De la A a la Z: plan para la recuperación de desastres (RD) TI

Tomado de: Articulo Original.

 

Los planes de recuperación de desastres (RD) en tecnologías de la información (TI) proporcionan un enfoque estructurado para responder a los incidentes no previstos que ponen en peligro la infraestructura de TI, compuesta por hardware, software, redes, procesos y personas. Proteger las inversiones realizadas por su firma en la infraestructura tecnológica y garantizar la capacidad empresarial para ejecutar sus operaciones corporativas son las principales razones para poner en marcha un plan de recuperación de desastres en TI.

En esta guía conoceremos todo lo necesario acerca de la elaboración del plan. Aprenderemos a desarrollar paso por paso el plan de RD de TI y los aspectos más importantes a tener en cuenta durante su elaboración.

ÍNDICE  DE LA PLANTILLA DEL PLAN DE RECUPERACIÓN DE DESASTRES TI

• ¿Qué es un plan de recuperación de desastres TI?
• Desarrollo paso a paso del plan de recuperación de desastres TI 
•  Aspectos clave a considerar al planificar la recuperación de desastres TI

Análisis de la plantilla del plan de RD de TI
===============================================================
 

¿Qué es un plan de recuperación de desastres TI?

Los planes de recuperación de desastres TI proporcionan unos procedimientos detallados a seguir, paso a paso, para recuperar los sistemas y redes que han sufrido disrupciones y ayudar a resumir la normalidad en las operaciones. El objetivo de estos procesos es minimizar cualquier impacto negativo en las operaciones de la compañía. El proceso de recuperación de desastres identifica los sistemas y redes críticos de TI; fija las prioridades para su recuperación y dibuja los pasos necesarios para reiniciar, reconfigurar y recuperar dichos sistemas y redes. Todo plan integral de recuperación de desastres debería incluir también a todos los proveedores relevantes, las fuentes de experiencia para recuperar los sistemas afectados y una secuencia lógica de los pasos a seguir hasta alcanzar una recuperación óptima.

Asumiendo que hemos completado una evaluación de riesgos e identificado amenazas potenciales a nuestra infraestructura de TI, el siguiente paso será determinar qué elementos de dicha infraestructura son los más importantes para las operaciones corporativas. Además, asumiendo que todos los sistemas y redes TI funcionan con normalidad, nuestra empresa debería ser plenamente viable, competitiva y sólida desde el punto de vista financiero. Cuando un incidente —interno o externo— afecta negativamente a la infraestructura de TI, las operaciones corporativas pueden verse amenazadas.  

Según la Publicación Especial 800-34, Contingency Planning for Information Technology Systems (Planificación de contingencias para los sistemas de tecnologías de la información), del National Institute for Standards and Technology (NIST, o Instituto Nacional de Estándares y Tecnología) de los Estados Unidos, lo que viene a continuación resume la estructura ideal de un plan de recuperación de desastres TI.

1. Elaboración de la declaración de políticas para el plan de contingencia. Contar con unas directivas formales proporciona la autoridad y orientación necesaria para elaborar un plan de contingencia efectivo.

2. Realización del análisis de impacto sobre el negocio (BIA). El análisis del impacto sobre el negocio ayuda a identificar y priorizar los sistemas y componentes críticos de TI.

3. Identificación de controles preventivos. Medidas que reducen los efectos de las disrupciones al sistema y pueden aumentar su disponibilidad y reducir los costos de contingencia del ciclo de vida.

4.  Desarrollo de estrategias de recuperación. Tener una estrategia integral garantiza que el sistema se recuperará de manera rápida y efectiva después de una disrupción.

5.  Desarrollo de un plan de contingencia TI. El plan de contingencia debería contener orientaciones y procedimientos detallados para la restauración del sistema dañado.

6. Prueba, formación y ejecución del plan. La prueba del plan identifica lagunas en la planificación, mientras que la formación prepara al personal de recuperación para la activación del plan; ambas actividades mejoran la eficacia del plan y la preparación general de la entidad.

7. Mantenimiento del plan. El plan debería ser un documento vivo que se actualiza regularmente para mantenerlo al día con mejoras al sistema.

Desarrollo paso a paso del plan de recuperación de desastres TI

Utilizando la estructura apuntada en la publicación SP 800-34 del NIST, podemos ampliar esas actividades a la siguiente secuencia estructurada de actividades.

1. El equipo de desarrollo del plan debería reunirse con el equipo interno de tecnología, el equipo de aplicación y los administradores de redes, y establecer el alcance de la acción, como por ejemplo, elementos internos, activos externos, recursos de terceros y enlaces a oficinas/clientes/proveedores; debemos asegurarnos de informar a la dirección del departamento de TI sobre dichas reuniones para que estén bien informados.

2. Recopilar todos los documentos relevantes de la infraestructura de redes, como los diagramas de las redes, la configuración de los equipos y bases de datos.

3. Obtener copias de los planes de recuperación de redes y de TI existentes; si no los hay, proceder con los siguientes pasos.

4. Identificar las amenazas contra la infraestructura de TI que la dirección considere más preocupantes: por ejemplo, incendios, errores humanos, apagones de energía, fallo de los sistemas.

5. Identificar aquello que la dirección considera que son las principales vulnerabilidades de la infraestructura: por ejemplo, inexistencia de sistemas de respaldo en caso de apagón eléctrico, copias de bases de datos obsoletas.

6. Examinar el historial previo de apagones y disrupciones, y cómo fueron gestionados por la empresa.

7. Identificar los activos TI que la dirección considera de importancia crítica. Por ejemplo: centro de llamadas, granjas de servidores, acceso a internet.

8. Determinar el tiempo máximo de apagón eléctrico que está dispuesta a aceptar la dirección en caso de indisponibilidad de los equipos TI.

9. Identificar los procedimientos operativos que se utilizan actualmente para responder a los apagones críticos.

10.  Determinar cuándo se probaron estos procedimientos para validar si siguen siendo adecuados o no.

11.  Identificar el/los equipo/s de respuesta de emergencia para todas las disrupciones de la infraestructura crítica de TI; determinar su nivel de conocimientos y preparación para manejar los sistemas críticos, especialmente en casos de emergencia.

12.  Identificar las capacidades de respuesta de los proveedores en casos de emergencia; si se han utilizado alguna vez; si funcionaron correctamente; cuánto paga la compañía por estos servicios; el estado del contrato de servicio; la existencia del acuerdo de nivel de servicio (SLA) y si se usa alguna vez.

13.  Recopilar los resultados de todas las evaluaciones en un reporte de análisis de carencias que identifique lo que se está haciendo frente a lo que debería hacerse, con recomendaciones sobre cómo lograr el nivel requerido de preparación y las inversiones necesarias para ello.

14.  Lograr que la dirección lea el repote y acuerde tomar las acciones recomendadas.

15. Preparar un plan de recuperación de desastres IT que cubra los sistemas y las redes esenciales de TI.

16.  Realizar pruebas de los planes y activos de recuperación de sistemas para validar su operatividad.

17. Actualizar la documentación del plan de RD para que recoja los cambios efectuados.

18. Programar la próxima revisión/auditoría de capacidades de recuperación de desastres TI (Fuente: NIST SP 800-34).

Aspectos clave a considerar al planificar la recuperación de desastres TI

• Apoyo de la alta gerencia. Asegúrese de tener el apoyo de la alta gerencia a fin de lograr alcanzar los objetivos del plan.
• Tomarse en serio el proceso de planificación de RD de TI. Aunque la recopilación y análisis de los datos para el plan de RD de TI puede llevar mucho tiempo, no es necesario que tenga docenas de páginas. Los plantes simplemente necesitan la información correcta, y esa información debería ser actual y precisa.
• Disponibilidad de estándares. Entre los estándares relevantes que podemos usar a la hora de desarrollar los planes de RD de TI están los siguientes: NIST SP 800-34, ISO/IEC 24762 y BS 25777.
• La sencillez es un grado. Es esencial reunir y organizar la información correcta. 
• Estudiar los resultados con las unidades de negocio. Una vez finalizado el plan de recuperación de desastres, debemos cotejar sus conclusiones con los líderes de las unidades de negocio para comprobar que nuestras premisas son correctas.
• Flexibilidad. La plantilla sugerida en este artículo puede ser modificada en lo que sea necesario para conseguir nuestros objetivos.

Análisis de la plantilla del plan de RD de TI

A continuación, examinaremos el índice de la plantilla, señalando las cuestiones clave a tratar y las actividades a desarrollar.

1. Declaración de intenciones del departamento de TI — Marca la pauta y dirección del plan.

2. Declaración de políticas — Es muy importante incluir una declaración aprobada con las políticas relativas a la provisión de servicios de recuperación de desastres.

3. Objetivos — Principales metas del plan.

4. Información de contacto del personal clave — Muy importante tener la información clave de contacto cerca del comienzo del plan. Es la información más susceptible de ser utilizada de inmediato y debería ser fácil de ubicar.

5. Visión general del plan — Describe los aspectos básicos del plan, como la actualización.

6. Respuesta de emergencia — Describe lo que hay que hacer inmediatamente en caso de incidente.

7. Equipo de recuperación de desastres — Miembros y datos de contacto del equipo de RD.

8. Alerta de emergencia, escalada y activación del PRD — Pasos a seguir en las primeras fases del incidente hasta que se activa el plan de RD.

9. Medios — Consejos para tratar con los medios de comunicación.

10.  Seguro — Resume la cobertura de seguros asociada con el entorno TI y otras políticas relevantes.

11.  Cuestiones legales y financieras — Acciones a tomar para administrar las cuestiones legales y financieras.

12.  Ejecución del PRD — Subraya la importancia de ejecutar el plan de recuperación de desastres.

13.  Apéndice A — Plantillas del plan de recuperación de desastres tecnológicos — Plantillas modelo para una variedad de recuperaciones por incidentes tecnológicos; es útil tener disponible la documentación técnica de algunos proveedores selectos.

14.  Apéndice B — Formularios recomendados — Formularios listos para usar que ayudarán a facilitar la finalización del plan.

Teniendo en cuenta las inversiones que las empresas realizan en infraestructuras TI, sería conveniente que inviertan también tiempo y recursos para proteger dichas inversiones de acontecimientos no previstos y potencialmente destructivos.

Acerca del autor: Paul Kirvan, CISA, CISSP, FBCI, CBCP, tiene más de 20 años de experiencia en gestión de continuidad del negocio como consultor, autor y educador. Además, es secretario del Instituto de Continuidad del Negocio, capítulo de E.U.

¿Qué ancho de banda es suficiente para un centro de datos virtual?

Tomado de: Ancho de Banda en Vrtualización.

 

Los profesionales de TI suelen citar la virtualización y las copias de seguridad como las razones por las que necesitan más ancho de banda. Pero no es necesario disponer de una red de 10 GbE para mantener un alto nivel de rendimiento.

En principio tiene mucho sentido pensar que una infraestructura virtual necesita una gran cantidad de ancho de banda. Digamos que la organización dispone de 20 servidores físicos consolidados, cada uno de ellos con dos puertos Gigabit Ethernet (GbE) conectados a un host virtual. Seguro que esto significa que el host no necesita más que unos cuantos puertos GbE, ¿no?

La realidad es que la mayor parte de esos host físicos no usan por completo todo el ancho de banda disponible, salvo en momentos muy concretos. Así que compartir un puerto GbE entre una docena de máquinas virtuales (VMs) no será un problema. La virtualización tiende a incrementar el uso medio de esos puertos desde menos de 1% hasta un 5% ó un 10%. Los VMs no necesitan mucho ancho de banda.

Dicho esto, los hosts de virtualización requieren puertos rápidos, principalmente para las transferencias de VMs entre los hosts. Mover 16 GB de datos contenidos en una de las VMs a través de una migración en vivo puede saturar el puerto GbE durante unos minutos. Este problema se agrava si consideramos que las migraciones también usan la memoria RAM de forma intensiva.

Si mi host virtual con 128 GB de RAM está saturado, migrar todos los datos de las VMs usando un solo puerto GbE puede llevar en torno a media hora o más. Si estoy migrando las VMs debido a un error físico en el sistema, podría tardar aún más. (Imagine la sensación cuando un host repleto de terabytes de memoria está a punto de fallar). Sin embargo la misma operación con un host de 128 GB y 10 conexiones GbE tardaría menos de cinco minutos, reduciendo el riesgo de fallo de las VM debido a un fallo del host virtual.

La importancia del ancho de banda en el almacenamiento

Las redes de almacenamiento con un gran ancho de banda también son un importante activo en las infraestructuras virtuales. La cantidad de ancho de banda necesaria para el almacenamiento depende no solo del número de transacciones, sino también de su tamaño. Windows File Server, por ejemplo, necesita transacciones relativamente pequeñas para acceder al almacenamiento, mientras que los servidores de base de datos usan transacciones de tamaño medio.

En ambos casos la carga de trabajo está limitada por la tasa de transacción de almacenamiento, incluso mucho antes de que el ancho de banda se convierta en un factor a tener en cuenta. Para las VMs de bajo uso y fácil virtualización, el almacenamiento en red no es una limitación, incluso a velocidades de GbE. Pero para las VMs con un uso más intensivo de recursos es mejor asegurarnos de disponer de docenas de “ejes” disponibles o de una razonable cantidad de discos de almacenamiento sólido antes de empezar a exigir redes de almacenamiento más veloces.

Copias de seguridad: las asesinas del ancho de banda

Conforme pasamos de la jornada laboral de 9 a 5 a la era del “siempre en línea” del Internet, la jornada laboral se superpone con la ventana de las copias de seguridad – ese momento en el que las empresas solían hacer copias del contenido de sus servidores, normalmente en las horas más tranquilas. Ahora las empresas necesitan mantener todo su rendimiento durante todo el día, así que las redes no pueden estar saturadas.

Las copias de seguridad son transacciones enormes que pueden colapsar una red rápidamente. Por eso resulta de sentido común tener una “vía rápida y ancha” por donde mover los datos. En estos casos, el elemento limitador son los discos de almacenamiento y no la propia conexión.

Siendo más concretos, si la herramienta de copia de seguridad usa agentes instalados en las VM, entonces necesitamos rutas rápidas a los hosts virtuales que eviten los posibles bloqueos durante el proceso de copia. (También deberíamos asegurarnos de que los hosts cuenten con la RAM y la CPU suficientes para poder gestionar este aumento de carga). Pero con un poco de suerte, nuestras copias de seguridad se descargan de las VM y de los host virtuales. Por lo tanto, conectar el servidor de seguridad con la unidad de almacenamiento, usando la conexión más rápida disponible, es definitivamente una buena idea. 

Y si disponemos de una red rápida para conectar el servidor de almacenamiento con el de copia de seguridad, ¿tiene sentido tener una red mucho más lenta para los hosts? Si vamos a comprar nuevo equipamiento, seguramente no. El coste incremental de disponer de puertos de red más rápidos es bajo y, con el tiempo, la demanda de ancho de banda seguramente aumentará.

Por otro lado, si lo que queremos es simplemente resolver el problema de la velocidad de las copias, probablemente compraremos puertos más rápidos para los servidores de almacenamiento y seguridad.

En última instancia, a medida que se compre nuevo equipamiento, iremos incluyendo puertos más rápidos. Con el paso del tiempo nos preguntaremos cómo nos las habíamos ingeniado en el pasado con esas redes tan lentas.

Porque del BPM

Tomado de: Porque del BPM

 

¿Cómo se define la gestión de procesos de negocio (BPM) en una sola frase? Si bien hay muchas respuestas diferentes, es probable que encuentre un tema común: BPM ayuda a una organización a hacer mejor su trabajo.

Este resumen del Manual Oracle Business Process Management Suite 11g, escrito por Manoj Das, Manas Deb y Mark Wilkins, abarca conceptos básicos de BPM, sus beneficios clave y las tecnologías relacionadas con BPM.

BPM, como su nombre indica, alude a la gestión de procesos de negocio (BP), por lo general con el objetivo de mantener o mejorar ciertos aspectos del rendimiento del negocio. Los procesos de negocio, a su vez, se refieren a las series de actividades que una empresa lleva a cabo. 

Como es previsible, existen muchas definiciones de BPM y de BP, que varían en su alcance y en sus puntos de vista. 

Más adelante en el libro profundizaremos sobre los detalles más precisos de la BPM y los BP, pero en un intento de brindar una estructura formal para los debates en curso, se adoptarán las siguientes definiciones no técnicas de trabajo:

• BPM se define como una estrategia para la gestión y mejora del rendimiento de un negocio a través de la optimización continua de los procesos de negocio en un ciclo repetitivo y cerrado de modelado, ejecución y medición. Las actividades de BPM abarcan la concepción y el descubrimiento a través de la implementación y la gestión de la ejecución de los procesos de negocio dentro de un apropiado marco de gobernanza.
• Un proceso de negocio es un conjunto de actividades vinculadas que son realizadas por personas y sistemas que ofrecen un valor empresarial a los clientes internos o externos.

Por lo tanto, adoptamos una visión amplia para el despliegue de un completo ciclo de vida de la BPM, incluyendo una continua mejora de procesos. Reconocemos esto como una disciplina de gestión que va más allá de las actividades de desarrollo de software o de la mera utilización de aplicaciones de software. 

También incluimos la buena gestión como un elemento necesario de la BPM. 

Creemos que una gobernanza adecuada es necesaria para garantizar la calidad de la adopción de la BPM que es capaz de brindar una ventaja competitiva sostenida.

En el caso de la definición de un proceso de negocio, evitamos a propósito la restricción a cualquier asociación estructurada de actividades empresariales. En los procesos estructurados, los pasos del proceso y su secuencia son conocidos a priori, por lo menos dentro de un conjunto específico de opciones posibles. 

Para muchos procesos de negocio esta restricción no plantea ninguna dificultad real y, de hecho, hace más simple la implementación informática de los procesos de negocio. 

Una orden directa de dinero en efectivo para bienes simples, un aprovisionamiento para un servicio telefónico y el apoyo al back-end de los procesos de negocio para la mayoría de las compras en Internet, todos entrarían en la categoría de procesos de negocio estructurados. 

Sin embargo, las empresas de hoy necesitan tanto mejorar como garantizar la calidad de ejecución de las transacciones comerciales que involucran más bien conjuntos ad hoc de actividades, en las cuales el número exacto de tareas y la naturaleza exacta de sus vinculaciones –incluyendo los aparentes flujos de trabajo– no son conocidos a priori. 

Los procesos de negocio evolucionan en función del contexto específico de una particular transacción comercial y se basan en resultados intermedios. A diferencia de la ramificación de flujos de tarea de secuencia estricta y pre-especificada, estas operaciones se rigen por normas comerciales, reglas y políticas de alto nivel. 

Estas operaciones también podrían incluir una colaboración relativamente libre de los trabajadores del conocimiento en lugar de pedirles las tareas humanas comunes conocidas dentro los sistemas tradicionales de flujo de trabajo. La gestión de estas operaciones puede ser formulada utilizando los llamados procesos no estructurados.

 Muchas de las actividades de gestión de casos, así como la R&D farmacéutica y los complicados análisis de riesgos, son ejemplos de procesos no estructurados.

Este extracto del Manual Oracle Business Process Management Suite 11g de Manoj Das, Manas Deb y Mark Wilkins, se reproduce aquí con permiso de Oracle Press, copyright 2012.

 Descargar el PDF del capítulo completo (en inglés).

Nos gustaría señalar que los procesos de negocio pueden existir –y de hecho lo hacen– dentro de aplicaciones empaquetadas como ERP, CRM, HRM y SCM, y también se pueden crear en el middleware que suele rodear estas aplicaciones. 

Si bien los procesos de negocios de aplicación transversal claramente se asientan en el middleware, suelen surgir situaciones en las que son necesarios el diseño multifacético y las consideraciones operativas en determinación a los mejores lugares para la creación de un proceso de negocio. 

Oracle BPM Suite es un producto middleware (de hecho, es parte de la familia de productos Fusion Middleware de Oracle) y se puede utilizar para crear procesos de negocios independientes que pueden integrarse con aplicaciones empaquetadas o bien extenderlas.

También puede ser útil tener en cuenta que la abreviatura “BPM” es de uso general para el Modelado de Procesos de Negocio, la Monitorización de Procesos de Negocio y la Gestión de Rendimiento Empresarial. Las dos primeras están incluidas en nuestra definición de BPM, mientras que la tercera se refiere a las mediciones financieras de desempeño del negocio en las cuales nuestro BPM debería contribuir en última instancia.

¿Por qué BPM?

En la actualidad, la mayoría de las empresas están muy interesadas en la adopción de BPM a través de sus organizaciones para ayudar a mejorar su desempeño corporativo. 

Todavía son pocas las compañías que han alcanzado la madurez en sus iniciativas de BPM, mientras que la mayoría está lidiando con las primeras etapas de la adopción. Informes frecuentes de firmas analistas líderes como Gartner, Forrester e IDC, indican que la mejora en la gestión de procesos ha sido una de las principales preocupaciones de las altas direcciones en los últimos años y lo seguirá siendo en los próximos. 

Los analistas estiman que el gasto anual en BPM se sitúa en el rango de los 5 a 6 mil millones de dólares y se prevé que crezca a una tasa del 30 al 40 por ciento por año (compárese con la tasa de crecimiento proyectada del 5 al 10 por ciento de la mayoría de los demás mercados de software de integración de negocios). 

En conjunto, la BPM parece disfrutar de un fuerte impulso positivo en el momento actual. Por lo tanto, valdría la pena profundizar un poco más para ver por qué la BPM se considera como algo tan beneficioso para una empresa.

Los beneficios de BPM

Como ya hemos señalado, la BPM consiste en gestionar las actividades empresariales de una manera integral. 

Si bien la adopción de BPM ofrece diversas ventajas, podría haber divergencias sobre la principal motivación para su uso en una determinada empresa. 

Por ejemplo, algunas empresas pueden centrarse en la ejecución de sus actividades de manera más eficiente, es decir, producir el mismo resultado con menos recursos como tiempo, dinero, bienes y mano de obra; mientras que otros pueden estar más interesados en generar mayor agilidad en el negocio con el fin de responder mejor a las cambiantes condiciones del mercado. 

En algunos casos, la gestión de procesos puede ser necesaria para producir suficiente visibilidad y crear registros de auditoría a través de una cadena de actividades, con el fin de satisfacer una variedad de requisitos normativos. 

Tales beneficios de la BPM, en general pueden ser clasificados como internos o externos. Generalmente los beneficios internos son la eficiencia, así como la satisfacción y la potenciación de los trabajadores, mientras que los beneficios externos ayudan a los clientes y a los socios a obtener más valor a partir de los productos y servicios de la empresa.

La BPM brinda una mayor eficiencia para las actividades comerciales mediante la entrega de procesos integrados que alcanzan a funcionalidades de TI distribuidas y también a los trabajadores. 

Un incremento en el nivel de automatización de ejecución de las transacciones debido a la informatización de las actividades del proceso reduce el tiempo de ejecución del proceso, ofrece una mayor capacidad de volumen de transacciones y reduce los errores generados por el hombre. Las instalaciones de colaboración (incluidas en Oracle BPM Suite 11g) hacen que sea mucho más fácil y más barato el manejo de excepciones complejas, lo que contribuye a una mayor productividad y eficiencia.

Una mejor visibilidad sobre una transacción comercial requiere de un seguimiento adecuado del proceso subyacente. Un proceso puede ser monitoreado a nivel superior para obtener datos de un chequeo general de salud acerca de las operaciones relacionadas con ese proceso –por ejemplo, el número de transacciones que se están realizando y cuántas están en qué estado de terminación, rangos de tiempos de finalización y porcentajes de caída. 

A menudo, las altas direcciones suelen estar interesadas en este tipo de información. Por otro lado, los diseñadores de procesos o aquellos interesados ​​en la mejora continua del proceso, también pueden desear realizar un seguimiento de varios parámetros de rendimiento asociados con las actividades individuales y las respuestas de rendimiento de las aplicaciones periféricas con las que se conecta el proceso. 

Los equipos de operaciones de TI se ocupan en general del rendimiento del sistema a nivel de software y hardware, de la información para una rápida detección de fallos y de brindar el nivel esperado de servicio de los sistemas que se ejecutan, para dar soporte a la continuidad del negocio. La gente de ventas y marketing estará interesada en aumentar las ventas y las oportunidades de ventas cruzadas asociadas con un cliente y sus operaciones. 

La descripción explícita y digital de los procesos que muestran todas las actividades asociadas, las normas y los sistemas finales, y los eventos generados por las instancias del proceso de negocio en ejecución, facilitan enormemente la visibilidad del proceso. Una vez que ya son maleables todas las actividades de una transacción basada en un proceso, también se hace más fácil la creación de rutas de auditoría o la generación de alertas para su uso con procedimientos de cumplimiento. 

Los analizadores de procesos integrados en BPMS (como en Oracle BPM Suite 11g) o herramientas de compañía como Business Activity Monitoring (por ejemplo, Oracle BAM) o Business Intelligence (por ejemplo, Oracle BI), pueden ser utilizados para visualizar con facilidad una variedad de información de los procesos.

Una mayor agilidad en los negocios se ha convertido en una característica esencial de las empresas ganadoras en el mercado global competitivo de hoy. 

La agilidad tiene que ver con responder rápidamente ante los cambios previstos y no previstos en la ejecución del negocio; los procesos de negocios son a menudo un lugar ideal para orquestar dichos cambios. 

Las empresas colaboradoras y los participantes de TI pueden modificar rápidamente los procesos existentes en función de lo que sea necesario según los imperativos del cambio. Además, la reutilización de los subprocesos o servicios (en los puntos finales del proceso) puede reducir enormemente el tiempo de respuesta para manejar el cambio. 

El uso de reglas de negocio externalizadas y desplegables en caliente que pueden alterar algunos aspectos de la ejecución del proceso (como resulta posible en Oracle BPM Suite 11g) es otra manera de aumentar la agilidad del negocio, ya que algunos de los cambios en el proceso pueden ser incorporados directamente por los analistas de negocio, sin requerir de largos y costosos proyectos de desarrollo de TI.

SOBRE LOS AUTORES

Manoj Das es gerente superior en el grupo de administración de productos de Oracle Fusion Middleware. Centra su atención en BPEL y en Reglas de Negocios. Manoj se incorporó a Oracle con la adquisición de Siebel, donde fue responsable de impulsar una plataforma de aplicación de próxima generación centrada en los procesos.

Manas Deb es director principal en el Grupo de Productos Fusion Middleware / SOA, BPM, Governance Suites en Oracle. Actualmente dirige la gestión de salida de productos y muchas iniciativas de participación estratégica de Oracle SOA, BPM y soluciones de gobernabilidad mundial. 

Mark Wilkins es un arquitecto de empresa que trabaja para el Programa de Arquitectura Empresarial Global de Oracle, donde se desempeña en líneas de productos para desarrollar estrategias de BPM. Mark se incorporó a Oracle desde BEA, donde jugó un papel decisivo en el desarrollo de métodos y ofertas de servicios de Arquitectura Orientada a Servicios.

Data Warehouse – Almacén de datos

Data Warehouse – Almacén de datos

Tenía que hacer una pequeña exposición/presentación sobre Data Warehouse en mi diplomado de Gestion TI. He puesto aquí algunos puntos de interés que he considerado.

Data Warehouse

Un Data Warehouse es una colección de datos en la cual se encuentra integrada la información de la Institución y que se usa como soporte para el proceso de toma de decisiones de una administración.

El soporte al procesamiento informático provee de una plataforma sólida, a partir de los datos históricos para hacer análisis.

Facilita la integración de sistemas de aplicación no integrados. Organiza y almacena los datos que se necesitan sobre una amplia perspectiva de tiempo.

Como características importantes de un buen Data Ware house:

• Flexible, ha de permitir cualquier tipo de dato de la organización y de cualquier fecha (tiempo).
• Escalable, no sabemos cuánto puede llegar a crecer una organización, por ello el sistema debe de ser lo suficientemente escalable para crecer sin problemas.
• Orientado a temas, el DW esté integrado con la lógica del negocio es imprescindible.
• Integrado, uno de los aspectos más importantes del DW es que la información encontrada interna esté siempre integrada.
• Amigable, debe de ser simple de usar y fácil de acceder a el, sin estas premisas, los usuarios no lo emplearán.

No se tiene un enfoque único para construir un Data Warehouse que se adapte a las necesidades de las empresas, debido a que las necesidades de cada una de ellas son diferentes, al igual que su contexto.

Cabe destacar que, para ampliar un negocio, se necesita que la información sea comprensible y accesible por todos.

Como esquema resumido del funcionamiento un Data Warehouse:

Consideración en plan de sistemas

Un Data Warehouse no se puede comprar, tiene que ser construido a medida y dependiendo de la complejidad de la organización o de los datos existentes, este puede ser muy complicado de implementar e influir mucho en el tiempo necesario para su desarrollo.

Estamos hablando de un proceso con altos beneficios a largo plazo, pero muy costoso de implementar. La total aprobación desde la dirección es imprescindible (top-down), para no tener que estar justificando gastos.

Es importante tener un equipo preparado para la implementación, ya que existe un alto grado de fracaso del proyecto. Por ello se recomienda una implementación por iteraciones.

Antes de comenzar se recomienda un pequeño desarrollo piloto, para demostrar los beneficios de esta práctica, de este modo los usuarios potenciales podrán entender la tecnología y probar los aportes que ofrece.

Por lo tanto, considerar que un Data Warehouse implica una serie de riesgos que se han de considerar en todo plan de sistemas, ya que involucra grandes recursos (dependiendo dimensión del proyecto).

Buenas prácticas derivadas

El flujo de datos que comenzará a manejar la empresa debe de ser analizado.

Gracias a la organización de los datos, la administración debería obtener ventaja estratégica frente la competencia. La experiencia y la evolución que se obtiene gracias a los datos es el mayor beneficio de cara al plan de empresa. Como claro resultado será la obtención de mejores decisiones en el negocio, más oportunidades y más claridad de trabajo.

Continuar con el desarrollo de sofisticación y uso del Data Warehouse, conseguiría que los datos acumulados dentro de una empresa llegarán a ser más organizados, más conectados, más accesibles y, en general, más disponibles a más empleados.

Otra buena práctica derivada sería enlazar el Data Warehouse a otros sistemas (tanto internos como externos a la organización), se puede compartir información con otras entidades comerciales con poco esfuerzo.

Habilitar acceso MEDIAWIKI solo con LOGIN

Edite el archivo de LocalSettings.php,  copia en la seccion correspondiente lo siguiente:

# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['createpage']      = false;
$wgGroupPermissions['*']['createtalk']      = false;
$wgGroupPermissions['*']['createaccount']   = false;
$wgShowIPinHeader = false; # For non-logged in users

Agregue al final lo siguiente:

$wgAutoLogin = true;
#SetupAuthMyExtension();
$wgDisableCookieCheck = true;

# End of automatically generated settings.
# Add more configuration options below.
function NoLoginLinkOnMainPage( &$personal_urls ){
    unset( $personal_urls['login'] );
    unset( $personal_urls['anonlogin'] );
    return true;
}
$wgHooks['PersonalUrls'][]='NoLoginLinkOnMainPage';

CENTOS comando Copy.

Algunos trucos:

Copiar un archivos sin confirmar la sobre escritura usando comando yes.
yes | cp -Rf * /home/macropro/E_fe01

(esta es una solucion "desesperada" pero funciona!)

En centos pide confirmacion  porque por default hay un alias:

cp='cp -i'

Para quitarlo:

unalias cp 

unalias elimina el alias de cp que pide confirmación

Otra opcion para no eliminar el alias es encerrar entre apóstrofes, esto usa el

comando tal cual sin alias, con la ventaja que el alias se
mantiene para uso posteriores Ej:

 'cp' archivo /haciadonde/archivo 

 'cp' -rf /RutaOrigen/* /RutaDestino/

Actualizando Mediawiki

• Respaldar la base de datos: 

     mysqldump --user=xxx --password=xxx miwiki > miwiki.sql

• Descargar mediawiki ultima version: 

     https://www.mediawiki.org/wiki/MediaWiki 

• Nos ubicamos en /var/www/html/

• Descomprimir en: tar xvzf mediawiki-1.20.4.tar.gz  

• Copiar cp -R mediawiki-1.20.4 minuevawiki

• Copiar desde la WIki Anterior: LocalSettings.php ,miwiki/images , miwiki/extensions.

     cp -R miwiki/LocalSettings.php minuevawiki
     cp -R miwiki/extension minuevawiki
     cp -R miwiki/images minuevawiki

• Restauramos la base de datos, en la nueva wiki:

          mysql --silent --local --password=root minuevawiki < miwiki.sql

• En la nueva wiki modificamos el LocalSettings.php, en la siguiente linea:

          ## Database settings
          $wgDBtype             = "mysql";
          $wgDBserver          = "localhost";
          $wgDBname           = "minuevawiki";
          $wgDBuser             = "root";
          $wgDBpassword     = "password";  

• Ejecutamos: php minuevawiki/maintenance/update.php  

• Ejecutamos en el Browser: http://localhost/minuevawiki

• Si no desplega correctamente la pagina principal, tenemos que hacer, es ingresar en la wiki anterior copiar todo el fuente de la pagina principal y pegar en la misma de la nueva wiki.                         

 

MySQL Error 1153 - Obtenido un paquete mayor que 'max_allowed_packet bytes'

Se debe cambiar en  my.ini (En Windows,  c:\Program Files\MySQL\MySQL Server / En Linux etc/my.cnf)  dentro de la seccion:

[mysqld]
max_allowed_packet = 10MB

O tambien ejecutar de la siguiente en lineas de Comandos:

mysql --max_allowed_packet=100M -u root -p database < dump.sql

Can't contact the database server: Can't connect to MySQL server on (13)

Al momento de instalar MEDIAWIKI 1.20.4, en Centos, pero la particularidad es que tenemos en otro servidor exclusivamente para servidores de base de datos, debido a ello me reporta el error:

Can’t connect to MySQL server on… (13)

Revisando todas las alternativas:

•  He hecho todas las configuraciones MySQL en PHP, pero mi solicitud estaba lanzando un "no se puede conectar al servidor MySQL en ... (13)
• Tuve la oportunidad de acceder a MySQL remotamente desde el servidor nuevo usando la línea de comandos, y fue capaz de telnet al puerto 3306, así que sabía que yo era capaz de conectarse. 
• Por alguna razón, mi aplicación PHP era incapaz de hacerlo. Finalmente, descubrí que debido a que el nuevo servidor se estaba ejecutando CentOS que necesitaba para desactivar SELinux. 
• Si está experimentando este problema, entonces éste es una posible solución. Modifique el archivo  /etc/sysconfig/selinux, la siguiente linea:

SELINUX=enforcing

a

SELINUX=disabled

A continuación, tendrá que reiniciar el servidor. Una vez que hice este cambio mi aplicación PHP fue capaz de conectarse a la base de datos sin ningún problema.

Tomado de: Articulo ORIGINAL

¿Vale la pena certificarse como PMP?

Tomado de: ARTICULO ORIGINAL

Como PMP (Project Management Professional) es frecuente escuchar una pregunta que todos los administradores de proyecto se han planteado en algún momento de sus carreras... ¿Vale la pena certificarse como PMP?

Pasar por el proceso de tomar el temido examen de certificación como PMP es costoso y complicado, y requiere un gran esfuerzo de preparación. ¿Vale la pena el esfuerzo para obtener la certificación?

El autor revisa algunos de los pros y los contras de la certificación PMP. Si bien sus opiniones son personales, son en su mayoría compartidas por el traductor.

La Certificación como PMP puede reforzar un CV, y puede hacer la diferencia entre conseguir un trabajo como gerente de proyectos y de ser pasado por alto en favor de otra persona (una persona que probablemente que sea PMP certificado). Lo que es más, muchos empleadores exigen la certificación PMP de sus gerentes de proyecto. Tener la credencial sin duda hará que sea más fácil encontrar un trabajo como gerente de proyecto o de programa.

Con el fin de aplicar para tomar el examen PMP es necesario haber alcanzado un cierto grado de experiencia en proyectos: 60 meses (7.500 horas) de experiencia si no se cuenta con título universitario, y 36 meses (4.500 horas) de experiencia si tiene una licenciatura. El PMI (Project Management Institute) tiene un proceso de auditoría para asegurar que los PMP potenciales están diciendo la verdad acerca de su experiencia en proyectos.

Usar la designación "PMP" después del nombre en la firma de correo electrónico da cierta credibilidad inicial cuando se conocen nuevos contactos (sólo los que ya saben lo que significa PMP).

(Además, es claro que el contar con la certificación no garantiza que una persona sea capaz de administrar un proyecto en forma exitosa. Sin embargo cómo se señala más delante y como se ha destacado en otro post, si muestra que la persona tiene el compromiso con la profesión de Administración de Proyectos, que conoce la terminología, las herramientas, los procesos y que ha sido capaz de enfrentar con éxito un proyecto personal de la magnitud que se describe).

El autor señala que tener la certificación PMP puedes ayudarle a conseguir un sueldo más alto en comparación con los gerentes de proyectos que no están certificados. Es más, una encuesta indica que el PMP es la más alta pagada certificación (por lo menos a partir de 2008). Más buenas noticias: una segunda encuesta indica que los salarios PMP siguen aumentando.

Las ofertas para líderes certificados (para cualquier área de ingeniería) en los EUA oscilan entre $40.00 y $100.00 US Dlls. la hora. Los escalones más altos son ofrecidos a consultores especializados, con muchos años de experiencia, o bien a líderes de oficinas grandes de proyectos.

Adicionalmente, el PMI® mantiene una base de datos con los resultados de su encuesta de 2005 sobre sueldos a personal de manejo de proyectos. Esta base, sin embargo, es accesible únicamente a miembros del PMI®.

Hago un paréntesis en el artículo original para citar ahora el artículo: "¿Qué sueldos están ofreciendo a líderes certificados?" de LiderDeProyecto que menciona:

...la oferta más baja: $20,000.00 Mx Pesos mensuales (aprox. $11.35 US Dlls la hora). No nos ha sido posible determinar si quienes hayan solicitado un PMP® hayan podido obtenerlo por este salario.

La oferta más alta: $65,000.00 Mx Pesos mensuales (aprox. $45.45 US Dlls la hora). Para este nivel, sin embargo, se requiere un alto nivel de experiencia en proyectos grandes (con más de 25 analistas y programadores).

Es seguro que existen ofertas más altas, pero es raro que los montos aparezcan anunciados: en México, generalmente, las ofertas superiores a $40,000.00 Mx Pesos mensuales se manejan a nivel confidencial o semi confidencial (es decir, sólo se transmiten directamente entre los interesados).

La media de las ofertas para líderes certificados, con experiencia en proyectos pequeños y medianos (5 a 20 analistas y programadores), oscila alrededor de los $35,000.00 Mx Pesos mensuales (alrededor de $20.00 US Dlls la hora)...

De nuevo en el primer artículo, el autor destaca otras ventajas de la certificación: Se puede tener contacto con todos los PMPs del mundo. (357 770 en todo el mundo de acuerdo a las estadísticas del propio PMO a Agosto de 2011). Se puede participar en las reuniones periódicas en las que se organizan aprender acerca de la teoría de gestión de proyectos, hacer networking y obtener PDUs necesarios para renovar la certificación cada tres años.

Brian considera que la metodología del PMI resulta ya un poco anticuada, y que los procesos del PMI parecen adaptarse mejor a proyectos que utilizan el método de desarrollo en cascada, que no es tan popular en estos días. Señala que el desarrollo iterativo se está imponiendo rápidamente, y me parece que el desarrollo ágil con Scrum es una metodología sólida que ayuda a mantener los proyectos en marcha.

De hecho, el PMI ya lanzó un piloto de la certificación como PMI-Agile Certified Practitioner (PMI-ACP).

El autor se inclina a pensar que los Gerentes de Proyecto certificados como PMP son mejores que aquellos que no están certificados, en general, debido al hecho de que los certificados entienden la importancia de la credencial y han dedicado tiempo y esfuerzo a obtenerla.

Brian considera que vale la pena obtener la certificación como PMP. Le ha ayudado a ser contratado para trabajos de gestión de proyectos, y continuará haciéndolo a lo largo de su carrera. Le ha ayudado a conocer a mucha gente interesada en el campo de la gestión de proyectos mediante la participación en las actividades y eventos del PMI, y le ha permitido aprender más sobre la doctrina de la gestión de proyectos. Poner la denominación PMP después del nombre en la firma de correo electrónico le ha dado cierta credibilidad adicional al tratar con los clientes, y también ha suscitado debates sobre la gestión de proyectos con sus compañeros.

Comentarios: 

Hola, bueno el artículo. Sin embargo en ninguna parte se analiza el hecho de que la certificación PMI garantice la calidad del profesional. Solo se habla de $$ que permite aspirar, no de calidad de los  conocimientos. Mas aún, el hecho de que la metodología sea en Cascada (algo obsoleta por estos tiempos) no garantiza una gestión óptima, mas aún en proyectos de alta complejidad como de  desarrollo e implementación de SW. Finalmente, será bueno saber si los PM de grandes compañías de TI (Google, Oracle, SAP, etc) tienen certificaciones PMI

En realidad, ninguna certificación y ningún grado de estudios te garantizan la calidad de los conocimientos.

Desde mi particular punto de vista, la calidad de los conocimientos (y sobre todo, como la persona declara esos conocimientos) es de nuevo una de esas cosas que se aprenden en la cuna. Tiene que ver más con honestidad que con certificaciones.

Por otro lado, yo no interpreto que el PMI sugiera una metodología... Es todo un tema filosófico. De nuevo, desde mi punto de vista, el PMI sugiere un conjunto de herramientas que se pueden usar, proporciona un lenguaje común y ejemplifica el uso del lenguaje y las herramientas con un esquema en cascada. 

Pero deja muy claro que cada quién puede adaptar las herramientas y los procesos a la metodología que mejor le aplique. Ya hemos platicado aquí sobre métodos ágiles, que por el momento parecen ser una buena opción para enfrentar proyectos complejos de desarrollo de software. Agile no está peleado con el PMBok. Yo mismo he implementado las herramientas y los procesos en proyectos que no siguen el esquema de Cascada.

Por último, no estoy seguro de si hay PMPs como empleados de las grandes compañías. Una búsqueda rápida en LinkedIn sugiere que sí.