Plan de Contingencia. Aspectos a tener en cuenta

Informe de situación del CPD

Dentro del análisis de riesgos es imprescindible evaluar el conjunto de sistemas que forman parte del CPD y conocer exactamente las condiciones en que se encuentran. Para ello es conveniente realizar un estudio detallado de las condiciones que cumplen, con el objetivo de definir un conjunto de medidas correctoras, dirigidas a mejorar la seguridad física de la sala y optimizar la disponibilidad de los servicios de TI.

Como valor añadido, este análisis nos permitirá establecer recomendaciones con el objetivo de perseguir la máxima eficiencia energética de cada uno de los sistemas y así reducir el consumo energético del conjunto del CPD y, en consecuencia, los costes asociados.

De esta forma y una vez implementadas las recomendaciones resultantes, la organización habrá minimizado los riesgos que pueden afectar al CPD, aportando estabilidad y seguridad a todos los procesos de negocio.

El análisis ha de contemplar los siguientes aspectos:

• Sistema de cerramiento de la sala.
• Sistema eléctrico.
• Sistema de alimentación interrumpida.
• Sistema de climatización.
• Sistema de protección contra incendios.
• Sistema de monitorización de alarmas.
• El estado general de la sala, en cuanto a distribución, orden, limpieza, y nivel de respeto intrínseco de las condiciones de seguridad, control de accesos así como otros criterios técnicos específicos vitales en este tipo de entornos.

Manuales técnicos y “checklists funcionales”

Para que la recuperación de los servicios en el entorno de contingencia y su posterior restitución a la situación original sea un éxito, es imprescindible:

Definir cómo “levantaremos” la infraestructura que soporta los servicios de TI – equipos, bases de datos, comunicaciones, etc.- en los diferentes entornos.

Definir cómo comprobaremos que los procesos de negocio asociados a dichos servicios funcionan correctamente. Hemos de comprobar si podemos seguir haciendo pedidos, facturando, vendiendo, etc…

Para realizar el primer punto debemos definir todos aquellos manuales técnicos asociados. Manuales cuya ejecución se comprobará durante las pruebas y cuya responsabilidad de realización recae sobre el personal de TI.

Para realizar el segundo punto debemos definir todos aquellos “checklists funcionales” asociados a los procesos de negocio soportados por los servicios de TI. La responsabilidad de su realización recae sobre las diferentes unidades de negocio.

Proceso de gestión de la continuidad y disponibilidad de los servicios de TI

Una vez realizado el plan de contingencia, si queremos que sea algo vivo y útil, es fundamental establecer las bases para una gestión eficaz y eficiente, que proporcione continuidad en el tiempo al resto de trabajos realizados durante la creación del plan. Para ello, será necesario definir el proceso de gestión de la continuidad y disponibilidad de los servicios de TI.

La definición de este proceso implica, a su vez, la definición de los siguientes elementos:

• Objetivos de cada proceso.
• Actividades de cada proceso y roles y responsabilidades asociados a cada una de ellas de manera que quede claro quién hace qué dentro del proceso.
• Relaciones con el resto de procesos, principalmente gestión de incidencias, problemas, configuración y cambios.
• Las entradas del proceso definirán qué es lo que este proceso requiere de los demás.
• Las salidas del proceso definirán qué información se debe entregar al resto de procesos.
• Métricas e indicadores que describan cómo se debe medir el proceso.

Este proceso nos permitirá:

• Determinar claramente las responsabilidades dentro del ciclo de diseño, transición y operación de los servicios de TI.
• Que los servicios de TI se diseñen para alcanzar los requerimientos de disponibilidad y continuidad del negocio.
• Que se establezcan las bases para la mejora continua de los servicios de TI.
• Que se facilite la justificación del coste de las inversiones asociado a la disponibilidad y continuidad de los servicios.
• Adoptar una mentalidad proactiva.

Retos de la gestión de la LOPD en grandes organizaciones

Las grandes organizaciones, con grandes grupos de empleados, un número importante de departamentos o varias delegaciones y/o sucursales, necesitan poder gestionar y mantener toda la información y documentación asociada al cumplimiento de la LOPD de forma centralizada y actualizada.

Además, este tipo de organizaciones tiene la necesidad de enmarcar las medidas exigidas por la LOPD y su Real Decreto dentro del cumplimiento general de las obligaciones legales, reglamentarias o contractuales y de los requisitos de seguridad de la organización que pueden venir determinados por estándares internacionales como ISO27000 o SOX.

Abast Grup y ECIJA le invitan a un seminario en el que examinaremos la forma de abordar el cumplimiento de lo exigido por la LOPD y le mostraremos herramientas que le permitirán gestionar y cumplir con lo establecido por la ley y su Real Decreto de una manera eficaz.

El evento se realizará el día 1 de marzo en las oficinas de Abast en Barcelona (C/Equador, 39-45). El evento se iniciará a las 9:30 y finalizará, como muy tarde, a las 12:30. A continuación os detallamos la agenda del mismo:

• Café de bienvenida y entrega de la documentación
• Retos de gestión de la LOPD en grandes organizaciones.
  • David Ortega - Director de Consultoría y Auditoría de TI de Abast
• Demostración práctica de la herramienta Ecija DPServer.
  • Álvaro Écija Bernal - Socio Director de ECIJA
• Caso de éxito. Pendiente de confirmar
• Ruegos y preguntas
• Aperitivo

Si estáis interesados podéis inscribiros en www.abast.es/seminarios o llamando al 902 486 901.

¿Cómo hacer un Plan de Contingencia?

A medida que las organizaciones dependen más y más de la tecnología, que se ha convertido en un componente clave de la mayor parte de los procesos de negocio, la disponibilidad de los servicios de TI es imprescindible para su supervivencia. Esta disponibilidad se consigue mediante la definición e implementación de un Plan de Contingencia cuyo objetivo consiste en garantizar que se puede recuperar la infraestructura de TI que soporta dichos servicios dentro de los plazos y con el nivel de servicio acordado y necesario para el negocio.

Beneficios

1. Reducción de aquellos riesgos que, en caso de materializarse las amenazas que les originan, pueden representar pérdidas ingentes de capital, bien por facturación fallida, por reposición de los daños causados, por pérdida de oportunidad de negocio, por reclamación de clientes, por sanciones legales, etc.
2. Ahorro de tiempo y dinero al afrontar y corregir situaciones nefastas antes de que ocurran y nos obliguen a resolverlas con prisas y a cualquier precio.
3. Mejora de la imagen y revalorización de la confianza en la empresa de los accionistas, inversores, empleados, proveedores y clientes al mostrarles que se toman medidas diarias para garantizar la continuidad del negocio.

Retorno de la Inversión

La metodología para desarrollar el plan tiene como objetivo principal ayudar a la organización a garantizar que se implementan las medidas y estrategias de recuperación que el negocio realmente necesita y puede permitirse.

Es fundamental, por tanto, entender que significa para el negocio la no disponibilidad de sus sistemas y realizar las acciones y planes necesarios para evitar que ocurra. La clave para lograr esta comprensión es la calificación (la validación con el negocio) de lo que significa realmente el tiempo de inactividad y, a continuación, la cuantificación (medición) de las consecuencias para el negocio. Se trata, por tanto, de estimar el coste de mejorar la infraestructura de TI actual frente a las pérdidas por no disponibilidad.

Metodología

Básicamente, un proyecto de Plan de Contingencia consiste en:

1. Análisis de impacto en el negocio. Consiste en identificar los procesos más críticos del negocio, los servicios de TI que los soportan, determinar el impacto si uno o varios de estos servicios de TI se ven afectados total o parcialmente y definir los requerimientos de recuperación establecidos por el negocio – tiempo máximo de interrupción y máxima pérdida de datos permitida -.
2. Análisis de riesgos. Consiste en estimar el riesgo potencial al que están sometidos los sistemas de TI, evaluando el impacto asociado a la materialización de una amenaza, y definir aquellas recomendaciones o controles preventivos que permitan reducir o eliminar dicho riesgo.
3. Definición de las estrategias de recuperación. Consiste en establecer los escenarios de recuperación en función de las amenazas determinadas en el análisis de riesgos y los requerimientos de negocio definidos en el análisis de impacto. En esta fase se define el escenario tecnológico óptimo para soportar los procesos de negocio, atendiendo a las disponibilidades del servicio.
4. Desarrollo e implementación del Plan de Contingencia. Una vez definida la estrategia de recuperación, el plan debe definir y establecer aquellos procedimientos, manuales técnicos y checklists funcionales que permitan restaurar los servicios de TI (sistemas, operaciones y datos) después de una emergencia o afectación total o parcial de estos servicios. La implementación del plan consiste en la ejecución de las recomendaciones establecidas en el análisis de riesgos y el escenario tecnológico definido.
5. Prueba y mantenimiento del plan. Las pruebas del plan son esenciales para identificar las deficiencias de planificación y preparación del personal. Además, el plan debe ser un documento vivo que se actualiza periódicamente para mantenerse al día con los cambios en los sistemas de TI.

Aspectos importantes a tener en cuenta:

1. Es aconsejable, en algunos casos imprescindible, utilizar una herramienta para realizar el análisis de riesgos. En el mercado existen diversas herramientas y cada una de ellas tiene sus ventajas e incovenientes: PILAR, Meycor, Proteus, Ecija (PCN, SGSI), etc.
2. Es necesario definir los procesos de continuidad y disponibilidad de TI que permitan mantener actualizado el plan frente a los cambios continuos de la infraestructura y servicios de TI, considerando de forma especial su integración con el proceso de gestión de cambios.
3. Un punto delicado es la definición de los criterios de activación del plan. El plan debería activarse cuando la evaluación de los daños indique que se han cumplido uno o más de estos criterios.
4. Las estrategias de recuperación nos definen el escenario tecnológico que cumple con los criterios de continuidad del negocio. El desarrollo del plan de contingencia asociado puede verse aplazado hasta la implementación de dicho escenario. Esto puede conllevar una inversión económica considerable que deberá pasar, entre otras cosas, por un proceso de aprobación que se puede dilatar en el tiempo. Entre tanto, es aconsejable definir un plan provisional basado en "best effort" - intentar solucionarlo lo antes posible - que prevea qué hacer en caso de activación del plan.

¿La crisis 'obliga' al personal de TI a reinventarse?

Hace relativamente poco tiempo, leí este artículo que me llamó, especialmente, la atención por su título:

"La Crisis 'obliga' al personal de TI a reinventarse" (noticia publicada el pasado 10/03/2009 en http://www.idg.es/computerworld/noticia.asp?id=77363)

En él se exponían los siguientes puntos principales, cito textualmente:

(...) No hay duda de que las perspectivas del empleo dentro de la industria de TI son cada vez más negras. Las compañías están externalizando sus departamentos de TI, renovando sus plantillas y sustituyendo a veteranos del sector por mano de obra barata en un intento desesperado por reducir costes.

(...) Más que vaticinar el fin de la carrera del profesional especializado en TI, los analistas consideran que éste debe reinventarse, cambiar sus habilidades y combinar su conocimiento de la tecnología con su conocimiento sobre el negocio con el objetivo de poder salvaguardar su puesto del offshoring.

Dos reflexiones a lo que se expone en el artículo:

• Premisa 1: la reinvención, la innovación en definitiva, es una cualidad del cambio, así como el talento para desarrollarla es una característica intrínsecamente humana.

Está claro que en épocas de crisis o en circunstancias adversas se agudiza el ingenio y por tanto, se es especialmente proclive a los que llamamos vulgarmente "estrujarse los sesos", pero la capacidad humana de reinventarse, de innovar es una característica que forma parte de nuestro género "Homo" desde los albores de la humanidad.

Dice E. Punset en su blog (http://www.eduardpunset.es/blog/?p=175) que la capacidad metafórica es el primer requisito del talento y que la especie humana lo desarrolló hace unos cincuenta mil años, y que "sin el ejercicio del poder metafórico o multidisciplinar no hay talento que valga".

(...) Durante mucho tiempo se creyó que el talento era el fruto de una reflexión. Nunca se habían analizado científicamente los mecanismos intuitivos. La intuición no se consideraba siquiera conocimiento. No te podías fiar de la intuición. Más tarde, el análisis científico demostró que gran parte de la historia de la evolución transcurrió a golpe de intuición.

(...) En los últimos años, la ciencia ha ido más lejos y ha llegado a la conclusión de que, en determinados casos, es mucho más segura la intuición que la razón. ¿Cuándo? Cuando no se dispone de toda la información necesaria (...).

Por tanto, y aunque lo favorezca, no hace falta necesariamente que haya crisis para reinventarse, sólo que haya cambio, y el cambio es recursivo. Estamos en continuo cambio. Ya lo dijo Heráclito: "todo fluye, nada permanece".

Cuando en el ámbito de los negocios el entorno es cambiante, los parámetros de competencia varían, la tecnología evoluciona ofreciendo nuevas posibilidades, surge la incertidumbre...y la intuición...que nos lleva a la innovación...que nos lleva al cambio...que nos lleva, en definitiva, a reorientar o modificar de forma estratégica, los procesos de negocio para garantizar mejor su adaptación.

• Premisa 2: sin conocimiento no hay éxito

La aparición de la economía basada en el conocimiento supone que la capacidad de una empresa de crear valor ya no depende exclusivamente de su capacidad financiera y de producción. Se viene constatando desde hace algunos años que la información y el conocimiento son una fuente primordial para la creación de renta y de riqueza.

(...) La Gestión del Conocimiento surge en el nuevo escenario económico como la nueva visión con la que plantear la búsqueda de soluciones que contribuyan a modificar, adaptar o ajustar el entorno empresarial a la nueva realidad, cuyo principal y más claro atributo es la incertidumbre.

M. Fernández de Pinedo, "La Gestión del Conocimiento en el nuevo paradigma")

Nuevamente, ante un entorno de incertidumbre -que viene de la mano del cambio- el conocimiento se convierte en un factor fundamental para la adecuada gestión de la información que tratan los procesos de negocio.

El "know-how" no puede medirse, ni valorarse exclusivamente en términos de coste -barato frente a caro-. El conocimiento es capacitación, es saber identificar, evaluar, intuir, interpretar, medir, es en definitiva, valor añadido. Valor que aporta madurez a estos procesos de negocio y que predispone su adaptación al cambio, a la innovación.

Por este motivo, la reducción de los costes no debería buscarse en este sentido, sino que debería orientarse hacia una mayor optimización en el uso de los recursos, una mejora de la calidad de los procesos que generan productos finales y/o servicios con resultados más competitivos, o bien hacia la potenciación de los propios recursos humanos de TI (lo que se conoce como "empowerment") que permita precisamente, obtener ese valor añadido y esa efectividad resultado de su conocimiento y experiencia.

Por tanto, y bajo este prisma, la tendencia de abaratar costes en el contexto de las TI sustituyendo a "veteranos del sector por mano de obra barata" me parece, sin duda, un error.

En palabras de J. M. Viedma ("La Gestión del Conocimiento y del Capital Intelectual", 2001):

Tanto la gestión del capital intelectual como la gestión del conocimiento son de hecho la piedra angular del paradigma de empresa excelente o empresa triunfadora del siglo XXI.

Un dato significativo procedente de la presentación de resultados del informe 2009 de la Fundación para la Innovación Tecnológica -Fundación Cotec-:

Se confirma un descenso sobre la evolución y la capacidad del sistema español de innovación, rompiendo con la trayectoria de un crecimiento superior al 10% en los últimos años y pasando a unos niveles que no se apreciaban desde 2002.

¿Debemos atribuirlo únicamente a un problema de la crisis?

Estándares Metodológicos para la Gestión de los Sistemas de Información.

En la actualidad la variedad de metodologías (llamémosle así de forma genérica al conjunto de estándares, metodologías, o buenas prácticas) presentes en el mercado relacionadas con la gestión de los departamentos de TI es muy amplia, y parece que el futuro no va en la línea con la “consolidación” como pasa en el mercado de las empresas de TI, sino todo lo contrario, con nueva metodologías apareciendo en la cartelera mensualmente…..Lean Service Management, USMBOK (Universal Service Management Body of Knowlegde, www.usmbok.org), ISO 38500, CMMi Services, Six Sigma aplicado a TIC, y un largo etcétera.
De todas formas hay algunos de estos estándares que se han consolidado en el mercado, o que suenan en mayor medida, sobre todo los que ya llevan unos años de trayectoria. Entre estos, ITIL, en sus versiones 2 y 3 (14 millones de entradas en google), el estándar ISO 20000 (4,6 millones de entradas), nacido a raíz de ITIL, la ISO 27001 relacionada con la seguridad de la información (1,7 millones de entradas), CMMi en su totalidad (Development- Services-Adquisition) (2,1 millones de entradas), y Cobit (0,8 millones de entradas) como marco de gestión más enfocado a alinear los objetivos del negocio con las tareas de los departamentos de TI.
De todo este aglomerado de estándares cada organización debe ser capaz de entenderlos todos, saber qué puntos tienen en común y qué elementos define mejor cada uno, y a la vez saber utilizar aquellas herramientas que nos presentan individualmente los distintos enfoques.
Por ejemplo, ISO 20000 es, a nuestro modo de ver, un buen punto de partida para iniciarse en este camino, aunque no se persiga el fin último de una certificación. Este estándar define unos mínimos que toda organización debe cumplir (los “debes” de la norma, en su parte 1) para tener un sistema de gestión de servicios TI (SGSTI). Apoyando a esta norma certificable, podemos utilizar su parte 2 (ISO/IEC 20.000-2), como referencia para la mejora de este sistema de gestión (los “debería” de la norma).
En paralelo, no podemos desviar la vista de ITIL, en su versión 2, ya que contiene casi los mismos procesos que la norma certificable, aportando un conocimiento más profundo en cuanto a las interrelaciones entre los distintos procesos y una visión más detallada de los roles implicados y sus responsabilidades.
La última versión de ITIL, la 3ª de estas mejores prácticas, aporta una mayor profundidad en cuanto al ciclo de vida de los servicios, y se realiza una revisión de antiguos conceptos, actualizándolos y proponiendo algunas nuevas soluciones a dificultades encontradas en la versión anterior. De todas formas, la versión 3 en todo su conjunto, abarca un ámbito tan grande de procesos y funciones que no parece recomendable empezar con esta versión de esta metodología a no ser que hablemos de organizaciones ya muy maduras en la gestión por procesos y con un cierto tamaño, que nos permita dedicarle un esfuerzo considerable.
No olvidemos, de entre todas las metodologías, aquellas orientadas a asegurar la seguridad de la información, como requisito indispensable dentro de una organización que gestiona datos y por tanto debe asegurar su confidencialidad, integridad y disponibilidad. En este sentido la norma ISO 27001 (Sistema de Gestión de la Seguridad de la Información (SGSI)) sería la norma certificable, junto con toda la familia de la serie 27000, y por tanto el punto de referencia.
Como complemento a todas las anteriores, nunca deberíamos descuidarnos tener en cuenta Cobit (Cobit 4.1), sea cual sea el ámbito que nos interese (dentro de TI). Ya que nos aporta un visión complementaria a todos los procesos de ISO 20.000 e ITIL, y nos aporta mucha más información en relación a indicadores y como mapearlos a nuestros objetivos de negocio. Sin olvidar las propuestas de matrices RACI o los niveles de madurez propuestos para cada proceso.
En definitiva, para confeccionar un sistema de gestión de los sistemas de información, hay unos pasos que ninguna organización debería saltarse. En primer lugar, conocer las distintas metodologías, y posteriormente definir cuál es el objetivo que quiere conseguir la organización. Seguidamente, evaluar el estado de madurez de la organización respecto al objetivo marcado. En tercer lugar, llevar a cabo un proyecto (apoyado por la Dirección) para conseguir pasar del estado actual al deseado. Este paso puede realizarse internamente, o con ayuda externa, pero siempre debe quedar claro el objetivo, y se deben definir los indicadores que nos permitirán saber cuando hemos llegado al objetivo final.
Para finalizar y siguiendo el hilo del inicio de este artículo, comentar que 11 empresas en España (según distintas fuentes) ya han conseguido la certificación ISO 20.000, y nos consta que un número mucho mayor están en camino de implementar un modelo basado en dicha norma, lo que nos reafirma en nuestra opinión: La ISO 20.000 es un buen punto de partida hacia la mejora para las organizaciones que gestionan las TIC.

Artículo publicado en www.computing.es

http://www.computing.es/Informes/200905130005/Estandares-Metodologicos-para-la-Gestion-de-los-Sistemas-de-Informacion.aspx

Pongamos que hablamos de herramientas de análisis de riesgos en IT

A menudo, tenemos tendencia a creer que las herramientas nos van a proporcionar todas las respuestas que necesitamos con sólo apretar un botón (en el mejor de los casos). Toda la subjetividad que conlleva un clásico análisis de campo (descriptivo, empírico), basado en entrevistas, cuestionarios y observaciones varias, aunque, no por ello, ausente de metodología, parece condicionar su validez frente a un análisis basado en el uso de una herramienta generalmente específica y dedicada. El proceso analítico en que se basa la herramienta suele considerarse mucho más objetivo y, desde luego, mucho más racional en comparación con el anterior. De hecho, no podemos olvidar que las herramientas de análisis en general permiten obtener modelos conceptuales que, a su vez, permiten interpretar datos, predecir implicaciones y, por tanto, tomar decisiones; pero, frecuentemente, en esa creencia se pasa por alto un detalle fundamental, y es que ninguna herramienta o aplicación informática puede sustituir el conocimiento deductivo y la propia experiencia de quien realiza el análisis. Sobre todo, si se tiene en cuenta que, en muchos casos, la herramienta se basa o permite elegir opciones de tipo cualitativo donde es el propio usuario quien valora subjetivamente las variables en las que se fundamentarán los cálculos internos (por ejemplo, una valoración de frecuencia, probabilidad o degradación); cálculos que, por otro lado, son también discutibles.

De lo expuesto hasta el momento no debe deducirse necesariamente que esté en contra del uso de estas herramientas en el proceso de análisis; todo lo contrario, se trata simplemente que no comparto (o no entiendo) el uso indiscriminado que, en muchas ocasiones, se hace de ellas cuando, no disponiendo de conocimiento suficiente de la situación actual de la Compañía, se pretende, cual Oráculo, buscar respuestas a preguntas que no han sabido formularse primero. En estos casos, las respuestas perseguidas se contextualizan en un supuesto análisis numérico que, amparado en sus mecanismos de cálculo, esconde una carencia de conocimiento, de metodología, de objetivos y, en definitiva, de definición, que se hace patente, especialmente, en aquellos casos en los que no se precisa ninguna herramienta para valorar unas variables que son obvias, muchas veces, "a flor de piel". Si, además, se toman en cuenta los costes, la obtención de una valoración numérica final, no siempre compensan el tiempo invertido en la entrada y posterior mantenimiento-actualización de los datos y la dedicación que requiere el proceso relacional y de análisis.

Puesto que los procesos de negocio están soportados por servicios de TI, quizá deberíamos conocerlos primero un poco mejor.

La paradójica existencia de las "guerrillas" IT

Se ha escrito muchísimo sobre el llamado "Sun-Tzu" o "Arte de la Guerra" como un clásico de estrategia militar de actual aplicabilidad al mundo de los negocios y de la estrategia empresarial (véase por ejemplo "El Arte de la Guerra para Directivos" de Gerald Michaelson). Un aspecto muy recurrente de los muchos que se tratan en todas estas publicaciones, es la comparación del enemigo con la competencia directa externa, pero curiosamente, la mayoría de las veces, no hay que irse tan lejos para observar que los "mini campos de batalla" se suceden día tras otro, en nuestro entorno más cotidiano dentro de la propia compañía e incluso dentro de la propia área.

A lo largo de mi experiencia, he tenido la oportunidad de llevar a cabo proyectos para diferentes organizaciones, el desarrollo de los cuales, ha acontecido en el "campo de batalla" de sus áreas IT, eso sí, bajo un aparente clima de calma. Lo paradójico de esta situación y como sucede en todas las guerras, es que nunca produce vencedores, sino únicamente estancamiento y pérdida por igual.

Mi posición de observadora accidental en esta particular guerra IT encubierta, me ha permitido reflexionar sobre esta cuestión y sobre los posibles motivos que la fomentan, llegando a la conclusión que, salvando la predisposición tan humana al conflicto, son principalmente consecuencia de:

• Una carencia clara de estrategia, o bien de alineación entre la estrategia tecnológica y la corporativa de negocio de la organización, cuya primera implicación es la divergencia de directrices, objetivos y prioridades. Esto se traduce en la máxima: "a falta de criterio, el mío es el que vale".

• La consolidación del efecto "Reino de Taifas", cuyas características más destacadas son a mi modo de ver, por un lado, el establecimiento de "facciones" de poder que implican el posicionamiento de los integrantes de rango y por otro lado, una acentuada problemática de comunicación y coordinación entre "reinos" que impacta en el desarrollo normal de las actividades del área IT y por tanto, en el negocio.
  

• La inexistencia de la práctica del análisis de carácter iterativo (mejora continua) y en consecuencia, la resistencia como respuesta a la crítica y la oposición al cambio: "crítica vs fiscalización".

• Las propias aptitudes de liderazgo de sus componentes.

En resumen, estamos hablando de estrategia, trabajo en equipo, comunicación, metodología y liderazgo: ¡todo un clásico!.

Tomando como referencia el tratado de Sun-Tzu (capítulo 1) y salvando las distancias, estas problemáticas, analizadas bajo el prisma de los cinco fundamentos del arte de la estrategia, ponen de manifiesto que tanto éstas como cualquier otra proclive a la "guerra de guerrillas", no se rigen por criterios de gobierno y sin gobierno no hay victoria.

Como conclusión, y puesto que ya se ha escrito mucho sobre el tema, me quedo con esta reflexión:

Preveer una victoria que un hombre ordinario puede preveer, no es el espíritu de la excelencia. No importa si triunfas en la batalla y eres aclamado universalmente como "experto", pues levantar una hoja caída no requiere tener gran fuerza, distinguir entre el día y la noche no es prueba de gran visión, oír un trueno no es muestra de oído agudo.
(...)
Los que son expertos en la guerra cultivan sus políticas y se adhieren estrictamente a las reglas trazadas. De este modo, tienen en su poder el control de los acontecimientos.

(Sun-Tzu - El Arte de la Guerra, capítulo 4: Disposiciones)