Escolar Documentos
Profissional Documentos
Cultura Documentos
10 de diciembre de 2012
Tabla de contenido
Tema 1: Administracin Moderna Basada en Procesos de Negocio. ................................................................... 6 1.1.- Definicin de Administracin de Empresas. ................................................................................................... 6 1.2.- Definicin de Procesos de Negocio. ................................................................................................................. 6 1.3.- El Rol de las Normas ISO en los Procesos de Negocio. ............................................................................... 6 1.4.- Jerarqua entre Procesos de Negocio y Normas ISO. ................................................................................. 7 1.5.- Componentes de Administracin Basada en Procesos de Negocio. ........................................................ 7 1.6.- PDCA / KAIZEN / 5"S" / SIX SIGMA: ............................................................................................................. 7 1.7.- Control Interno sobre Procesos de Negocio. ................................................................................................. 8 1.8.- Eficiencia del Proceso de Negocio. ................................................................................................................... 8 1.9.- Puestos de Trabajo Orientados a los Procesos. ............................................................................................ 9 1.10.- Perfil del Puesto, Funciones, Atribuciones, Roles asociados al Proceso. ............................................... 9 1.11.- Relaciones de los Procesos de Negocio - Dependencias y Contribuciones. .......................................... 9 1.12.- Rol de la Matriz RACSI en el Proceso. .......................................................................................................... 9 1.13.- Definiciones Utilizadas: ................................................................................................................................... 10 Tema 2: Arquitectura Empresarial. ............................................................................................................................. 17 2.1.- Que es Arquitectura Empresarial. .................................................................................................................. 17 2.2.- Que Conforma la Arquitectura Empresarial. ................................................................................................ 18 2.3.- Framework de la Arquitectura Empresarial. ................................................................................................ 18 2.4.- Gobierno Corporativo. ....................................................................................................................................... 20 2.5.- La importancia de las Polticas Empresariales. ........................................................................................... 20 2.6.- El rol de las reglas de Negocio. ....................................................................................................................... 20 2.7.- La estrategia del Negocio. ............................................................................................................................... 20 2.8.- La Misin del Negocio. ...................................................................................................................................... 20 2.9.- La visin del Negocio. ........................................................................................................................................ 20 2.10.- Alineacin de la Arquitectura Empresarial con el Negocio. .................................................................... 20 2.11.- Giro de Negocio. .............................................................................................................................................. 21 2.12.- Estructura Organizativa. ................................................................................................................................ 21 2.13.- Gobiernos o Comits de Regulaciones. ...................................................................................................... 21 2.14.- Cultura Corporativa......................................................................................................................................... 21 Tema 3: Patrones de Procesos de Negocios. ........................................................................................................... 22 3.1.- Preguntas Claves para el Patrn de Procesos de Negocio. ..................................................................... 22 Qu son los Patrones de Procesos de Negocios?: ................................................................................................ 22 Cul es la diferencia entre los Patrones de Procesos de Negocios y los modelos de referencia? Cmo se complementan?: ........................................................................................................................................................ 23 Cul es la metodologa para disear procesos de negocios utilizando estos patrones?: ........................... 23 ITCP-CERBESA | 1
10 de diciembre de 2012
Cul es la relacin entre los Patrones de Procesos de Negocios y la Arquitectura Empresarial de Sistemas de una organizacin? .................................................................................................................................. 24 Cul es la relacin entre los Patrones de Procesos de Negocios y metodologas como Balanced Scorecard y Six Sigma? ................................................................................................................................................. 24 Cul es la relacin entre los Patrones de Procesos de Negocios y el Rediseo de Procesos? .................. 24 3.2.- Reingeniera, rediseo o mejora de procesos de negocio?. .................................................................. 25 3.3.- Qu significa BPR?. ......................................................................................................................................... 25 3.4.- Diferencia entre reingeniera y rediseo ....................................................................................................... 26 Tema 4: Evaluacin de Procesos de Negocio. ......................................................................................................... 28 4.1.- Tcnica del rbol de Problemas. .................................................................................................................... 28 4.2.- Tcnica del rbol de Objetivos. ........................................................................................................................ 28 4.3.- Diagrama Causa Efecto Ishikawa.................................................................................................................... 28 4.5.- Simbologa de diagramacin de Procesos. ................................................................................................... 28 4.6.- Matriz de Dependencias y Contribuciones como Herramienta descriptiva de Anlisis. ...................... 29 4.7.- Mapa Relaciones Estratgicas como Herramienta grafica de Anlisis. ................................................. 30 4.8.- Estadsticas del Proyectos. .............................................................................................................................. 30 4.9.- Porque Evaluar Procesos y no Puestos. ........................................................................................................ 31 4.10.- Matriz RACSI como Herramienta de Anlisis de personal que soporta un proceso. ........................ 31 Tema 5: Seis Sigma para apoyar la Alineacin Arquitectura Orientada a Servicios en los Procesos de Negocio. ............................................................................................................................................................................ 32 5.1.- Relacin entre Six Sigma en TI por medio de SOA. ..................................................................................... 32 5.2.- Anlisis de procesos de Auditoria Interna. ................................................................................................... 32 5.3.- Historia De Seis Sigma. .................................................................................................................................... 32 5.7.- Etapas Y Roles En La Estrategia Seis Sigma. ............................................................................................... 36 5.8.- Herramientas Utilizadas. .................................................................................................................................. 37 5.9.- Elementos Clave. ................................................................................................................................................ 37 5.10.- Diferencias Entre Calidad Tradicional Vs. Seis Sigma. ............................................................................. 37 5.11.- Seis Sigma En TI. ............................................................................................................................................. 38 5.12.- Six Sigma en TI. ................................................................................................................................................ 39 5.13.- Aplica Seis Sigma a TI?. ............................................................................................................................... 39 5.14.- Casos De xito De Seis Sigma en TI. ........................................................................................................... 39 5.15.- CMO APLICAR SEIS SIGMA A TI. ............................................................................................................... 40 5.16.- Seis Sigma en ITIL. .......................................................................................................................................... 42 5.17.- LOS BENEFICIOS DE SEIS SIGMA EN ITSM. ............................................................................................... 42 5.18.- Factores De xito Al Integrar Seis Sigma en TI. ........................................................................................ 43 5.19.- Sntesis de los Beneficios............................................................................................................................... 43
ITCP-CERBESA |
10 de diciembre de 2012
5.20.- SOA e ITIL. ......................................................................................................................................................... 43 5.21.- Definicin de Arquitectura y de Esquema de Arquitectura ..................................................................... 44 5.22.- Dimensiones de una Arquitectura Empresarial ........................................................................................ 44 5.23.- Mtodos de Desarrollo de la Arquitectura ................................................................................................ 45 5.24.-Continuum Empresarial .................................................................................................................................. 45 5.25.- Marcos de Arquitectura ................................................................................................................................ 45 Tema 6: Principios de Auditoria Interna. ................................................................................................................... 47 6.1.- Definicin de Control Interno. .......................................................................................................................... 47 6.2.- El rol del Auditoria Interna. ............................................................................................................................... 47 6.3.- Los procesos de Negocios son claves para Auditoria Interna. ................................................................. 48 6.4.- El Rol estratgico de Auditoria Interna. ......................................................................................................... 48 6.5.- Buenas Prcticas: COSO. ................................................................................................................................. 48 Tema 7: Principios de COSO - ERM. ............................................................................................................................ 50 7.1.- Que es COSO ERM. ........................................................................................................................................ 50 7.2.- Como apoya COSO ERM a la Arquitectura Empresarial. ........................................................................... 50 7.3.- COSO ERM como modelo de Gestin de Riesgos Corporativos. .......................................................... 50 7.4.- ISO 31000 Gestin del Riesgo. ....................................................................................................................... 51 7.5.- ISO 22301 Continuidad del Negocio. ............................................................................................................ 51 7.6.- ISO 27000 Seguridad de la Informacin. ..................................................................................................... 53 7.8.- Matriz de Riesgos. ............................................................................................................................................. 53 7.9.- Tipos de modelos o herramientas para elaborar una Matriz de Riesgos. ............................................. 53 Tema 8: CONTINUIDAD DE LOS PROCESOS DEL NEGOCIO. ................................................................................. 57 8.1.- Que es un BCP. ................................................................................................................................................... 57 8.2.- Como Administrar un BCPM. .......................................................................................................................... 57 8.3.- Que es un DRP. .................................................................................................................................................. 58 8.4.- Procesos de Negocio Claves. .......................................................................................................................... 58 8.5.- El rol de la Gestin del Riesgo Corporativo en un BCP. .............................................................................. 58 8.6.- DRP de TIC. ......................................................................................................................................................... 58 8.7.- RPO. ...................................................................................................................................................................... 60 8.8.- RTO. ...................................................................................................................................................................... 60 Tema 9: BUENAS PRACTICAS TI. ................................................................................................................................. 61 9.1.- Definicin de Buenas Prcticas. ..................................................................................................................... 61 9.2.- Definicin de Metodologa. ............................................................................................................................... 61 9.3.- Conceptos Generales de ITIL. .......................................................................................................................... 61 9.4.- Conceptos Generales de COBIT. ..................................................................................................................... 64 9.5.- Conceptos generales de CMMI. ...................................................................................................................... 65 ITCP-CERBESA | 3
10 de diciembre de 2012
9.6.- Conceptos generales de SOA. ......................................................................................................................... 67 9.7.- Conceptos generales de VAL IT. ..................................................................................................................... 68 9.8.- Conceptos Generales de RISK IT. ................................................................................................................... 69 9.10.- Conceptos Generales de Seguridad de la Informacin. ........................................................................... 70 9.11.- Conceptos Generales de Gobierno de TI. ................................................................................................... 72 9.12.- ITIL y COBIT como se complementan. ......................................................................................................... 73 Tema 10: SGSI. ............................................................................................................................................................... 74 10.1.- Principios de la Seguridad de la Informacin. ............................................................................................ 74 10.2.- Entorno de la Seguridad de la Informacin. ............................................................................................... 74 10.3.- SGSI. ................................................................................................................................................................... 75 10.4.- O ISM3 Modelo para la implementacin de un SGSI. ........................................................................... 77 Tema 11: Gobierno de Roles Identidades y Accesos. ............................................................................................ 80 11.1.- Definicin de IDM. ........................................................................................................................................... 80 11.2.- Definiciones de Roles, Identidades y Accesos. .......................................................................................... 80 11.3.- Definicin de Identidades. .............................................................................................................................. 81 11.4.- Definicin de Accesos. ................................................................................................................................... 81 11.5.- El Gobierno de roles identidades y accesos GRIA. .................................................................................... 82 11.6.- El Rol de Auditoria Interna en GRIA. ............................................................................................................ 82 Tema 12: Principios de Direccin de Proyectos. ..................................................................................................... 83 12.1.- Que es un Proyecto. ........................................................................................................................................ 83 12.2.- Triple restriccin de un Proyecto. ................................................................................................................ 83 12.3.- Grupo de Procesos de Iniciacin. ................................................................................................................. 84 12.4.- Grupo de Procesos de Planificacin. ........................................................................................................... 84 12.5.- Grupo de Procesos de Ejecucin.................................................................................................................. 84 12.6.- Grupo de Procesos de Monitoreo y Control. ............................................................................................. 84 12.7.- Grupo de Procesos Cierre. ............................................................................................................................ 84 12.8.- Gestin de Riesgos en los Proyectos. ......................................................................................................... 84 12.9.- Elaboracin del Caso de Negocio en los Proyectos. ................................................................................. 86 12.10.- Procesos y reas de Conocimiento. ......................................................................................................... 88 Tema 13: Sistema de Gestin Empresarial -SGE. ................................................................................................... 89 13.1.- Definicin de SGE. ............................................................................................................................................ 89 13.2.- Ciclos de procesos de Negocio de un SGE. ................................................................................................ 89 13.3.- La integracin de Tecnologa y los ciclos de procesos de negocio. ....................................................... 89 13.4.- Definicin de Acrnimos relacionados a SGE. ........................................................................................... 90 13.5.- Componentes claves de una SGE. ................................................................................................................ 90 13.6.- Beneficios de un SGE. ..................................................................................................................................... 92 ITCP-CERBESA | 4
10 de diciembre de 2012
13.7.- Diferencia entre datos e Informacin.......................................................................................................... 92 13.8.- Eliminar datos : Es correcto?. ..................................................................................................................... 92 13.9.- SGE es un sistema transaccional integrado. ............................................................................................. 92 Tema 14: Cambio Cultura Organizacional. ............................................................................................................... 94 14.1.- Cambio Organizacional Positivo. ................................................................................................................... 94 14.2.- Cultura de Servicio al Cliente. ....................................................................................................................... 97 14.3.- Cultura de Gestin basada en Procesos de Negocio. .............................................................................. 98 14.4.- Cultura de Administracin de Riesgos. ....................................................................................................... 98 14.5.- Cultura de Gestin de Proyectos. ................................................................................................................. 98
ITCP-CERBESA |
10 de diciembre de 2012
Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Las dos formas principales de visualizar una organizacin, son la vista funcional y la vista de procesos.
10 de diciembre de 2012
estndares de calidad, tiempos de entrega y niveles de servicio. Existen ms de 20 elementos en los estndares de esta ISO que se relacionan con la manera en que los sistemas operan. Su implantacin, aunque supone un duro trabajo, ofrece numerosas ventajas para las empresas, entre las que se cuentan con: Estandarizar las actividades del personal que trabaja dentro de la organizacin por medio de la documentacin. Incrementar la satisfaccin del cliente. Medir y monitorear el desempeo de los procesos generando valor agregado a los mismos. Disminuir reprocesar. Incrementar la eficacia y/o eficiencia de la organizacin en el logro de sus objetivos. Mejorar continuamente en los procesos, productos, eficacia, entre otros. Reducir las incidencias negativas de produccin o prestacin de servicios.
ITCP-CERBESA |
10 de diciembre de 2012
Clasificacin
, Seiri
Separar innecesarios
Orden
, Seiton
Situar necesarios
Limpieza
, Seis
Suprimir suciedad
Normalizacin
, Seiketsu
Sealizar anomalas
Mantener disciplina
la
, Shitsuke
Seguir mejorando
SIX SIGMA es una metodologa de mejora de procesos, centrada en la reduccin de la variabilidad de los mismos, consiguiendo reducir o eliminar los defectos o fallas en la entrega de un producto o servicio al cliente. La meta de 6 Sigma es llegar a un mximo de 3,4 defectos por milln de eventos u oportunidades (DPMO), entendindose como defecto cualquier evento en que un producto o servicio no logra cumplir los requisitos del cliente.
10 de diciembre de 2012
Generalmente, las definiciones exactas de los KPIs variarn dependiendo de la naturaleza de la organizacin. Existen, sin embargo, una cantidad de KPIs tpicos utilizados para evaluar los procesos. Un principio extensamente aceptado mantiene que los KPI's deben ser SMART: Especfico (Specific) Medible (Measurable) Alcanzable (Achievable) Orientado A Resultados (Result-Oriented) A Tiempo (Timely)
ITCP-CERBESA |
10 de diciembre de 2012
Existen algunas variantes que agregan dos roles ms: V=Verify (Verificador). Este rol se encarga de comprobar si el producto concuerda con los criterios de aceptacin establecidos en la descripcin del producto. S=Sign (Firmante). Este rol se aprueba las decisiones de V y autorizan la salida del producto. Lo lgico es que el trabajo de un S preceda siempre al de un A. En esta matriz se asigna el rol que el recurso debe jugar para cada actividad dada. No es necesario que en cada actividad se asignen los cinco roles, pero s por lo menos el de encargado y el de responsable. Estas matrices se pueden construir en alto nivel (reas generales) o en un nivel detallado (tareas de nivel bajo).
Son definidos por la Estrategia y Giro del Negocio. No contienen Detalle de sus Acciones ya que esta en sus procesos.
ITCP-CERBESA |
10
10 de diciembre de 2012
Proceso.
Secuencia de pasos o procedimientos relacionados mutuamente o que interactan, para generar valor, los cuales transforman elementos de entrada en productos o servicios que salen del proceso. Se caracteriza por tener Entradas y Salidas y de tener al menos un procedimiento para su ejecucin. Son cclicos los adems de atravesar toda la organizacin de forma directa o indirecta. Adems satisfacen necesidades de clientes internos y externos.
PROCESO DE NEGOCIO
Es Ciclico.
ITCP-CERBESA |
11
10 de diciembre de 2012
Procedimiento.
Es un conjunto de Actividades o acciones secuenciales que se realizan como apoyo a la ejecucin de un proceso, para obtener siempre el mismo resultado bajo determinadas circunstancias. Los procedimientos son dependientes del proceso y nicamente se activan segn la necesidad de los procesos. Son detallistas y capaces de soportar el procesos al que pertenecen. Los Criterios de Aceptacin de un Procedimiento son:
Soporta a un Proceso determinado. No posee entradas ni salidas. Es estatico. Detalla de forma especifica la forma de ejecutar las actividades.
PROCEDIMIENTO DE NEGOCIO
ITCP-CERBESA |
12
10 de diciembre de 2012
Actividad.
Conjunto de acciones con un fin en comn, son soporte de un procedimiento y generan valor al mismo, apoyando con esto al proceso que las agrupa. Los Criterios de Aceptacin de una Actividad son:
ACTIVIDADES DE NEGOCIO
Son Puntuales
Soportan un procedimiento.
No son Ciclicas.
ITCP-CERBESA |
13
10 de diciembre de 2012
Tarea.
Accin que se realiza en un periodo determinado para soportar una actividad del procedimiento. Los Criterios de Aceptacin de una Tarea son:
Conjunto de actividades que se ejecutan especificamente para resolver algo del procedimiento.
Es Eventual.
TAREA
Bajo Demanda.
Genera un Resultado.
ITCP-CERBESA |
14
10 de diciembre de 2012
Instructivo.
Documento con indicaciones especficas sobre la manera en que debe desarrollarse una actividad. Los Criterios de Aceptacin de un Instructivo son:
Es preciso
INSTRUCTIVO
ITCP-CERBESA |
15
10 de diciembre de 2012
Manual.
Un manual de instrucciones es una libreta en el que se explica paso a paso como realizar cierta tarea. Puede encontrarse en: En el mundo de la informtica es muy habitual encontrarlo, para realizar la instalacin de una aplicacin correctamente y qu hacer en caso de tener algn problema. Es tambin habitual encontrar uno cuando compramos cualquier aparato electrnico de cierta complejidad. Instrucciones de seguridad, en manufacturas cuya utilizacin inadecuada podra acarrear riesgos para la salud del usuario.
ITCP-CERBESA |
16
10 de diciembre de 2012
ITCP-CERBESA |
17
10 de diciembre de 2012
Arquitectura Objetivo: Muestra cmo debera estar compuesta la arquitectura futura y est representada bajo el framework de representacin especificando al detalle las vistas y dimensiones de la arquitectura. Iniciativas de Arquitectura: Est compuesto por la agrupacin de necesidades y requisitos en proyectos claros y definidos, los cuales hacen parte de un portafolio de proyectos. Esta agrupacin detalla las actividades necesarias para lograr llegar a tener una Arquitectura Objetivo desarrollada. Plan de Proyectos: Detalla la secuenciacin ptima para la ejecucin de las iniciativas de la Arquitectura. Generalmente se detallan los proyectos a nivel de alcance, tiempo, recursos, calidad. Comit de Arquitectura: Comit que norma las acciones sobre la arquitectura, propone y gestiona las actividades que afectan directamente la arquitectura actual y que hacen que se moldeen hacia la arquitectura Objetivo. Oficina de Proyectos. Permite controlar el efectivo avance de cada uno de los proyectos planteados para llegar a la arquitectura empresarial objetivo. Con esto es posible tener un modelo que permita atender estructuradamente el proceso ciclo de mantenimiento de una Arquitectura Empresarial. En la contextualizacin de la Arquitectura Empresarial se inicia con la definicin del framework de representacin y los principios de la arquitectura, se realiza un diagnstico para determinar el estado actual de la arquitectura; a partir de la formulacin estratgica, se define el deber ser de la arquitectura logrando construir los elementos de representacin necesarios en el framework. Una vez se tiene esto, se identifican las brechas para convertirlas en iniciativas de proyectos. En el mantenimiento de la Arquitectura Empresarial, se hace una administracin detallada de las iniciativas a travs de la implantacin de una oficina de proyectos y se mantienen todas las iniciativas validadas en el comit de Arquitectura. Rpidamente este es el concepto de una Arquitectura Empresarial implementada en una organizacin y con este modelo se puede tener visibilidad clara de una Arquitectura.
ITCP-CERBESA |
18
10 de diciembre de 2012
La palabra inglesa "framework" (marco de trabajo) define, en trminos generales, un conjunto estandarizado de conceptos, prcticas y criterios para enfocar un tipo de problemtica particular que sirve como referencia, para enfrentar y resolver nuevos problemas de ndole similar.
ITCP-CERBESA |
19
10 de diciembre de 2012
10 de diciembre de 2012
En el mantenimiento de la Arquitectura Empresarial, se hace una administracin detallada de las iniciativas a travs de la implantacin de una oficina de proyectos y se mantienen todas las iniciativas validadas en el comit de Arquitectura.
ITCP-CERBESA |
21
10 de diciembre de 2012
ITCP-CERBESA |
22
10 de diciembre de 2012
Cul es la diferencia entre los Patrones de Procesos de Negocios y los modelos de referencia? Cmo se complementan?:
Hay modelos de referencia de varios tipos; los ms antiguos son los modelos de referencia de ARIS-SAP. La diferencia entre los PPN y estos modelos de referencia es el nfasis en lo que se desea modelar. Los PPN estn claramente orientados a modelar la estructura sistmica de un negocio, enfatizando las relaciones entre los diferentes procesos que existen y cmo se puede optimizar la coordinacin entre ellos, por medio de lgicas de negocio (algoritmos con base analtica, heursticas o reglas) bien diseadas y automatizadas parcial o totalmente por medio de apoyo TI. Los modelos de referencia ARIS-SAP enfatizan el modelamiento del procesamiento computacional que apoya un proceso. Por lo tanto los patrones y estos modelos de referencia son potencialmente complementarios, ya que trabajan a diferentes niveles de abstraccin. Esto se est demostrando en un proyecto real que estamos ejecutando en una empresa, donde se est utilizando un software tipo ERP que tiene un mtodo de modelamiento parecido a ARIS; aqu los PPN han permitido el diseo de una estructura complementaria de procesos ms orientados al negocio que no cubra el ERP. Otros modelos de referencia, hoy da ms populares y ms usados que los de ARIS-SAP, son SCOR e eTOM, los cuales estn ms cercanos a nuestros patrones, ya que tambin se centran en el negocio, estableciendo estructuras jerrquicas de procesos, procedimientos y actividades en la forma de rboles. En el ltimo nivel se entregan mejores prcticas y mtricas para medir desempeo de las actividades. Estos modelos fueron propuestos despus de los nuestros y, a diferencia de los PPN, no consideran explcitamente las relaciones entre los procesos. Adems estn especializados a empresas con cadena de abastecimiento, SCOR, y a empresas de telecomunicaciones, eTOM. stos han demostrado ser muy complementarios a los PPN, ya que hemos ejecutado muchos proyectos en que los PPN se han especializado y adaptado usando ideas de SCOR o eTOM. Pero el diseo de la estructura de relaciones y los mecanismos de coordinacin se ha hecho a partir de los PPN..
ITCP-CERBESA |
23
10 de diciembre de 2012
sistemas que permitieron el pago de las pensiones a partir de Julio, tal como lo haba prometido la Presidenta, con muy buena atencin y sin demoras.
Cul es la relacin entre los Patrones de Procesos de Negocios y la Arquitectura Empresarial de Sistemas de una organizacin?
En el caso ms normal, los PPN, al ser utilizados dentro de una metodologa como la bosquejada anteriormente, definen apoyos computacionales que deben insertarse dentro de una Arquitectura Empresarial de sistemas existentes. A lo menos, de acuerdo a nuestra experiencia, hay que integrarse con los datos que tienen las bases de datos de los sistemas actuales y slo se complementa la Arquitectura Empresarial de sistemas con aplicaciones que ejecutan lgica sofisticada de negocios, que no proveen tales sistemas. En el caso ms raro en que se puede disear o redisear la Arquitectura Empresarial completa de sistemas basada en Servicios (SOA), sta debe estar al servicio, o deducirse, de la Arquitectura Empresarial de procesos rediseada de la empresa y de los diseos detallados de los procesos.
Cul es la relacin entre los Patrones de Procesos de Negocios y metodologas como Balanced Scorecard y Six Sigma?
Esto fue contestado en alguna medida en la tercera pregunta, ya que el rediseo de procesos debe partir con un planteamiento estratgico, el cual puede realizarse con la metodologa de Balanced Scorecard (BSC); adems uno de los macro procesos de la organizacin es el de Planificacin del Negocio, el cual puede disearse en detalle siguiendo las ideas del BSC, como lo estamos haciendo en algunos proyectos reales. Por ltimo, est la idea, dentro de la Arquitectura Empresarial genrica de macro procesos, de que el macro proceso Desarrollo de Nuevas Capacidades debe estar constantemente monitoreando la Cadena de Valor para detectar oportunidades de rediseo de sta. Tal monitoreo puede hacerse a partir de indicadores generados con un BSC, pero, tambin, podra provenir de mediciones y anlisis del proceso que se realizan con tcnicas del tipo Six Sigma.
10 de diciembre de 2012
En muchas ocasiones he escuchado en reuniones: "Tenemos que aplicar una reingeniera" y en muchas licitaciones, tanto pblicas como privadas, se pide luego de un levantamiento y anlisis, un rediseo y mejora de los procesos de negocio. En reiteradas ocasiones les he preguntado a mis alumnos de magster y diplomado si los trminos "reingeniera, rediseo y mejora" son sinnimos o conceptos diferentes. El resultado ha sido que muy pocos profesionales o estudiantes han sabido diferenciar claramente estos enfoques. A continuacin definir cada uno de ellos y explicar cundo y cmo se aplican. El trmino "reingeniera de procesos" (en ingls: Business Process Reengineering, BPR) fue propagado por una publicacin de Hammer & Champy en el ao 1993, que se hizo famosa como respuesta al hecho de cmo las empresas tradicionales podan enfrentar la prolongada recesin que se vena arrastrando desde mediados de los 80 en los pases occidentales, amenazados por la eficiente competencia asitica. Al respecto Hammer & Champy dejan claro cul es el "driver", o el "Leitmotiv" para aplicar una reingeniera:
"Reingeniera de procesos significa quebrar con paradigmas antiguos, procedimientos obsoletos y orientarse fundamentalmente hacia la creacin de valor para el cliente, al pensar en reestructurar la nueva forma de organizar el trabajo".
ITCP-CERBESA |
25
10 de diciembre de 2012
El BPR requiere de grandes esfuerzos, consume muchos recursos y demanda una gran coordinacin de participantes de todos los niveles en una organizacin, razn por la cual se clasifica en una de las categoras de proyectos de alto riesgo. El BPR debera restringirse a aquellos procesos de negocio que tienen una importancia estratgica y cuyo desempeo actual es altamente deficiente. Pero, qu podramos entender por deficiente y cundo se justifica una reingeniera de procesos?: La competencia supera sin problemas a la compaa. Los productos y servicios no satisfacen las necesidades de los clientes: Se requiere de una nueva solucin orientada a la demanda del mercado (clientes). Una nueva solucin requiere el diseo de un nuevo proceso. Existen muchos conflictos dentro de la organizacin: Muchas reuniones sin resultados. El poder informal es ms alto que el formal. Comunicacin excesiva fuera de la lnea.
10 de diciembre de 2012
est inserto dentro de la gestin diaria de operaciones y, a diferencia de la tcnica de rediseo, no requiere de la formulacin de un proyecto. El ciclo de la implementacin de la mejora queda en manos de los responsables del negocio y no consume recursos adicionales a los propios. Algunos de estos conceptos de mejora continua se conocen bajo los nombres de Six Sigma, Kaizen y Total Cycle Time, pero tambin podemos sumar a estas tcnicas el slo monitorear el rendimiento de los procesos a travs de indicadores de ciclo u otros y comenzar iniciativas de mejora cuando se detectan desviaciones al comportamiento esperado (BPM-Governance). El concepto de mejora continua est limitado a cambios pequeos como reglas de negocio, procedimientos locales, redistribucin del volumen de trabajo, simplificacin de formularios, etc. Si los cambios propuestos por la mejora continua impactan sobre la estructura de los procesos, traspasan los lmites de responsabilidad del rea, impactan sobre la tecnologa, o bien requieren de recursos adicionales, y la propuesta de mejora pasa a un proyecto de rediseo. De igual forma si un proyecto de rediseo pone en duda la estructura de responsabilidades o traspasa las fronteras de un rea de negocio, pasa a ser un proyecto de reingeniera. Sin embargo, en un proyecto de modelado de procesos, sea con BPMN u otra notacin, siempre se espera o se ordena analizar el contexto en vas de mejorar el rendimiento de los procesos actuales cuando se implementen. No es suficiente que el analista aprenda la notacin en que modelar los procesos, sino que, para poder proponer un nuevo diseo del proceso, debe saber qu analizar y conocer las tcnicas en cada uno de estos diferentes enfoques. La figura muestra una tabla con las principales caractersticas que diferencian los tres enfoques principales de mejora de procesos (Ver cuadro). Caracterstica Enfoque Punto de partida Objetivo del cambio Tipo de cambio Periodicidad del cambio Organizacin del cambio Impulsor del cambio Reingeniera Proceso nuevo Proceso existente Rediseo Restructuracin Proceso existente Mejora Mejora evolutiva Proceso existente Actualizacin, eficiencia o satisfacer al cliente Incremental Continuo Dentro de operaciones Cualquier actor Dentro de un Subproceso Cognitivo Procedimiento, regla de negocio Costo, calidad, tiempo Medio Bajo
Cambio radical, satisfacer al Rediseo de una parte del cliente proceso Radical Descontinuado Proyecto Directorio Transversal Cultural Estructural Intervalos intermedios Proyecto o grupo de trabajo Dueo de proceso Proceso, subproceso Cultural Procesal Estructural
Procesal Estructural
Riesgo
Alto
ITCP-CERBESA |
27
10 de diciembre de 2012
10 de diciembre de 2012
Conector fuera de pgina: Representa la continuidad del diagrama en otra pgina. Representa una conexin o enlace con otra hoja diferente en la que continua el diagrama de flujo (Figura 12). Conector dentro de pgina: Representa la continuidad del diagrama dentro de la misma pgina. Enlaza dos pasos no consecutivos en una misma pgina. (Figura 13) Lneas de flujo: Conecta los smbolos sealando el orden en que se deben realizar las distintas operaciones (Figura 14) Almacn de datos: Indica el depsito permanente de un documento o informacin dentro de un archivo (Figura 15)
ITCP-CERBESA |
29
10 de diciembre de 2012
ITCP-CERBESA |
30
10 de diciembre de 2012
4.10.- Matriz RACSI como Herramienta de Anlisis de personal que soporta un proceso.
La matriz RACSI permite identificar la cantidad de puestos que intervienen en el proceso y sus roles en el mismo, esto permite determinar si un proceso tienen los recursos necesarios para su ejecucin, o evidencia si hay carencia o sobre abundancia para los mismos. Adems permite establecer si los procesos cuentan con los perfiles de puestos adecuados.
ITCP-CERBESA |
31
10 de diciembre de 2012
Tema 5: Seis Sigma para apoyar la Alineacin Arquitectura Orientada a Servicios en los Procesos de Negocio.
5.1.- Relacin entre Six Sigma en TI por medio de SOA.
Seis Sigma, es una filosofa de trabajo y una estrategia de negocios, la cual se basa en el enfoque hacia el cliente, en un manejo eficiente de los datos y metodologas y diseos robustos, que permite eliminar la variabilidad en los procesos y alcanzar un nivel de defectos menor o igual a 3,4 defectos por milln. Adicionalmente, otros efectos obtenidos son: reduccin de los tiempos de ciclo, reduccin de los costos, alta satisfaccin de los clientes y ms importante an, efectos dramticos en el desempeo financiero de la organizacin. En general, los procesos estndar tienden a comportarse dentro del rango de tres (3) Sigma, lo que equivale a un nmero de defectos de casi 67.000 por milln de oportunidades (DPMO), si ocurre un desplazamiento de 1,5 Sigma; esto significa un nivel de calidad de apenas 93,32 %, en contraposicin con un nivel de 99,9997 % para un proceso de Seis Sigma. Comparativamente, un proceso de Tres Sigma es 19.645 veces ms malo (produce ms defectos) que uno de Seis Sigma. Quines utilizan Seis Sigma? Empresas comprometidas con la satisfaccin del cliente en la entrega oportuna de productos y servicios, libres de defectos y a costos razonables. Algunos ejemplos: Motorola, Allied Signal, G.E., Polaroid, Sony, Lockheed, NASA, Black & Decker, Bombardier, Dupont, Toshiba, etc. Por ejemplo, Motorola entre 1987 y 1994 redujo su nivel de defectos por un factor de 200. Redujo sus costos de manufactura en 1,4 billones de dlares. Increment la productividad de sus empleados en un 126,0 % y cuadruplic el valor de las ganancias de sus accionistas. Los resultados para Motorola hoy en da son los siguientes: Incremento de la productividad de un 12,3 % anual; reduccin de los costos de mala calidad sobre un 84,0 %; eliminacin del 99,7 % de los defectos en sus procesos; ahorros en costos de manufactura sobre los Once Billones de dlares y un crecimiento anual del 17,0 % compuesto sobre ganancias, ingresos y valor de sus acciones. Seis Sigma no slo es una metodologa que aplique al mundo de la manufactura, esta metodologa se puede aplicar a las reas de TI y esto har que se ahorren costos y que se mejore la calidad de los servicios y se propicia la mejora continua.
ITCP-CERBESA |
32
10 de diciembre de 2012
Allied Signal, Sony, Polaroid, Dow Chemical, FeDex, Dupont, NASA, Lockheed, Bombardier, Toshiba, J&J, Ford, ABB, Black & Decker, etc. Su aplicacin requiere del uso intensivo de herramientas y metodologas estadsticas (en su mayora) para eliminar la variabilidad de los procesos y producir los resultados esperados, con el mnimo posible de defectos, bajos costos y mxima satisfaccin del cliente. Esto contrasta con la forma tradicional de asegurar la calidad, al inspeccionar postmortem y tratar de corregir los defectos, una vez producidos. Un proceso con una curva de capacidad afinada para Seis Sigma, es capaz de producir con un mnimo de hasta 3,4 defectos por milln de oportunidades (DPMO), lo que equivale a un nivel de calidad del 99.9997 %. Este nivel de calidad se aproxima al ideal del cero-defectos y puede ser aplicado no solo a procesos industriales de manufactura, sino tambin en procesos transaccionales y comerciales de cualquier tipo, como por ejemplo: en servicios financieros, logsticos, mercantiles, tecnologa, etc. Quiz la contribucin ms importante para el auge y desarrollo actual de Seis Sigma, haya sido el inters y esfuerzo dedicado para su implantacin en toda G.E., desde sus divisiones financieras, hasta sus divisiones de equipos mdicos y de manufactura. La fuerza impulsora que apuntal y apoy esta iniciativa: Jack Welch, CEO de G.E. "Miren, Solamente tengo tres cosas que hacer: tengo que seleccionar a las personas correctas, asignar la cantidad adecuada de dlares y transmitir ideas de una divisin a otra a la velocidad de la luz. As que realmente estoy en el negocio de promover y transmitir ideas". [1]
ITCP-CERBESA |
33
10 de diciembre de 2012
ITCP-CERBESA |
34
10 de diciembre de 2012
Como estrategia gerencial, Seis Sigma se desarrolla en ocho etapas en las cuales participan los diferentes niveles de la organizacin. A las cuatro ya mencionadas se agregan dos etapas iniciales de identificacin y definicin de carteras de proyectos y otras dos etapas posteriores que se refiere a la estandarizacin e integracin a nivel empresa de las mejoras logradas en los proyectos individuales. Estas fases se muestran en la siguiente figura.
ITCP-CERBESA |
35
10 de diciembre de 2012
Lderes de Proyectos, Cinturones Negros (Black Belts-BB) Son el recurso de tiempo completo que tiene la organizacin y se focalizan en liderar y facilitar el desarrollo y trmino de los proyectos. Los BB juegan varios papeles, sin embargo su papel ms importante es: ayudar a las personas de la organizacin a materializar las oportunidades de mejora que se hayan detectado; ayudar en la reduccin de los defectos o problemas que se abordarn a travs de los proyectos Seis sigma y finalmente proporcionar la direccin y orientacin a los equipos de proyecto para el desarrollo de las tcnicas de resolucin de problemas. Esto requiere que los BB entiendan y dominen la aplicacin prctica de las herramientas de Seis Sigma, que desarrollen activamente el trabajo en equipo y que tengan la habilidad y disciplina para orientar sus decisiones, basndose en las evidencias objetivas que puedan desarrollar como parte de la estrategia Seis Sigma. Uno de sus roles claves, es ayudar al proyecto -por la va de la induccin y la bsqueda del compromiso de los miembros de su equipo y de otras personas involucradas- a organizar y analizar en forma sistemtica la sabidura de la organizacin, para hacer visible las virtudes y defectos de los procesos con los que operan. Los BB tambin actan como exploradores de datos o para identificar la necesidad de stos ya que el contar con datos puede ser tan crtico, que el proyecto de un BB puede ser definir las mtricas que se requieren para una necesidad especfica y los recursos para su materializacin. Finalmente, los BB juegan un papel clave como facilitadores y lderes de cambio, ya que son los que aportan las nuevas ideas o visiones de cmo hacer las cosas de mejor forma. Reciben un entrenamiento intensivo de cuatro semanas, con 160 horas de entrenamiento especfico en un lapso de 4 meses, durante los cuales deben ejecutar un proyecto exitoso y dar demostraciones de dominio de la cartera de herramientas Seis Sigma. Facilitadores de Proyectos, Cinturones Verdes (Green Belts-GB) Como recursos a tiempo parcial, ellos ayudan a los BB a completar los proyectos y a mantener sus logros. Realizan tambin actividades claves en las fases preliminares del proyecto para la exploracin y tratamiento inicial de datos y participan activamente en las actividades de la fase de control con el desarrollo de mtodos y entrenamiento operacional. Esto permite liberar de los BB para que puedan
ITCP-CERBESA |
36
10 de diciembre de 2012
abordar otros proyectos de mejoramiento que tengan impacto en la lnea base del negocio. Reciben un entrenamiento de 2 semanas, en un lapso de 2 meses, con un total de 80 horas de entrenamiento. Integrantes del grupo de proyecto (Yellow Belts- YB) Ellos son los integrantes de un proyecto especfico con dedicacin a tiempo parcial que proporcionan la sabidura de la organizacin y de esa forma aportan su conocimiento especficos y/o multifuncional, para implementar y cumplir los propsitos de los proyectos y del mismo modo, ayudan a mantener o sustentar los mejoramientos y las ganancias logradas. Se seleccionan de acuerdo a sus conocimientos, competencia y experiencias en los procesos y operaciones que se pretenden mejorar. Reciben entrenamiento aplicado a los aspectos que sern requeridos para un efectivo desarrollo del proyecto. El entrenamiento es proporcionado por los Cinturones Negros al inicio, durante la ejecucin y al trmino de la etapa de control. Recientemente se ha tomado conciencia que el aporte del grupo de proyecto se incrementa en la medida que van entendiendo en que consiste la Estrategia de Seis Sigma, por esta razn se ha creado esta nueva categora denominada Yellow Belts- YB que reciben un entrenamiento de 5 das lo que les permite integrar las metodologas Seis Sigma para el mejoramiento de los procesos productivos, de servicio o transaccionales.
CIP, Procesos de Mejora Continua. Diseo/Rediseo de Procesos. Anlisis de Varianza, ANOVA. Cuadro de Mando Integral, BSC. La Voz del Cliente, VOC. Pensamiento Creativo. Diseo de Experimentos, DoE. Gerencia de los Procesos. Control Estadstico de Procesos, SPC.
10 de diciembre de 2012
satisfaccin tanto de las necesidades y objetivos de los clientes, como de las necesidades y objetivos de la propia organizacin. En la siguiente tabla [1] se resumen algunas de las diferencias ms notables entre la forma tradicional de enfocar la Calidad en las organizaciones y la forma de enfocarla a travs de la estrategia de Seis Sigma:
SEIS SIGMA Est descentralizada en una estructura constituida para la deteccin y solucin de los problemas. Su enfoque es proactivo. Se hace uso estructurado de las herramientas de mejora y de las tcnicas estadsticas para la solucin de los problemas. Se provee toda una estructura de apoyo y capacitacin al personal, para el empleo de las herramientas de mejora. La toma de decisiones se basa en datos precisos y objetivos: "Slo en Dios creo, los dems traigan datos". Se v a la causa raz para implementar soluciones slidas y efectivas y as prevenir la recurrencia de los problemas. Se establecen planes de entrenamiento estructurados para la aplicacin de las tcnicas estadsticas requeridas.
Generalmente no hay una aplicacin estructurada de las herramientas de mejora. No se tiene soporte en la aplicacin de las herramientas de mejora. Generalmente su uso es localizado y aislado. La toma de decisiones se efecta sobre la base de presentimientos y datos vagos. Se aplican remedios provisionales o parches. Slo se corrige en vez de prevenir. No se establecen planes estructurados de formacin y capacitacin para la aplicacin de las tcnicas estadsticas requeridas. Se enfoca solamente en la inspeccin para la deteccin de los defectos (variables clave de salida del proceso). PostMortem.
Se enfoca hacia el control de las variables clave de entrada al proceso, las cuales generan la salida o producto deseado del proceso.
ITCP-CERBESA |
38
10 de diciembre de 2012
Es necesario que Seis Sigma sea un proyecto de arriba abajo. Seis Sigma es una herramienta de transformacin directiva, y si los administradores de alto nivel no estn interesados o no estn dispuestos a patrocinar ellos mismos la estrategia, es seguro que la metodologa falle.
ITCP-CERBESA |
39
10 de diciembre de 2012
Un equipo de ingenieros de Fidelity Wide Processing esperan disminuir entre 6 y 8 millones los costos este ao (CIO Magazine) El departamento de TI de Seagate registro ahorros de 3.7 millones de dlares al instituir Seis Sigma durante el ao fiscal previo. Desde que se implemento Seis Sigma hace ms de dos aos la compaa ha ahorrado 4.5 millones de dlares (CIO Magazine) o Estamos siendo ms rigurosos con los contratos de mantenimiento. Trabajamos en equipo y analizamos las necesidades y definimos los niveles de servicio. Eso ahorro 1.5 millones de dlares (Mark Brewer, Seagate CIO) o Los archivos de datos eran muy grandes para transferirlos a otros sistemas para su anlisis. El retraso resultaba en retrasos mayores al momento de detectar problemas. Cuando el proyecto empez no fue claro del todo detectar que el problema era el tiempo de transferencia. Pero aplicando Seis Sigma a este problema, la causa raz fue encontrada y un apropiado ajuste fue hecho a la red y al servidor de archivos (bajando el tiempo del proceso de 19 a 5 minutos). Se ahorr un milln de dlares en este proceso. (Mark Brewer, Seagate CIO) Enterprise Managment Associates recientemente condujo una investigacin en el uso de Seis Sigma para administrar la calidad de servicio de TI e indica que un 65 reconocen la importancia que tiene este mtodo para la administracin de servicios de TI.
ITCP-CERBESA |
40
10 de diciembre de 2012
Supongamos que el diagrama mostrado arriba muestra a una organizacin que procesa tarjetas de crdito. Los Flotantes (fondos no recolectados) y deudas malas son cuestiones importantes en un negocio como este. Supongamos que los altos directivos han establecido una meta estratgica para mejorar el Retorno en Igualdad (Return on equity, ROE), estas seran las Ys en esta instancia. Obviamente TI no puede hacer mucho acerca de esa meta, y lo ms probable es que ninguna otra organizacin lo pueda hacer mucho tampoco. Pero, se puede dividir esto en pequeas Ys y la administracin se puede asignar como una responsabilidad a departamentos o unidades especficas. Las unidades recolectoras pueden escoger medir sus contribuciones a las metas en trminos de alguna unidad que haga sentido al negocio, como puede ser en el caso de las tarjetas Ventas pendientes del da. En el caso de un centro de llamadas (call center), una meta especfica podra ser el nmero de clientes contactados cada hora de cada da. Cuando los contactos caen, la recoleccin de datos tambin. Las recolecciones, las Ys, son dirigidas por el nmero de llamadas realizadas, quizs una x (probablemente una de muchas xs potenciales). Se pueden utilizar otros factores que controlar por ejemplo el nmero de llamadas que realiz el equipo, el promedio de tiempo por llamada, y otros muchos factores. Se observa que la importancia de las xs es que dirigen el nmero de llamadas y esto significa la disponibilidad de los sistemas de TI. Ellos no pueden llamar si la red telefnica o la base de datos de clientes no est disponible. Por lo tanto, la recoleccin efectiva de datos reflejar el nivel de servicios provista por el rea de TI de la organizacin. Este proceso es aplicable a cada unidad de TI. Es siempre posible cuantificar la contribucin al negocio que resulta de las mejoras de TI, por ejemplo, costos, disponibilidad, tiempo, o niveles de calidad.
ITCP-CERBESA |
41
10 de diciembre de 2012
ITSM ayuda a asegurar la alineacin de los Servicios de TI con el negocio y los requerimientos del cliente y este articula y apoya los servicios de los proveedores de TI para brindar un servicio de excelencia y Mejora Continua. En comparacin, Seis Sigma es en esencia una iniciativa de la mejora de la calidad con un enfoque al negocio y adems es mucho ms compatible con los mtodos de ITSM. Ambos enfoques tienen entre sus cualidades reducir costos y proveer alta calidad usando mejores prcticas aplicadas a productos y/o servicios. Seis Sigma puede ayudar a promover y habilitar ITSM ya que ste provee una adopcin general y adems provee beneficios que pueden ser expresados en trminos financieros. Como un nivel estratgico Seis Sigma puede ayudar a posicionar a ITSM para conocer los requerimientos del negocio concentrndose en las perspectivas de Aprovisionamiento de Servicios con Calidad y ahorro en Costos. Este puede proveer la estructura y rigor de las mejores prcticas a ITSM de una manera que el negocio y los accionistas puedan entender, respetar y apreciar. Realmente puede existir una sinergia entre Seis Sigma con la metodologa ITSM.
ITCP-CERBESA |
42
10 de diciembre de 2012
10 de diciembre de 2012
SOA proporciona una metodologa y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integracin y consolidacin. La metodologa de modelado y diseo para aplicaciones SOA se conoce como anlisis y diseo orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementacin. Para que un proyecto SOA tenga xito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en trminos de planificacin, herramientas e infraestructura. The Open Group Architecture Framework (TOGAF) (o Esquema de Arquitectura de Open Group, en espaol) es un esquema (o marco de trabajo) de Arquitectura Empresarial que proporciona un enfoque para el diseo, planificacin, implementacin y gobierno de una arquitectura empresarial de informacin. Esta arquitectura es modelada por lo general con cuatro niveles o dimensiones: Negocios, Tecnologa (TI), Datos y Aplicaciones. Cuenta con un conjunto de arquitecturas base que buscan facilitarle al equipo de arquitectos definir el estado actual y futuro de la arquitectura.
ITCP-CERBESA |
44
10 de diciembre de 2012
3. Arquitectura de Datos, la cual describe la estructura de los datos fsicos y lgicos de la organizacin , y los recursos de gestin de estos datos 4. Arquitectura Tecnolgica, la cual describe la estructura de hardware, software y redes requerida para dar soporte a la implantacin de las aplicaciones principales, de misin crtica, de la organizacin
5.24.-Continuum Empresarial
El Continuum Empresarial puede ser interpretado como un "repositorio virtual" de todos los artefactos arquitectnicos disponibles en una organizacin. Incluye modelos arquitectnicos, patrones de arquitectura, descripciones arquitectnica, entre otros. Estos artefactos pueden existir especficamente al interior de la empresa, o en general en la industria de Tecnologas de Informacin. El Continuum Empresarial consiste tanto del Continuum Arquitectnico como del Continuum de Soluciones. Continuum Arquitectnico especifica la estructura de los artefactos arquitectnicos reutilizables, incluyendo reglas, representaciones y relaciones de los sistemas de informacin disponibles en la organizacin. Continuum de Soluciones describe la implementacin del Continuum Arquitectnico mediante la definicin de bloques constituitivos de solucin (solution building blocks, en ingls).
ITCP-CERBESA |
45
10 de diciembre de 2012
ITCP-CERBESA |
46
10 de diciembre de 2012
ITCP-CERBESA |
47
10 de diciembre de 2012
Para actuar en el departamento de auditora interna, cualquier personal adscrito con carcter de auditor interno debe tener en cuenta: Cumplimiento de las normas profesionales de conducta Debe poseer los conocimientos tcnicos y disciplinarios para la realizacin de las auditoras internas Los auditores internos estn obligados a una formacin permanente Los auditores internos deben poseer ciertas dosis de relaciones humanas y comunicacin Los auditores internos deben actuar con el debido cuidado profesional
El control interno se puede considerar eficaz en cada una de las 3 categoras si el consejo de admn. Y la direccin tiene la seguridad razonable de que: Disponer de informacin adecuada sobre hasta qu punto se estn logrando los objetivos operacionales de la entidad Se preparan de forma fiable los estados financieros pblicos Se cumplen las leyes y normas aplicables El control interno est compuesto de cinco componentes relacionados entre s que se derivan de la manera en que la direccin dirija la empresa y estn integrados en el proceso de direccin.
10 de diciembre de 2012
Dicho nombre fue adoptado debido a que se trata de un trabajo por ms de cinco aos, de varias instituciones ubicadas en aproximadamente cincuenta pases. La comisin fue creada con el objetivo de tener un marco conceptual compuesto por diferentes puntos de vista acerca del Control Interno.
ITCP-CERBESA |
49
10 de diciembre de 2012
ITCP-CERBESA |
50
10 de diciembre de 2012
La gestin de riesgos corporativos es un proceso efectuado por el consejo de administracin de una entidad, su direccin y restante personal, aplicable a la definicin de estrategias en toda la empresa y diseado para identificar eventos potenciales que puedan afectar a la organizacin, gestionar sus riesgos dentro del riesgo aceptado y proporcionar una seguridad razonable sobre el logro de los objetivos. Podemos decir que los grupos de Inters son: Accionistas. Inversionistas. Empleados. Comunidad. Clientes. Proveedores. Acreedores. Estado. Esta definicin recoge los siguientes conceptos bsicos de la gestin de riesgos corporativos: Es un proceso continuo que fluye por toda la entidad. Es realizado por su personal en todos los niveles de la organizacin. Se aplica en el establecimiento de la estrategia. Se aplica en toda la entidad, en cada nivel y unidad, e incluye adoptar una perspectiva del riesgo a nivel conjunto de la entidad. Est diseado para identificar acontecimientos potenciales que, de ocurrir, afectaran a la entidad y para gestionar los riesgos dentro del nivel de riesgo aceptado. Es capaz de proporcionar una seguridad razonable al consejo de administracin y a la direccin de una entidad. Est orientada al logro de objetivos dentro de unas categoras diferenciadas, aunque susceptibles de solaparse. La definicin es amplia en sus fines y recoge los conceptos claves de la gestin de riesgos por parte de empresas y otras organizaciones, proporcionando una base para su aplicacin en todas las organizaciones, industrias y sectores. Se centra directamente en la consecucin de los objetivos establecidos por una entidad determinada y proporciona una base para definir la eficacia de la gestin de riesgos corporativos.
10 de diciembre de 2012
Si se implementa correctamente, la gestin de la continuidad del negocio disminuir la posibilidad de ocurrencia de un incidente disruptivo y, en caso de producirse, la organizacin estar preparada para responder en forma adecuada y, de esa forma, reducir drsticamente el dao potencial de ese incidente.
La Gestin de la Continuidad implica el cumplimiento de una serie de actividades que aseguran que los procesos y/o servicios crticos de una organizacin estarn disponibles en todo momento. Este tipo de gestin surge debido a que hay organizaciones que requieren demostrar que pueden seguir operando bajo cualquier circunstancia o situacin, o bien simplemente asegurar a sus clientes que los servicios que proporcionan siempre estarn disponibles sin importar la gravedad de los incidentes. Anteriormente, las organizaciones podan acceder al estndar britnico BS 25999, sin embargo, ste slo era reconocido en el Reino Unido aunque fuera implementado mundialmente. A partir de mayo de 2012, el estndar BS 25999 es sustituido por la norma ISO 22301:2012 y se establece como la norma internacional para Gestionar la Continuidad del Negocio. Aqu se plantean una serie de requisitos que al ser cumplidos garantizan que las organizaciones puedan seguir ejecutando sus actividades sin importar los eventos o contratiempos que se presenten en la operacin.
ITCP-CERBESA |
52
10 de diciembre de 2012
La norma ISO 22301:2012 est organizada en 10 secciones, las tres primeras se refieren al Alcance, Referencias, Normativas, y Trminos y Definiciones. Las siguientes 7 secciones contienen los requisitos de la norma, los cuales son genricos y pueden ser aplicables a cualquier tipo de organizacin. El primer requisito se refiere al Contexto de la Organizacin, donde se abordan temas internos y externos que son importantes para los objetivos del negocio y que en determinado momento podra verse comprometido su cumplimiento. Estos temas, de acuerdo a la norma, requieren de una revisin de las actividades de la organizacin, funciones, productos o servicios, y el impacto de un incidente que pudiera generar una interrupcin, tambin contempla los vnculos entre la poltica de continuidad del negocio con otras polticas de la organizacin, as como reglamentos o leyes a las cuales la compaa est sujeta a cumplir. En conjunto, estos temas ayudarn a determinar el alcance del Sistema de Gestin de la Continuidad del Negocio (SGCN) sin olvidar contemplar los riesgos que la organizacin pueda tolerar o este acostumbrada a afrontar.
10 de diciembre de 2012
A continuacin se presentan la metodologa que se utiliza: Riesgo = Valor de activos Impacto de activos y Nivel de aceptacin del Riesgo = Valor de activos Integridad Confidencial, y viabilidad Impacto de Activos = Impacto en los procesos de Negocio y Tolerancia al Riesgo = Probabilidad de Amenaza explotacin de la vulnerabilidad Medida de clculo de Riesgo: Valor de Activos BIA * Amenaza * Vulnerabilidad = Riesgo Medida. Dnde BIA Valor de activos es una medida de 0 a 5, donde el propietario de los activos es necesario para identificar las consecuencias para los negocios de una violacin del peor caso de la confidencialidad, integridad o disponibilidad. Se visualiza los Riesgos como la prdida de reputacin, el inters de los medios de comunicacin, la sensibilidad de los datos, prdida financiera, etc. La amenaza se basa la evaluacin de la amenaza inicial a una lista de amenazas que se han extrado de la norma ISO / IEC 27001:2005, sus vulnerabilidades asociadas. Escala de 1 a 3 Vulnerabilidad: El control de la corriente y la vulnerabilidad (riesgo de vulnerabilidad se aproveche) situacin dentro de la empresa en relacin con la amenaza identificada se evala. Escala de 1 a 5. Esto proporciona una medida de riesgo 0 a 75 con el fin de tomar decisiones sobre cmo abordar y controla: MUY BAJO 0-14. El bajo nivel de riesgo no justifica los controles adicionales estn poniendo en marcha. No hay actividad an ms necesaria. BAJA 15-24 El bajo nivel de riesgo no justifica los controles adicionales estn poniendo en marcha. No hay actividad an ms necesaria. MEDIUM 25-45 Gestin aplicarn su criterio en cuanto a si los riesgos son aceptables. Los controles se aplicarn, segn proceda. ALTO 46-60 Administracin, seleccionar los controles adecuados. MUY ALTO 61-75 Alto Riesgo - Gestin seleccionar los controles adecuados como una prioridad. En la norma ISO 31000, el control se define como una "medida que est modificando riesgo". La norma tambin define que "la organizacin debe asegurarse de que haya rendicin de cuentas, la autoridad y las competencias adecuadas para la gestin de riesgos, incluyendo la implementacin y el mantenimiento del proceso de gestin de riesgos y garantizar la adecuacin, efectividad y eficiencia de todos los controles. " Si una organizacin tiene que implementar de manera eficiente y efectiva lo que la norma define anteriormente para los controles, cuntos controles se pueden gestionar con realismo en la organizacin. La experiencia es que no puede haber muchos miles, por ejemplo, 10.000 ms, ya que una industria se crear dentro de una organizacin, si tiene que asegurar regularmente la adecuacin, eficacia y eficiencia de los 10.000 controles ms. Si una organizacin capta 10.000 ms controles, pero es solamente puede garantizar regularmente la adecuacin, eficacia y eficiencia de un pequeo subconjunto de los controles, entonces hay un punto en la documentacin de todos los controles? Por qu gastar todo el tiempo tratando de definir / documentar cada control, cuando no se puede encontrar en cualquier punto dado cuntos de ellos estn trabajando o no funciona. en el contexto de las grandes organizaciones
ITCP-CERBESA |
54
10 de diciembre de 2012
donde las decisiones importantes se tienen que hacer en trminos de cuntos controles para capturar, evaluar y vigilar la aplicacin efectiva de la norma ISO 31000 estndar . Bastantes de las empresas (hasta 15000 empleados) que tratan de aplicar herramientas de evaluacin de riesgos como parte de su norma ISO 27001 la ejecucin del proyecto. El resultado es que por lo general toma mucho tiempo y dinero con muy poco efecto. En primer lugar, qu es en realidad la evaluacin de riesgos, y cul es su propsito? La evaluacin de riesgos es un proceso en el que una organizacin debe identificar los riesgos de seguridad de la informacin que determinan la probabilidad e impacto. Simplemente hablando, la organizacin debera reconocer a todos los problemas potenciales con su informacin, la probabilidad de que ocurran y qu consecuencias podra ser. El propsito de la evaluacin del riesgo es determinar qu controles son necesarios con el fin de disminuir el riesgo "la seleccin de los controles que se llama el proceso de tratamiento de riesgos y en la ISO 27001 son elegidos en el anexo A, que especifica 133 controles. La evaluacin de riesgos se lleva a cabo mediante la identificacin y evaluacin de los activos, vulnerabilidades y amenazas. Un activo es cualquier cosa que tenga valor para la organizacin "de hardware, software, personas, infraestructuras, datos (en varias formas y medios), proveedores y socios, etc. Una vulnerabilidad es una debilidad en un activo, proceso, control, etc., lo que podra ser explotado por una amenaza, una amenaza es una causa que puede causar dao a un sistema u organizacin. Un ejemplo de la vulnerabilidad es la falta de software anti-virus, una amenaza relacionada es el virus informtico. Sabiendo todo esto, si su empresa que realmente necesita una herramienta sofisticada para realizar la evaluacin de riesgos. Todo lo que necesitas es una hoja de clculo de Excel, buenos catlogos de vulnerabilidades y amenazas, y una buena metodologa de evaluacin de riesgos. La tarea principal es realmente para evaluar la probabilidad y el impacto, y eso no puede ser hecho por cualquier herramienta "es algo que los propietarios de activos, con el conocimiento de sus activos, tienen que pensar. La metodologa no est disponible de forma gratuita, pero se puede usar ISO 27005 estndar (que describe la evaluacin del riesgo y el tratamiento en detalle), o puede utilizar algunos otros sitios web de venta de la metodologa. Todo esto debera tomar mucho menos tiempo y dinero que la compra de una herramienta de evaluacin de riesgos y aprender a usarlo. Una buena metodologa debe contener un mtodo para la identificacin de activos, amenazas y vulnerabilidades, tablas para el marcado de la probabilidad y el impacto, un mtodo para el clculo del riesgo, y definir el nivel de riesgo aceptable. Catlogos debe contener al menos 30 vulnerabilidades y amenazas 30, algunos contienen incluso unos pocos cientos de cada uno, pero eso es probablemente demasiado para una empresa. El proceso no es muy complicado "estos son los pasos bsicos para la evaluacin y tratamiento: Definir y documentar la metodologa (incluyendo los catlogos), la distribuir a todos los propietarios de activos de la organizacin Organizar entrevistas con todos los propietarios de activos durante el cual se deben identificar los activos y las vulnerabilidades y amenazas relacionadas, y en el segundo paso pedirles que evaluar la probabilidad y el impacto si los riesgos particulares debera ocurrir.
ITCP-CERBESA |
55
10 de diciembre de 2012
Consolidar los datos en una sola hoja de clculo , calcular los riesgos e indican que los riesgos no son aceptables para cada riesgo que no es aceptable, seleccione uno o varios controles del Anexo A de la norma ISO 27001 "calcular lo que el nuevo nivel de riesgo sera despus de los controles se llevan a cabo.
En conclusin: la evaluacin del riesgo y el tratamiento realmente son la base de la informacin de seguridad / ISO 27001, pero no quiere decir que tengan que ser complicado. Se puede hacer de una manera sencilla, y su sentido comn es lo que realmente cuenta. Lo anteriormente expresado nos ha llevado a proponer lineamientos que consideren los aspectos fundamentales de ISO 27001, ISO 27002, ISO 27005, ISO 20000, COBIT 5.0, COSO, ITIL V3 y BS 25999, entre otros, con el fin de plantear una ruta estratgica que le ofrezca a las organizaciones la capacidad para estar mejor preparada ante un entorno cambiante y de alto riesgo. MEGERIT es una metodologa de evaluacin riesgo ampliamente aceptado y est relacionada a la ISO 27005. Algunas definiciones tiles: Riesgo: combinacin de la probabilidad de un evento y de su consecuencia Amenaza: Una causa potencial de un incidente indeseado, que puede dar lugar a daos a un sistema o a una organizacin Vulnerabilidad: Una debilidad de un activo o de un grupo de activos que puede ser explotada por una o ms amenazas Valoracin de riesgo: proceso de comparacin de riesgos estimados respecto a los criterios de riesgos dados, para determinar la magnitud del riesgo. Tratamiento de riesgo: proceso de seleccin e implementacin de medidas (controles) para modificar el riesgo Control: Medio de gestionar el riesgo, incluyendo polticas, procedimientos, recomendaciones, prcticas o estructuras de la organizacin, que pueden ser de naturaleza administrativa, tcnica, de gestin o legal
ITCP-CERBESA |
56
10 de diciembre de 2012
Grupo de Procesos de gestin holstico que identifica amenazas potenciales a la organizacin sus impactos a la operacin del negocio que esas amenazas, en caso de realizarse, pudieran causar y provee una estructura para construir resiliencia (es la capacidad de un sistema organizacional de soportar y recuperarse ante desastres y perturbaciones) organizacional con la capacidad para la efectiva respuesta salvaguardando los intereses de las principales partes interesadas, reputacin y prestigio de la organizacin, marca y actividades que crean valor.
ITCP-CERBESA |
57
10 de diciembre de 2012
10 de diciembre de 2012
Un plan de recuperacin ante desastres (del ingls Disaster Recovery Plan) es un proceso de recuperacin que cubre los datos, el hardware y el software crtico, para que un negocio pueda comenzar de nuevo sus operaciones en caso de un desastre natural o causado por humanos. Esto tambin debera incluir proyectos para enfrentarse a la prdida inesperada o repentina de personal clave, aunque esto no sea cubierto en este artculo, el propsito es la proteccin de datos. Con el crecimiento de la tecnologa de informacin y la confianza sobre datos cruciales, el panorama ha cambiado en aos recientes a favor de la proteccin de datos irreemplazables. Esto es evidente sobre todo en la tecnologa de informacin; con los sistemas de ordenadores ms grandes que sostienen informacin digital para limitar prdida de datos y ayudar recuperacin de datos. Se cree que algunas empresas gastan hasta el 25 % de su presupuesto en proyectos de recuperacin de desastre, sin embargo, esto lo hacen para evitar prdidas ms grandes. De las empresas que tenan una prdida principal de registros automatizados el 43 % nunca vuelve a abrir, el 51 % cierra en menos de dos aos, y slo el 6 % sobrevivir el largo plazo. El mercado de proteccin de datos existente es caracterizado por varios factores: El permanente cambio de las necesidades de los clientes determinado por el crecimiento de datos, asuntos regulatorios y la creciente importancia de tener rpido acceso a los datos conservndolos en lnea. Respaldar los datos de vez en cuando teniendo tecnologas de cintas convencionales de reservas. Como el mercado de recuperacin de desastre sigue sufriendo cambios estructurales significativos, este cambio presenta oportunidades para las empresas de la nueva generacin a que se especialicen en la planificacin de continuidad de negocio y la proteccin de datos fuera de sitio. Continuidad del Negocio es un concepto que abarca tanto la Planeacin para Recuperacin de Desastres (DRP) como la Planeacin para el Restablecimiento del Negocio. Recuperacin de Desastres es la capacidad para responder a una interrupcin de los servicios mediante la implementacin de un plan para restablecer las funciones crticas de la organizacin (es decir la parte operativa del negocio). Ambos se diferencian de la Planeacin de Prevencin de Prdidas, la cual implica la calendarizacin de actividades como respaldo de sistemas, autenticacin y autorizacin (seguridad), revisin de virus y monitoreo de la utilizacin de sistemas (principalmente para verificaciones de capacidad). En esta ocasin hablaremos sobre la importancia de contar con la capacidad para restablecer la infraestructura tecnolgica de la organizacin en caso de una disrupcin severa. Constantemente se experimentan situaciones de emergencia, directa o indirectamente, las cuales se manifiestan en respuestas equvocas ocasionadas por el temor, miedo o un extremoso pnico aterrador. Frecuentemente los administradores o responsables de los sistemas de cmputo empiezan a tomar en cuenta la seguridad de su sistema despus de haber sido objeto de un ataque, dando como resultado la prdida de informacin, horas de trabajo, incluso dinero. La seguridad en el trabajo es uno de los factores ms importantes que garantizan el crecimiento de la productividad. Velar por la seguridad fsica y lgica no es una tarea que se efecte una sola vez y garantice su eficiencia por siempre. Para mantener la seguridad se requiere realizar peridicamente tareas preventivas. El establecimiento de procedimientos y medidas de seguridad estn destinados a salvaguardar la unidad administrativa, el centro de cmputo su estructura fsica, al personal, sus procedimientos operacionales, la informacin y documentacin generada contra cualquier evento natural o humano que de forma intencional o por accidente puedan afectarlos.
ITCP-CERBESA |
59
10 de diciembre de 2012
8.7.- RPO.
Punto Objetivo de Recuperacin (RPO, Recovery Point Objective) es cuando la infraestructura, ya comenzada nuevamente, comenzar a hacerse evidente. Bsicamente, RPO significa lo que la organizacin est dispuesta a perder en cantidad de datos. Para reducir un RPO es necesario aumentar el sincronismo de rplica de datos.
8.8.- RTO.
Tiempo Objetivo de Recuperacin (RTO, Recovery Time Objective) es el tiempo que pasar una infraestructura antes de estar disponible. Para reducir el RTO, se requiere que la Infraestructura (Tecnolgica, Logstica, Fsica) est disponible en el menor tiempo posible pasado el evento de interrupcin.
ITCP-CERBESA |
60
10 de diciembre de 2012
ITCP-CERBESA |
61
10 de diciembre de 2012
ITIL se centra en brindar servicios de alta calidad para lograr la mximo satisfaccin del cliente a un costo manejable. Para ello, parte de un enfoque estratgico basado en el tringulo procesos / personas / tecnologa. En otras palabras: determina la forma de ejecutar procesos estndar ayudados de la tecnologa para lograr la satisfaccin de las personas, usuarios de los servicios de TI. Desarrollar la Estrategia de los Servicios de TI. Desarrollar Estrategia de los Servicios. 1. Definir el Mercado. 2. Desarrollar los Ofrecimientos. 3. Desarrollar Recursos Estratgicos. 4. Preparar para Ejecucin (Anlisis Estratgico). Desarrollar Economa de los Servicios. 5. Administrar Finanzas. 6. Evaluar Retorno de la Inversin. 7. Administrar el Portafolio de Servicios. 8. Administrar la Demanda. Desarrollar Organizacin. 9. Desarrollar Estilo de la Organizacin. 10. Departamentalizar y Definir Funciones de la Organizacin. 11. Disear la Organizacin. 12. Desarrollar la Cultura Organizacional. 13. Desarrollar Estrategias de Aprovisionamiento de Servicios. Implementar Tcticas. 14. Relacionar Estrategia con Diseo de Servicios. 15. Relacionar Estrategia con Transicin de Servicios. 16. Relacionar Estrategia con Operacin de Servicios. 17. Relacionar Estrategia con Mejora Continua de Servicios. Desarrollar el Diseo de los Servicios: 18. Administrar el Catlogo de Servicios. 19. Administrar Niveles de Servicio. 20. Administrar Capacidades de Recursos. 21. Administrar Disponibilidades de Servicios. 22. Administrar la Continuidad del Servicio de TI. 23. Administrar la Seguridad de Informacin. 24. Administrar Proveedores de Servicios. 25. Administrar Ingeniera de Requerimientos. 26. Administrar Datos e Informacin. 27. Administrar las Aplicaciones. Desarrollar la Transicin de los Servicios: 28. Planear la Transicin y Soporte. 29. Administrar Cambios. 30. Administrar Recursos y Configuraciones. 31. Administrar Liberaciones e Implementaciones. 32. Validar Servicios y Pruebas. 33. Evaluar Servicios de Transicin. 34. Administrar Conocimientos. 35. Administrar Comunicaciones y Compromisos. ITCP-CERBESA | 62
10 de diciembre de 2012
36. Administrar Organizacin y Cambio. 37. Administrar Relaciones con Interesados. Desarrollar la operacin y continuidad de los Servicio: 38. Administracin de Eventos. 39. Administracin de Incidentes 40. Atender Requisiciones de Servicios 41. Administracin de Problemas. 42. Administracin de Accesos. Desarrollar la Mejora Continua de los Servicios de TI. 43. Mejorar Continuamente los Servicios. 44. Reportar Actividades de Servicios. 45. Realizar Medicin de los Servicios. 46. Calcular Retorno de Inversiones de MCS. ITIL se enfoca en velar por la disponibilidad de los servicios, por ende sus procesos se enfocan en soportar dicha disponibilidad, para lo cual tomo como referencia la Matriz RACSI que le permite a la organizacin tener claro las funciones de cada uno de los integrantes del equipo, de esta manera poder soportar el catlogo de servicios en funcin de los procesos respectivos.
Por otro lado, la gestin de servicios con ITIL tiene su columna vertebral en la funcin de Service Desk, la cual es el punto nico de contacto entre la organizacin y el usuario o cliente del servicio.
10 de diciembre de 2012
Tener un sistema de gestin de servicios basado en ITIL permitir a la compaa lograr: 1. Mayor alineamiento de TI con el negocio / enfoque a clientes: Los procesos ITIL estn dirigidos a maximizar la disponibilidad de los servicios TI con el propsito de lograr la satisfaccin de los clientes y cumplir con los acuerdos de nivel de servicio acordados 2. Resolucin de incidencias y problemas ms rpida y eficiente: Al tener una posicin proactiva hacia la resolucin rpida y eficaz de incidentes y a la vez hacia la prevencin de los mismos, se logra tambin la satisfaccin de los clientes 3. Reduccin del nmero de llamadas al Service Desk: Las mejores prcticas de ITIL establecen los procesos necesarios no solo para resolver incidentes, sino para aprender de ellos y lograr tener una base de conocimientos (llamada por ITIL: Known Error Database) con la que la organizacin logra una mejora continua minimizando cada vez el nmero de incidentes y la carga de trabajo del Service Desk. 4. Aumento del ratio de resolucin de incidencias en primera instancia: Organizando adecuadamente los niveles de escalamiento de incidentes en el Service Desk, se logra maximizar el tiempo de respuesta y resolucin desde que se comunica el incidente en el servicio TI hasta su resolucin 5. Implantacin de cambios ms rpida / mejor control de cambios: De igual manera, gracias al proceso de gestin de cambios de ITIL, se pueden administrar los cambios requeridos en la infraestructura TI que se generan a raz de algn incidente determinado. El correcto manejo de los cambios garantiza la calidad y estabilidad de los servicios TI 6. Reduccin del nmero de cambios que necesiten ser revocados: Igualmente, con una correcta gestin de cambios, que cuente con revisiones de la Junta de cambios y el cliente, se minimizarn los posibles problemas que puedan surgir a raz de los mismos y los malos entendidos respecto a dichos cambios entre la organizacin y el cliente.
COBIT est conformado por cuatro dominios, cada uno de los cuales estn organizados en procesos (34 en total) que su vez se sub-dividen en actividades y objetivos de control Planificacin y organizacin: Que est compuesta por todas las actividades que definen las estrategias y tctica de TI basado en los objetivos de negocio de la empresa. Se define adems la infraestructura de TI adecuada y necesario Adquisicin e implementacin: Donde se encuentran las actividades para la ejecucin del plan de TI previamente definido. Entrega y soporte: Dominio que comprende la entrega de los servicios requeridos y el establecimiento de procesos de soporte. Monitoreo y evaluacin: Donde se realizan las actividades de inspeccin y monitoreo de los procesos de TI.
Los procesos de estos dominios de COBIT se implantan dentro de las polticas y especificaciones de requerimientos de negocio, determinados por los criterios de la informacin, los cuales establecen los niveles de rendimiento en cada uno de los siguientes aspectos: Eficiencia ITCP-CERBESA | 64
Estos criterios deben ser tomados en cuanto al momento de ejecutar los procesos COBIT y al momento de monitorear los diversos recursos de TI con los que cuenta la compaa (aplicaciones, informacin, infraestructura y personas). Estos nos dan un marco completo de trabajo para gestionar y controlar las TI y poder maximizar los beneficios de las TI para con la organizacin. Ac existen un conjunto de normas ISO que apoyan la certificacin del tema de seguridad de la informacin y van desde la ISO 17999 hasta la 27000 y sus diferentes captulos.
ITCP-CERBESA |
65
10 de diciembre de 2012
Nivel 0: Incompleto o El proceso no se realiza, o no se consiguen sus objetivos Nivel 1: Inicial o ejecutado: o Este es el nivel en donde estn todas las empresas que no tienen procesos: es donde el proceso se ejecuta y se logra su objetivo, as sea fuera de presupuesto y de cronograma. o En este nivel de madurez, el desarrollo del proyecto es totalmente opaco, no se sabe lo que pasa en l. Nivel 2: Repetible: o Se da cuando el xito de los resultados obtenidos se puede repetir o La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo, se decir: adems de ejecutarse, el proceso se planifica, se revisa y se evala para comprobar que cumple los requisitos. o El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Nivel 3: Definido: o Significa que la forma de desarrollar proyectos est definida, establecida, documentada y que existen mtricas (obtencin de datos objetivos) para la consecucin de objetivos concretos Nivel 4: Administrado o Los proyectos usan objetivos medibles y cuantificables para alcanzar cubrir las necesidades de los clientes y la organizacin. Es decir, se usan mtricas para gestionar la organizacin. Nivel 5: Optimizado o Los procesos de los proyectos y de la organizacin estn orientados a la mejora de las actividades, que mediante mtricas son identificadas, evaluadas y puestas en prctica.
La mayora de las empresas que llegan solo hasta el nivel 3, ya que es un nivel con el cual muchas empresas no ven la necesidad de ir ms all. Por otro lado, normalmente las empresas que intentan alcanzar los niveles 4 y 5, lo realizan simultneamente ya que estn muy relacionados. Cabe acotar nuevamente que el objetivo principal de estos niveles de madurez es lograr un nivel de estandarizacin adecuado para cada proyecto respecto a sus procesos de desarrollo de software, con la finalidad de gestionar los proyectos de software adecuadamente y as lograr cumplir con los objetivos planificados para dicho proyecto. Es importante recordar tambin que lo primordial no es lograr la certificacin de los procesos de la organizacin sino lograr una institucionalizacin de dichos procesos estandarizados que conlleven a la realizacin de los objetivos definidos. ITCP-CERBESA | 66
10 de diciembre de 2012
ITCP-CERBESA |
67
10 de diciembre de 2012
Val IT est compuesto por tres procesos que se muestran en el siguiente grfico:
ITCP-CERBESA |
68
10 de diciembre de 2012
Value Governance: Este proceso establece el marco de trabajo general, la direccin estratgica necesaria, las caractersticas deseadas del portafolio de inversiones as como las restricciones sobre las cuales basarse al momento de decidir las inversiones Investment management: En este proceso de Val IT, basados en los requerimientos de negocio, se definen los programas de inversin y se realiza una valoracin de los mismos para determinar si son enviados al proceso de gestin de portafolios para su evaluacin correspondiente desde el punto de vista del alineamiento a la objetivos estratgicos, nivel de riesgos permitidos y generacin de valor para el negocio. Portafolio management: Este proceso evala y prioriza los programas basado en las restricciones de recursos y costos, y transfiere los proyectos seleccionados al portafolio activo de la compaa para su ejecucin.
10 de diciembre de 2012
Equilibrar los costos y beneficios de la gestin de riesgos de TI Promover la comunicacin justa y abierta de los riesgos de TI Establecer el tono adecuado en la parte superior, mientras que la definicin y la aplicacin de la rendicin de cuentas son un proceso continuo y parte de las actividades diarias.
Componentes de la comunicacin de los riesgos de TI El mayor riesgo de TI y los flujos de comunicacin son los siguientes: Expectativa: lo que la organizacin espera resultado como definitivo y lo que es el comportamiento esperado de los empleados y la gestin, sino que abarca la estrategia, las polticas, procesos, procedimientos, formacin sobre sensibilizacin de cada usuario y sus jerarquas, as como la sensibilizacin del personal de TI. Capacidad: indica cmo la organizacin es capaz de gestionar el riesgo. Estado: la informacin de la situacin real de los riesgos de TI, sino que abarca el perfil de riesgo de la organizacin, indicador de riesgo clave, eventos, causa raz de los siniestros. Una comunicacin eficaz debe ser: Concientizar Concisa til Oportuna Dirigida a la audiencia correcta Disponible en una necesidad de saber base Procesos de dominios en los Riesgos de TI: Los tres dominios del riesgo que se enumeran a continuacin se enmarcan con los que figuran los procesos (tres por dominio), cada proceso contienen una serie de actividades: Gobierno, Riesgo, Asegrese de que los riesgos de TI prcticas de gestin estn integrados en la empresa, lo que le permite conseguir una ptima rentabilidad ajustada al riesgo.
10 de diciembre de 2012
Desde el momento en que nuestra computadora se conecta a Internet, se abren ante nosotros toda una nueva serie de posibilidades (Derechos y Obligaciones), sin embargo stas traen consigo toda una serie de nuevos y en ocasiones complejos tipos de ataque. Ms aun, mientras en un ordenador aislado el posible origen de los ataques o amenazas es bastante restringido, al conectarnos a Internet, cualquier usuario de cualquier parte del mundo puede considerar nuestro sistema un objetivo apetecible (Vulnerabilidades). Existe un acuerdo y conciencia general sobre la importancia de la Seguridad de los Sistemas de Informacin (denominado SSI). La SSI est relacionada con la disponibilidad, confidencialidad e integridad de la informacin tratada por las computadoras y las redes de comunicacin. Se usan comnmente otros trminos que en esencia tienen el mismo significado, tales como seguridad de la informacin, seguridad de las computadoras, seguridad de datos o proteccin de la informacin, pero en aras de la consistencia, usaremos el trmino Seguridad de los Sistemas de Informacin. INFORMACIN Y SISTEMA INFORMTICO ASPECTOS CLAVE EN LA SSI DEFINICIN DE SEGURIDAD INFORMTICA Confidencialidad Integridad Disponibilidad Autenticidad Imposibilidad de rechazo Consistencia Aislamiento Auditora POLTICA DE SEGURIDAD ANLISIS Y GESTIN DE RIESGOS VULNERABILIDAD, AMENAZAS Y CONTRAMEDIDAS Vulnerabilidad Amenaza Contramedida TIPOS DE VULNERABILIDAD Vulnerabilidad fsica Vulnerabilidad natural Vulnerabilidad del hardware y del software Vulnerabilidad de los medios o dispositivos Vulnerabilidad por emanacin Vulnerabilidad de las comunicaciones Vulnerabilidad humana TIPOS DE AMENAZAS Intercepcin Modificacin Interrupcin Generacin Amenazas naturales o fsicas Amenazas involuntarias Amenazas intencionadas TIPOS DE MEDIDAS DE SEGURIDAD O CONTRAMEDIDAS Medidas fsicas Medidas lgicas Medidas administrativas Medidas legales PLANES DE CONTINGENCIA PRINCIPIOS FUNDAMENTALES DE LA SEGURIDAD INFORMTICA Principio de menor privilegio La seguridad no se obtiene a travs de la oscuridad ITCP-CERBESA | 71
10 de diciembre de 2012
Principio del eslabn ms dbil Defensa en profundidad Punto de control centralizado SEGURIDAD EN CASO DE FALLO Participacin universal Simplicidad
Necesidades Negocio
Estrategia Comites Corporativos. Gestion de Ciclos Procesos Negocio.
Gobierno TI
ITIL CMMI PMI COBIT SOA
Estrategia Negocio
PMO R&A PE
Por ello, un buen Gobierno de TI permite tener un sistema en el cual todos los involucrados, incluyendo a los miembros de la Alta Gerencia, empleados y responsables de los dems departamentos de la compaa tengan el input necesario en el proceso de toma de decisiones. Esto previene el divorcio entre objetivos de TI y objetivos de negocio. Adems previene que usuarios crticos de los servicios TI protesten por no tener un sistema que rinda segn sus expectativas. Entonces, para definir lo que es Gobierno de TI, se pueden ensayar con varios conceptos propuestos por distintas instituciones: Para ITGI: Es el proceso de administracin que asegura la obtencin de los beneficios esperados de la tecnologa de informacin (TI) de manera controlada para acrecentar el xito sostenido de una empresa a largo plazo Para ISACA: Es el uso eficiente de los recursos de TI para apoyar el cumplimiento de los objetivos del negocio
ITCP-CERBESA |
72
10 de diciembre de 2012
Para el Australian Standard for Corporate Governance : Sistema por el cual el uso presente y futuro de las TI es controlado . Involucra evaluar y dirigir planes del uso de las TI que soporten a la organizacin, as como monitorear el uso de estos planes. Incluye adems polticas y estrategias de uso de TI en la organizacin. De estos conceptos podemos rescatar los siguientes puntos que determinan un bueno gobierno de TI: Es un proceso. Asegura la obtencin de los beneficios esperados de las TI. Mediante el uso de los recursos de TI. Que involucren planes que soporten a la organizacin. Para acrecentar el xito sostenido de la misma. Se recalca entonces al bueno Gobierno de TI como un proceso para obtener beneficios que incrementen el xito de la compaa, usando la infraestructura de TI adecuada con los planes y proyectos adecuados. Con un buen gobierno de TI, la organizacin puede dar respuesta a las siguientes interrogantes: Cmo puede la Alta Gerencia lograr que su organizacin TI devuelva valor de negocio a la compaa? Cmo puede la Alta Gerencia lograr que su organizacin TI no invierta en proyectos equivocados? Cmo puede la Alta Gerencia controlar su organizacin TI?
ITCP-CERBESA |
73
10 de diciembre de 2012
Compromiso de la direccin
La direccin de la organizacin debe comprometerse con el establecimiento, implementacin, operacin, monitorizacin, revisin, mantenimiento y mejora del SGSI. Para ello, debe tomar las siguientes iniciativas: Establecer una poltica de seguridad de la informacin. Asegurarse de que se establecen objetivos y planes del SGSI. Establecer roles y responsabilidades de seguridad de la informacin. Comunicar a la organizacin tanto la importancia de lograr los objetivos de seguridad de la informacin y de cumplir con la poltica de seguridad, como sus responsabilidades legales y la necesidad de mejora continua. Asignar suficientes recursos al SGSI en todas sus fases. Decidir los criterios de aceptacin de riesgos y sus correspondientes niveles. Estructurar los DNA de confidencialidad con el personal de la organizacin. Asegurar que se realizan auditoras internas. Realizar revisiones del SGSI, como se detalla ms adelante.
Asignacin de recursos
Para el correcto desarrollo de todas las actividades relacionadas con el SGSI, es imprescindible la asignacin de recursos. Es responsabilidad de la direccin garantizar que se asignan los suficientes para: Establecer, implementar, operar, monitorizar, revisar, mantener y mejorar el SGSI. Garantizar que los procedimientos de seguridad de la informacin apoyan los requerimientos de negocio. Identificar y tratar todos los requerimientos legales y normativos, as como las obligaciones contractuales de seguridad. ITCP-CERBESA | 74
10 de diciembre de 2012
Aplicar correctamente todos los controles implementados, manteniendo de esa forma la seguridad adecuada. Realizar revisiones cuando sea necesario y actuar adecuadamente segnlos resultados de las mismas. Mejorar la eficacia del SGSI donde sea necesario. Incorporar la Tecno vigilancia dentro del plan de trabajo.
Formacin y concienciacin
La formacin y la concienciacin en seguridad de la informacin son elementos bsicos para el xito de un SGSI. Por ello, la direccin debe asegurar que todo el personal de la organizacin al que se le asignen responsabilidades definidas en el SGSI est suficientemente capacitado. Se deber: Determinar las competencias necesarias para el personal que realiza tareas en aplicacin del SGSI. Satisfacer dichas necesidades por medio de formacin o de otras acciones como, p. ej., contratacin del personal ya formado. Evaluar la eficacia de las acciones realizadas. Mantener registros de estudios, formacin, habilidades, experiencia y cualificacin. Adems, la direccin debe asegurar que todo el personal relevante est concienciado de la importancia de sus actividades de seguridad de la informacin y de cmo contribuye a la consecucin de los objetivos del SGSI. Informar de la Ingenieria Social utilizada para extraer informacin.
Recomendaciones de mejora.
Basndose en todas estas informaciones, la direccin debe revisar el SGSI y tomar decisiones y acciones relativas a: Mejora de la eficacia del SGSI. Actualizacin de la evaluacin de riesgos y del plan de tratamiento de riesgos. Modificacin de los procedimientos y controles que afecten a la seguridad de la informacin, en respuesta a cambios internos o externos en los requisitos de negocio, requerimientos de seguridad, procesos de negocio, marco legal, obligaciones contractuales, niveles de riesgo y criterios de aceptacin de riesgos. Necesidades de recursos. Mejora de la forma de medir la efectividad de los controles.
10.3.- SGSI.
Sistema de Gestin de la Seguridad de la Informacin
El SGSI (Sistema de Gestin de Seguridad de la Informacin) es el concepto central sobre el que se construye ISO 27001.La gestin de la seguridad de la informacin debe realizarse mediante un proceso sistemtico, documentado y conocido por toda la organizacin. Este proceso es el que constituye un SGSI, que podra considerarse, por analoga con una norma tan conocida como ISO 9001, como el sistema de calidad para la seguridad de la informacin. Garantizar un ITCP-CERBESA | 75
10 de diciembre de 2012
nivel de proteccin total es virtualmente imposible, incluso en el caso de disponer de un presupuesto ilimitado. El propsito de un sistema de gestin de la seguridad de la informacin es, por tanto, garantizar que los riesgos de la seguridad de la informacin sean conocidos, asumidos, gestionados y minimizados por la organizacin de una forma documentada, sistemtica, estructurada, repetible, eficiente y adaptada a los cambios que se produzcan en los riesgos, el entorno y las tecnologas.
Qu es un SGSI?
SGSI es la abreviatura utilizada para referirse a un Sistema de Gestin de la Seguridad de la Informacin. ISMS es el concepto equivalente en idioma ingls, siglas de Information Security Management System. En el contexto aqu tratado, se entiende por informacin todo aquel conjunto de datos organizados en poder de una entidad que posean valor para la misma, independientemente de la forma en que se guarde o transmita (escrita, en imgenes, oral, impresa en papel, almacenada electrnicamente, proyectada, enviada por correo, fax o e-mail, transmitida en conversaciones, etc.), de su origen (de la propia organizacin o de fuentes externas) o de la fecha de elaboracin. La seguridad de la informacin, segn ISO 27001, consiste en la preservacin de su confidencialidad, integridad y disponibilidad, as como de los sistemas implicados en su tratamiento, dentro de una organizacin. As pues, estos tres trminos constituyen la base sobre la que se cimienta todo el edificio de la seguridad de la informacin: Confidencialidad: la informacin no se pone a disposicin ni se revela a individuos, entidades o procesos no autorizados. Integridad: mantenimiento de la exactitud y completitud de la informacin y sus mtodos de proceso. Disponibilidad: acceso y utilizacin de la informacin y los sistemas de tratamiento de la misma por parte de los individuos, entidades o procesos autorizados cuando lo requieran. Para garantizar que la seguridad de la informacin es gestionada correctamente, se debe hacer uso de un proceso sistemtico, documentado y conocido por toda la organizacin, desde un enfoque de riesgo empresarial. Este proceso es el que constituye un SGSI.
ITCP-CERBESA |
76
10 de diciembre de 2012
El Sistema de Gestin de la Seguridad de la Informacin (SGSI) ayuda a establecer estas polticas y procedimientos en relacin a los objetivos de negocio de la organizacin, con objeto de mantener un nivel de exposicin siempre menor al nivel de riesgo que la propia organizacin ha decidido asumir. Con un SGSI, la organizacin conoce los riesgos a los que est sometida su informacin y los asume, minimiza, transfiere o controla mediante una sistemtica definida, documentada y conocida por todos, que se revisa y mejora constantemente.
Identificar y Analizar
Identificar :
Activos. Amenazas. Vulnerabilidade s.
Planificar
Definir: Alcance Politica Metodologia
Gestin de Riesgos
ITCP-CERBESA |
77
10 de diciembre de 2012
ISM3 pretende cubrir la necesidad de un estndar simple y aplicable de calidad para sistemas de gestin de la seguridad de la informacin. ISM3 proporciona un marco para ISM que puede utilizarse tanto por pequeas organizaciones que realizan sus primeros esfuerzos, como a un nivel alto de sofisticacin por grandes organizaciones como parte de sus procesos de seguridad de la informacin... Al igual que otros estndares del ISECOM, ISM3 se proporciona con una licencia de cdigo libre, tiene una curva de aprendizaje suave, y puede utilizarse para fortalecer sistemas ISM en organizaciones que utilicen estndares como COBIT, ITIL, CMMI y ISO17799. Est estructurado en niveles de madurez, de modo que cada organizacin puede elegir un nivel adecuado para su negocio, y cubrir ese objetivo en varias etapas. En lugar de depender exclusivamente de mtodos caros de anlisis de riesgos, que suponen una barrera a la implantacin de sistemas de ISM, ISM3 sigue un punto de vista cualitativo, empezando por analizar los requerimientos de seguridad del negocio. Permite a la empresa aprovechar la infraestructura actual, fortalecindola mediante un sistema de calidad, y alcanzado niveles de madurez certificables segn el sistema de ISM evoluciona. Utiliza un modelo de gestin para diferenciar las tareas de seguridad operativa que previenen y mitigan incidentes de las tareas estratgicas y tcticas que identifican los activos a proteger, las medidas de seguridad a emplear, y los recursos que han de dedicarse a estas. Se describe un proceso de certificacin que permite a una organizacin autoevaluar su madurez, o bien obtener una certificacin de un auditor independiente. La publicacin de ISM3 v1.20 (Information Security Management Maturity Model, que se pronuncia ISM cubo) ofrece muchas ventajas para la creacin de sistemas de gestin de la seguridad de la informacin. ISM3 por s solo o para mejorar sistemas basados en ITIL, ISO27001 o COBIT. ISM3 pretende alcanzar un nivel de seguridad definido, tambin conocido como riesgo aceptable, en lugar de buscar la invulnerabilidad. ISM3 ve como objetivo de la seguridad de la informacin el garantizar la consecucin de objetivos de negocio. La visin tradicional de que la seguridad de la informacin trata de la prevencin de ataques es incompleta. ISM3 relaciona directamente los objetivos de negocio (como entregar productos a tiempo) de una organizacin con los objetivos de seguridad (como dar acceso a las bases de datos slo a los usuarios autorizados)... Algunas caractersticas significativas de ISM3 son: Mtricas de Seguridad de la Informacin - "Lo que no se puede medir, no se puede gestionar, y lo que no se puede gestionar, no se puede mejorar" - ISM3 v1.20 hace de la seguridad un proceso medible mediante mtricas de gestin de procesos, siendo probablemente el primer estndar que lo hace. Esto permite la mejora continua del proceso, dado que hay criterios para medir la eficacia y eficiencia de los sistemas de gestin de seguridad de la informacin. Niveles de Madurez ISM3 se adapta tanto a organizaciones maduras como a emergentes mediante sus cinco niveles de madurez, los cuales se adaptan a los objetivos de seguridad de la organizacin y a los recursos que estn disponibles. Basado el Procesos - ISM3 v1.20 est basado en procesos, lo que lo hace especialmente atractivo para organizaciones que tienen experiencia con ISO9001 o que utilizan ITIL como modelo de gestin de TIC. El uso de ISM3 fomenta la colaboracin entre proveedores y usuarios de seguridad de la informacin, dado que la externalizacin de procesos de seguridad se simplifica gracias a mecanismos explcitos, como los ANS y la distribucin de responsabilidades. Adopcin de las Mejores Prcticas Una implementacin de ISM3 tiene ventajas como las extensas referencias a estndares bien conocidos en cada proceso, as como la distribucin explcita de ITCP-CERBESA | 78
10 de diciembre de 2012
responsabilidades entre los lderes, gestores y el personal tcnico usando el concepto de gestin Estratgica, Tctica y Operativa. Certificacin Los sistemas de gestin basados en ISM3 pueden certificarse bajo ISO9001 o ISO27001, lo que quiere decir que se puede usar ISM3 para implementar un SGSI basado en ISO 27001. Esto tambin puede ser atractivo para organizaciones que ya estn certificadas en ISO9001 y que tienen experiencia e infraestructura para ISO9001. Accesible Una de las principales ventajas de ISM es que los Accionistas y Directores pueden ver con mayor facilidad la Seguridad de la Informacin como una inversin y no como una molestia, dado que es mucho ms sencillo medir su rentabilidad y comprender su utilidad.
ITCP-CERBESA |
79
10 de diciembre de 2012
ITCP-CERBESA |
80
10 de diciembre de 2012
h) Herramienta Tecnolgica de Administracin de Roles, identidades y Accesos (RIA) . Es aquella que permite automatizar una gran parte de las funciones asociadas con crear y modificar roles; crear y eliminar usuarios; otorgar accesos (lgicos) a los Servicios TI y a los Recursos Tecnolgicos y accesos (fsicos) a las instalaciones. i) Matriz RACSI. Matriz de responsabilidades asociadas a los Procesos del Gobierno de Roles, cuyas siglas corresponden a: R - el responsable de un Proceso; A - el que rinde cuentas de un Procesos; C - la persona consultada; S - la persona que ejecuta el Proceso; I - la persona informada.
10 de diciembre de 2012
Intranet corporativa, de la lnea de aplicaciones empresariales, corporativos mainframe, sistemas de correo electrnico y el gateway de Internet. Sus perfiles de identidad incluyen los datos relativos a su empleo y su ID de inicio de sesin a muchos a los sistemas internos. Insiders acceder a los componentes de su perfil de identidad, identificaciones de acceso especial a los diversos sistemas, muchas veces al da. Los forasteros son clientes de los bancos sobre todo los actuales y futuros. Sus perfiles pueden incluir desde una hasta tres IDs y contraseas de conexin - para Internet, banca telefnica y cajeros automticos basados en electrnicos. Sus perfiles incluyen informacin de los clientes, tales como una direccin postal y nmeros de cuenta. Los forasteros slo acceder a su ID de inicio de sesin de vez en cuando. Datos del perfil personal proporcionada por los forasteros, como el nombre completo, nmero de telfono o direccin de correo electrnico pueden ser inexactos.
ITCP-CERBESA |
82
10 de diciembre de 2012
Basado en mi experiencia y fruto de compartir esto con muchos alumnos y profesores, he llegado a la conclusin que realmente lo que existe es una quntuple restriccin. En concreto hablo de Objetivo, Coste, Alcance, Tiempo y Organizacin / recursos. El objetivo del proyecto si creo que es claro una restriccin ya que condiciona a las dems, sobre todo si este est bien definido (ya sabis tcnica SMART) y los recursos que dispongamos para la realizacin del
ITCP-CERBESA |
83
10 de diciembre de 2012
proyecto es otra restriccin clave, ya que nos condicionar bastante en la forma en la cual decidamos realizar el proyecto. Finalmente un factor adicional y clave para entender la complejidad de los proyectos, es que estos 5 factores no son estticos y que por tanto cambian a lo largo del recorrido de un proyecto derivados tanto de los condicionantes internos del proyecto como de los condicionantes externos, es decir del entorno tan cambiante que nos rodea.
10 de diciembre de 2012
Fases (es un proceso iterativo) en el proceso de gestin de riesgos: Fase Plan Gestin Riesgos Fase Identificacin de Riesgos Fase Anlisis de Riesgos Fase Planes Respuesta a Riesgos Fase Monitorizacin y Control Riesgos Fase Cierre Proceso Gestin Riesgos Cundo se lleva a cabo este proceso? En la elaboracin de una propuesta a un cliente, cuando se planifica el proyecto. A intervalos regulares durante la vida del proyecto: por ejemplo como parte de los informes de estado del proyecto. Cuando hay un cambio de alcance en el proyecto. En hitos o decisiones importantes del proyecto. Por tanto es un proceso iterativo y recurrente a lo largo de toda la vida del proyecto. Tipos de riesgo: Fuentes internas o externas de riesgos. Riesgos de negocio (se pierde o se gana), o riesgos puros (slo se pierde). Riesgos conocidos (se han identificado), o riesgos desconocidos (no han sido identificados). Otras muchos tipos: tcnicos, de gestin del proyecto, etc. Por qu gestionar riesgos? Cualquier empresa que oferta sus servicios a clientes, asume riesgos con el objetivo de ser ms competitivos, llegar primeros y conseguir dichos proyectos. Los proyectos son riesgo: Servicios personalizados al cliente. Nuevas soluciones y reas. No asumir riesgos = no conseguimos proyectos. Los clientes confan en nosotros para gestionar riesgos, por ello nos pagan, si no los asumiran ellos. Si realizamos gestin de riesgos proactivamente protegemos y mejoramos el beneficio de nuestra empresa. Una buena gestin de riesgos: Reduce el precio del proyecto. Mejora la satisfaccin del cliente. Incrementa la capacidad y probabilidades de xito. Nos hace la vida ms fcil en los proyectos. Disminuye drsticamente las sorpresas en los proyectos Tener aversin a los riesgos NO es gestin de riesgos. Con la gestin de riesgos ayudamos a nuestra empresa a conseguir los objetivos de negocio y proyecto, evitando problemas que podran causar prdidas inesperadas y no planificadas.
Si los requisitos del cliente generan riesgos, estos deben ser analizados, discutidos y negociados con el cliente: ITCP-CERBESA | 85
10 de diciembre de 2012
Esta discusin abierta ayuda a evitar sorpresas, retrasos o incremento en el coste. Demuestra al cliente que nuestra empresa entiende de gestin de riesgos. Alerta al cliente de reas de riesgo que pueden requerir de soluciones alternativas. En algunos casos, algunos riesgos pueden llegar a ser ofertados como opciones en otras propuestas o pueden ser la base de futuras gestiones de cambio (nuevas oportunidades de negocio).
ITCP-CERBESA |
86
10 de diciembre de 2012
El caso Econmico: optimiza el valor del dinero. Se analizan las diferentes alternativas para la obtencin del caso estratgico, incluido inclusive el no hacer nada como punto de partida, y se concluye con una lista de alternativas y qu rumbo tomar. El caso Comercial: es comercialmente viable. Si los dos aspectos anteriores son viables, es indispensable que se pueda lograr tanto la adquisicin de los insumos, como cualquier trato comercial que se deba hacer para ejecutar el proyecto. El caso Financiero: se puede costear financieramente. Se hacen los anlisis financieros correspondientes para garantizar que los beneficios no sern absorbidos por los costos, y que la inversin en el proyecto no desestabilizar la compaa. El caso Administrativo: se puede ejecutar con xito. Aqu se definen los procesos y procedimientos de cmo se estructurar el proyecto y como se administrar, para contener riesgos y garantizar el logro de los beneficios, dentro de los tiempos y costos estimados. Para facilitar la construccin de los casos de negocio, se sugiere abordarlo en tres etapas claramente identificables, que permitirn ir profundizando cada vez ms. En una primera etapa se detalla el esquema estratgico para definir claramente el alcance y los objetivos a lograr. La segunda etapa desarrolla el esquema del caso de negocio para ahondar en detalle en la parte financiera y en el anlisis de alternativas, y en una tercera y ltima etapa se completa el caso de negocio, detallando las actividades de ejecucin y garanta de logro de beneficios. El mayor beneficio que hemos encontrado en nuestra actividad para los casos de negocio, es que garantizan que el proyecto como un todo, resiste cambios normales dentro de los negocios, como cambios en gerentes, cambios en situaciones econmicas, y hasta permiten sobrellevar momentos de crisis que sin el caso de negocio, daran al traste con el proyecto. La elaboracin de una caso de Negocio o Ante proyecto permite establecer la magnitud de la inversin, as como realizar un diseo que permita determinar si es factible dicha inversin. La evaluacin de un Ante Proyecto es esencial para determinar si la inversin que se piensa realizar suplir las necesidades de la organizacin, basndose en el levantado de Alcances que se pretende dar a la necesidad misma. Para tal efecto es que es necesario realizar una serie de evaluaciones de tipo tcnico, econmico, funcionalidad, satisfaccin del usuario, beneficios a la empresa, y finalmente que se convierta en una inversin rentable que en el mediano o largo Plazo genere retornos de la inversin.
ITCP-CERBESA |
87
10 de diciembre de 2012
ITCP-CERBESA |
88
10 de diciembre de 2012
Customer relationship management (CRM) Business Process Management (BPM) Enterprice Performance Manager (EPM)
ITCP-CERBESA |
89
10 de diciembre de 2012
10 de diciembre de 2012
Al determinar cmo la tecnologa apoya el crecimiento de la compaa, se debe de considerar su posicin actual en el mercado y su norte en trminos de sus valores, principios, visin, misin, metas y objetivos; tener una misin definida ayudara a alcanzar con mayor precisin lo que falta y las necesidades futuras y la seleccin de las soluciones tecnolgicas adecuadas puede diferenciar entre ser un simple participante ms del mercado o ser el lder marcando la diferencia y ventaja competitiva con herramientas estratgicas empresariales. El manejo de la informacin y la rapidez para reaccionar a las necesidades del consumidor son las herramientas clave para el crecimiento de cualquier compaa, Aqu la tecnologa se convierte en el elemento estratgico para todos los niveles de la organizacin y para las fases de interaccin de sus miembros. La tecnologa mejora el perfil competitivo de las empresas y aumenta la productividad, la agilidad en la toma de decisiones, el manejo y el mejoramiento de la relacin con el cliente; sin embargo para incrementar las ganancias de una empresa, es imprescindible establecer un balance entre la tecnologa que desea adquirir y el presupuesto disponible. Por esto, la eleccin tecnolgica debe de buscar una solucin de tecnologas adaptables, escalables, productivas y accesibles, con una capacidad de soportar la evolucin y expansin de la compaa para cada una de las reas que la integran, y de acuerdo con su presupuesto y su visin, enfocndose en los retos que se presenten en el futuro. Con el presupuesto disponible y las necesidades por cubrir, deben de conocer las prioridades de la compaa y enfocarse en las reas principales: Almacenar data. Aumentar la Productividad. Reducir los costos. Analizar informacin oportuna. Se debe de disear la base para una infraestructura tecnolgica capaz de reaccionar y ajustarse a las demandas de la organizacin y del mercado, lo cual inicia con la adquisicin del equipo segn el plan estratgico corporativo. El presente documento servir como apoyo para la evaluacin de un sistema de gestin empresarial y a la alineacin de los procesos de negocio a las buenas prcticas de gestin, segn las necesidades de la empresa.
ITCP-CERBESA |
91
10 de diciembre de 2012
El tema de la gestin del cambio de costumbres a buenas prcticas es otra parte medular en este tipo de proyectos, adems de resaltar que no es un proyecto de Tecnologa sino un proyecto del Negocio.
ITCP-CERBESA |
92
10 de diciembre de 2012
ITCP-CERBESA |
93
10 de diciembre de 2012
Qu hacer? Identificar potenciales amenazas y desarrollar escenarios que muestren lo que podra suceder en el futuro. Examinar oportunidades que deben ser o podran ser explotadas. Iniciar debates honestos y dar razones convincentes para hacer a la gente pensar y hablar.
Qu hacer? Identificar los verdaderos lderes positivos de su organizacin. Pdales un compromiso emocional. Trabaje en equipo en la construccin del cambio. Realice un anlisis Stakeholder y de riesgos del equipo.
10 de diciembre de 2012
Qu hacer? Determine los valores que son fundamentales para el cambio Elabore un breve resumen que capture lo que ve como futuro de la organizacin Cree una estrategia para ejecutar esa visin Asegrese de que su coalicin pueda describir la visin en 5 o menos minutos Practique su declaracin de la visin a menudo.
Qu hacer? Hable a menudo de su visin de cambio Responda abierta y honestamente a las preocupaciones y ansiedades de la gente, elimine el ruido de posibles despidos, o retiros de personal. Aplique su visin en todos los aspectos operativos, desde el entrenamiento hasta la evaluacin de la performance. Ate todo a la visin Predique con el ejemplo
ITCP-CERBESA |
95
10 de diciembre de 2012
Qu hacer? Identifique o tome personas nuevas que sean lderes del cambio y cuyas funciones principales sean hacer el cambio. Mire la estructura orgnica, puestos, y sistemas de recompensas para asegurarse de que estn en consonancia con su visin. Reconozca y recompense a la gente que trabaja para el cambio Identifique a las personas que se resisten al cambio y aydeles a ver que lo necesitan Cree planes de Incentivo a la gente que alcance las metas del cambio y haga pblicos los incentivos.(Viajes a otros pases, premios, etc) Adopte medidas para eliminar las barreras (humanas o no)
Qu hacer? Busque proyectos de xito asegurado, que pueda implementar sin la ayuda de aquellos que sean crticos del cambio. No elija metas tempranas que sean costosas. Usted desea poder justificar la inversin de cada proyecto. Analice cuidadosamente los pros y contras de cada proyecto. Si no tiene xito en su primera meta, puede daar enteramente su iniciativa de cambio. Reconozca en pblico el esfuerzo de las personas que le ayudan a alcanzar los objetivos.
Qu hacer? Despus de cada victoria, analizar qu sali bien y qu se necesita mejorar. Fijarse ms metas para aprovechar el impulso que ha logrado. Aprenda sobre Demming, sobre la mejora continua y su PDAC (Plan, Do, Act, Check). Mantenga ideas frescas sumando ms agentes y lderes del cambio. ITCP-CERBESA | 96
10 de diciembre de 2012
Qu hacer? Hablar acerca de los avances cada vez que se d la oportunidad. Cuente historias de xito sobre procesos de cambio, y repetir otras historias que oiga. Incluye los ideales y valores del cambio cada vez que contrate y entrene gente nueva Reconozca pblicamente los principales miembros de su coalicin de cambio original, y asegrese de que el resto del personal (nuevo y viejo) se acuerden de sus contribuciones. Cree planes para sustituir a los lderes principales del cambio, a medida que stos se vayan. Esto ayudar a asegurar que su legado no se ha perdido u olvidado.
Puntos claves:
Tiene que trabajar duro para cambiar con xito a una organizacin. Visualice la arquitectura empresarial ptima. Cambie las Costumbres por Buenas Prcticas. Utilice los ciclos de Iniciacin, Planificacin, Ejecucin, Seguimiento y Control y Cierre de Fases tal como si fuera un proyecto. Utilice el Ciclo de Demming para mejora continua, con el Plan, Do, Act, Check PDAC al final de cada fase y vea las lecciones aprendidas y mejor las siguientes fases en base al conocimiento adquirido. Cuando planea cuidadosamente y construya un buen fundamento, la aplicacin del cambio podr ser mucho ms fcil, y se podr mejorar las posibilidades de xito. Si est demasiado impaciente, y si espera resultados demasiado pronto, es ms probable que fracase. Crear un sentido de urgencia, contratar poderosos lderes de cambio, construir una visin y comunicarla de manera eficaz, eliminar los obstculos, crear triunfos a corto plazo, y construir sobre el cambio. Si usted hace estas cosas, puede ayudar a hacer del cambio parte de su cultura organizacional. Ah es cuando se puede declarar una verdadera victoria.
ITCP-CERBESA |
97
10 de diciembre de 2012
ITCP-CERBESA |
98