Es cierto, las redes sociales cada vez están más de moda. Es más, yo creo que es el momento de dejar de pensar que son una moda y empezar a pensar en que, sencillamente, nuestras vidas se están "digitalizando". Es un proceso lento, muy irregular y muy poco homogéneo, pero creo que es un proceso imparable. Poco a poco, todos tendremos que ir aprendiendo a convivir con nuestras "dos vidas", la física (la de toda la vida, o la real, como dirían algunos) y la digital, virtual o como quiera que se acabe llamando la vida que "vive" nuestra identidad digital, que queramos o no también es parte de nosotros.
¿Cuál es el problema de llevar esta "doble vida" (real y virtual)? Sencillamente, que esa duplicidad es una falacia. En realidad esa doble vida no existe, son sólo dos visiones de una vida única, la nuestra. Dos visiones distintas, desde perfiles diferentes, pero de una única realidad.
El problema de la "doble vida" no es nuevo. De hecho, es tan antiguo como la sociedad en la que vivimos. Todos tenemos distintos perfiles en la vida real: el profesional, el personal, el familiar... Perfiles distintos, en los que tratamos de potenciar distintas características, pero que normalmente siempre tratamos de que sean coherentes entre sí. Al fin y al cabo, no es tan difícil que los distintos perfiles acaben mezclándose, y si algo tenemos claro es que detrás de cada perfil siempre está uno mismo.
El problema con nuestros perfiles digitales es que a veces nos olvidamos de que nos siguen representando a nosotros. Y de que son perfiles mucho más ubicuos, persistentes y permeables, con muchas más posibilidades de mezclarse y expandirse. Y claro, si no son coherentes entre sí y con los de la "vida real", podemos tener un problema...
Ese problema de falta de coherencia entre perfiles es el que ha tenido la protagonista de la noticia que acabo de leer, acerca de una chica que ha perdido la pensión por depresión por estar alegre y de fiesta con sus amigas. Parece que su perfil "profesional real" (de baja por depresión) no era coherente con su perfil "personal virtual" (fotos en facebook de fiesta con las amigas), y debido a esa incoherencia la empresa aseguradora ha decidido suspender la remuneración que tenía asignada.
No voy a entrar en la pertinencia o no del hecho, y menos voy a analizar la legalidad o no de la decisión, sobre todo desde el punto de vista de las leyes españolas. Prefiero quedarme sólo con el fondo del asunto: ¿estamos preparados para gestionar adecuadamente nuestros perfiles digitales? ¿Hasta qué punto puede ser "la seguridad" la herramienta para llevar a cabo esta gestión? Y lo que es más importante: ¿Existen los medios para hacerlo? ¿O estamos intentando ponerle puertas al campo? Si alguien quiere hacer comentarios al respecto, ya sabe que aquí puede hacerlo.
23 noviembre 2009
19 noviembre 2009
Publicada ISO/IEC TR 20000-3:2009
Lo sé, hace más de un mes que no publico ningún post. La verdad es que últimamente ando envuelto en una vorágine profesional bastante agotadora... Aunque ya se empieza a ver la luz al final del tunel.
Hoy sencillamente quiero destacar la publicación hace un mes del estándar ISO/IEC TR 20000-3:2009, la tercera parte de la cada vez más conocida ISO 20000. Esta parte, cuyo título oficial es Information technology -- Service management -- Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1, es un "informe técnico" en el que se dan pautas sobre cómo se puede definir el alcance de un SGSTI (Sistema de Gestión de Servicios TI) en línea con las exigencias de la ISO 20000. Habla de la aplicabilidad de la ISO 20000 y de los principios generales para la definición de alcances, y sobre todo proporciona distintos ejemplos y escenarios para la definición de alcances válidos.
Para terminar, y en línea con este tema, para todo aquél que quiera profundizar en la definición de alcances para un SGSTI según ISO 20000 también puede consultar el documento "itSMF ISO/IEC 20000 Certification Scheme - Scoping Guidelines", que aunque date de 2006 sigue siendo perfectamente válido, y tiene la ventaja de que está redactado en un tono mucho más divulgativo que el documento anterior.
Hoy sencillamente quiero destacar la publicación hace un mes del estándar ISO/IEC TR 20000-3:2009, la tercera parte de la cada vez más conocida ISO 20000. Esta parte, cuyo título oficial es Information technology -- Service management -- Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1, es un "informe técnico" en el que se dan pautas sobre cómo se puede definir el alcance de un SGSTI (Sistema de Gestión de Servicios TI) en línea con las exigencias de la ISO 20000. Habla de la aplicabilidad de la ISO 20000 y de los principios generales para la definición de alcances, y sobre todo proporciona distintos ejemplos y escenarios para la definición de alcances válidos.
Para terminar, y en línea con este tema, para todo aquél que quiera profundizar en la definición de alcances para un SGSTI según ISO 20000 también puede consultar el documento "itSMF ISO/IEC 20000 Certification Scheme - Scoping Guidelines", que aunque date de 2006 sigue siendo perfectamente válido, y tiene la ventaja de que está redactado en un tono mucho más divulgativo que el documento anterior.
19 octubre 2009
Peligros en la nube
La verdad es que hoy no estoy demasiado inspirado. Me cuesta escribir, no consigo que me salga algo fluido y medianamente motivador, al menos como para que alguien quiera seguir leyendo hasta el final del post... Sin embargo, me he decidido a escribir algo más que nada por no dejar pasar la oportunidad de comentar muy brevemente un par de artículos que me han gustado.
El primero de ellos, en dos partes, es del que he sacado el título del post: Hack in the Box, el peligro está en la nube. Un artículo en el que su autora nos cuenta cómo el ciber-crimen se está orientando hacia la nube, a la par del incremento de popularidad de este tipo de soluciones. Era algo previsible, que no nos permite olvidarnos de una de las principales premisas en esto de la seguridad: las mayores amenazas siempre serán aquellas que siguen los devenires del negocio. O lo que es lo mismo, visto desde el lado contrario: allí donde se concentre un mayor volumen de negocio es el lugar óptimo para centrar los ataques intencionados. Obvio, pero no está de más recordarlo de vez en cuando, no sea que las típicas discusiones Windows Vs Linux vayan a transformarse, en su versión 2.0, en una discusión Nube Vs Local, y acabemos cayendo en los mismos fundamentalismos...
El segundo, sobre el que no he investigado demasiado pero que me parece muy interesante por su aproximación innovadora, es la idea de luchar contra las ciber-amenazas mediante el uso de hormigas digitales. La verdad es que no me queda muy claro si eso de crear tipos concretos de hormigas para luchar contra amenazas específicas puede ser una solución apropiada (me recuerda a la filosofía de los antivirus del uso de firmas, aunque es una interpretación totalmente personal), pero el simple hecho de buscar soluciones alternativas a un problema que actualmente no está siendo apropiadamente resuelto me parece una idea estupenda, más allá del éxito real que vaya a tener la solución concreta. Y yendo un poco más allá... ¿Habría más modelos de la naturaleza susceptibles de ser aplicados para solucionar el problema del malware? Al fin y al cabo, los animales llevan millones de años estableciendo mecanismos de lucha contra sus propios virus, bacterias y demás "malware"... ¿Serán estas hormigas los glóbulos blancos electrónicos que estamos buscando? El futuro lo dirá.
El primero de ellos, en dos partes, es del que he sacado el título del post: Hack in the Box, el peligro está en la nube. Un artículo en el que su autora nos cuenta cómo el ciber-crimen se está orientando hacia la nube, a la par del incremento de popularidad de este tipo de soluciones. Era algo previsible, que no nos permite olvidarnos de una de las principales premisas en esto de la seguridad: las mayores amenazas siempre serán aquellas que siguen los devenires del negocio. O lo que es lo mismo, visto desde el lado contrario: allí donde se concentre un mayor volumen de negocio es el lugar óptimo para centrar los ataques intencionados. Obvio, pero no está de más recordarlo de vez en cuando, no sea que las típicas discusiones Windows Vs Linux vayan a transformarse, en su versión 2.0, en una discusión Nube Vs Local, y acabemos cayendo en los mismos fundamentalismos...
El segundo, sobre el que no he investigado demasiado pero que me parece muy interesante por su aproximación innovadora, es la idea de luchar contra las ciber-amenazas mediante el uso de hormigas digitales. La verdad es que no me queda muy claro si eso de crear tipos concretos de hormigas para luchar contra amenazas específicas puede ser una solución apropiada (me recuerda a la filosofía de los antivirus del uso de firmas, aunque es una interpretación totalmente personal), pero el simple hecho de buscar soluciones alternativas a un problema que actualmente no está siendo apropiadamente resuelto me parece una idea estupenda, más allá del éxito real que vaya a tener la solución concreta. Y yendo un poco más allá... ¿Habría más modelos de la naturaleza susceptibles de ser aplicados para solucionar el problema del malware? Al fin y al cabo, los animales llevan millones de años estableciendo mecanismos de lucha contra sus propios virus, bacterias y demás "malware"... ¿Serán estas hormigas los glóbulos blancos electrónicos que estamos buscando? El futuro lo dirá.
15 octubre 2009
Integrando Sistemas de Gestión
En este blog he hablado muchas veces de los requisitos comunes a cualquier sistema de gestión "tipo ISO", y de las ventajas que puede tener la integración de todos ellos. Sin embargo, últimamente me he encontrado con algunos casos que, usando la integración como slogan, lo único que pretendían era aprovechar la existencia de un sistema de gestión (normalmente de calidad, ISO 9001) para reutilizar algunos de sus elementos en el nuevo sistema de gestión que estaban montando, ya sea de gestión medioambiental (ISO 14001), de seguridad de la información (ISO 27001) o cualquier otro. No es que me parezca mal (de hecho, me parece algo lógico y recomendable, dado que sirve para optimizar recursos), pero con lo que no estoy en absoluto de acuerdo es con que a éso se le llame Sistema de Gestión Integrado. Y como no me ha gustado que en un blog me hayan eliminado un comentario esbozando este planteamiento (aunque lo entiendo, ya que es un blog corporativo, y puede ser comprensible que la organización no quiera que aparezcan posturas críticas en una herramienta de marketing), he decidido presentarlo aquí.
Como decía, existen ciertas prácticas que pueden ser recomendables a la hora de solapar o superponer (creo que cualquiera de estos dos términos sería más apropiado) sistemas de gestión. Es conveniente reutilizar las prácticas de gestión desarrolladas, lo que a nivel tangible se convierte en reutilizar la documentación, usando, por ejemplo, los mismos procedimientos de gestión documental y/o de registros o los mismos procedimientos de auditoría. No obstante, no hay que olvidar la especificidad de cada sistema de gestión, y por tanto habrá que ampliar el ámbito de actuación de dichas prácticas a los diversos entornos, de la forma que corresponda en cada caso. Eso nos puede llevar, entre otras cosas, a fusionar en un único documento textos equivalentes en distintos sistemas de gestión, consiguiendo, por poner un ejemplo, un documento único que recoja la política de calidad y seguridad de la información. Del mismo modo podremos acabar teniendo documentos únicos para ambos sistemas de gestión en los que se hable de responsabilidades de la dirección, mejora continua, gestión de no conformidades, ... Si pensamos en el apartado de roles y responsabilidades, algo que también suele ser habitual a la hora de solapar sistemas de gestión es intentar aprovechar las estructuras de gestión existentes (Responsable, Comité, etc.) para el nuevo sistema de gestión. Aunque claro, aquí puede no ser tan sencilla la reutilización, dado que en cada caso se requieren una capacitación y conocimientos específicos y diferenciados, y saber gestionar, por ejemplo, la calidad, no implica saber hacerlo con el medioambiente o la seguridad de la información.
Llegados a este punto es cuando hay que ver qué hemos conseguido al solapar distintos sistemas de gestión: tener una manera común de gestionar cosas distintas. Y ese creo que es precisamente el problema. Si buscamos el término integrar en el diccionario, vemos que hace referencia a la constitución de un todo, de algo global que sintetice las partes. Por lo tanto, creo que no basta con "integrar" la sistemática de gestión (que en realidad ya era la misma), sino que la clave para conseguir un sistema de gestión integrado es ser capaz de integrar aquello que se gestiona, es decir, poder gestionar de manera integrada la calidad, la seguridad o lo que corresponda en cada caso.
Para mí el primer requisito (necesario, pero no suficiente) de un Sistema de Gestión Integrado es, sin duda, que el alcance de ambos sea coincidente. Es más, no creo que se pueda hablar de que cosas distintas puedan estar integradas si su ámbito de aplicación no coincide. A partir de ahí, creo que para hablar de integración de verdad (permitidme que me centre en calidad y seguridad de la información, que es lo que mejor domino) tenemos que ser capaces de considerar de forma simultánea la calidad y la seguridad, y poder entender la una como parte de la otra (y viceversa). No creo que se pueda hablar de integración entre ambos sistemas de gestión si no consideramos la seguridad de la información en en nuestros procesos productivos, si la seguridad no es un factor intrínseco en la selección de proveedores, o si en nuestros análisis de riesgos no consideramos factores de riesgo relacionados con la calidad. En definitiva, creo que para hablar de un Sistema de Gestión Integrado tenemos que centarnos fundamentalmente en integrar aquello que se gestiona (que es lo difícil, obviamente). Y creo que esto es mucho más importante que tratar de que el responsable de calidad y el de seguridad sean la misma persona, ya que incluso se podría hablar de sistemas de gestión integrados en el caso de que sean distintos responsables.
En definitiva, creo que a veces las organizaciones pierden un poco el norte con tanto sistema de gestión normalizado, y se olvidan de que las empresas lo que deberían tener es un único sistema de gestión, el de la organización, independientemente de que el sistema cumpla o no los requisitos de más o menos sistemas de gestión normalizados, o de que ese cumplimiento esté o no certificado por alguien. La preocupación de cualquier organización debe ser el negocio, y negocio no sólo es calidad, o seguridad, sino la suma de todo ello y de mucho más. Así que estaría bien pensar un poco más en tener un sistema de gestión del negocio, que integre la gestión de todos los elementos que lo componen, y no preocuparnos tanto por modas o certificaciones que, si hacemos las cosas bien, se acaban integrando "solas"...
Como decía, existen ciertas prácticas que pueden ser recomendables a la hora de solapar o superponer (creo que cualquiera de estos dos términos sería más apropiado) sistemas de gestión. Es conveniente reutilizar las prácticas de gestión desarrolladas, lo que a nivel tangible se convierte en reutilizar la documentación, usando, por ejemplo, los mismos procedimientos de gestión documental y/o de registros o los mismos procedimientos de auditoría. No obstante, no hay que olvidar la especificidad de cada sistema de gestión, y por tanto habrá que ampliar el ámbito de actuación de dichas prácticas a los diversos entornos, de la forma que corresponda en cada caso. Eso nos puede llevar, entre otras cosas, a fusionar en un único documento textos equivalentes en distintos sistemas de gestión, consiguiendo, por poner un ejemplo, un documento único que recoja la política de calidad y seguridad de la información. Del mismo modo podremos acabar teniendo documentos únicos para ambos sistemas de gestión en los que se hable de responsabilidades de la dirección, mejora continua, gestión de no conformidades, ... Si pensamos en el apartado de roles y responsabilidades, algo que también suele ser habitual a la hora de solapar sistemas de gestión es intentar aprovechar las estructuras de gestión existentes (Responsable, Comité, etc.) para el nuevo sistema de gestión. Aunque claro, aquí puede no ser tan sencilla la reutilización, dado que en cada caso se requieren una capacitación y conocimientos específicos y diferenciados, y saber gestionar, por ejemplo, la calidad, no implica saber hacerlo con el medioambiente o la seguridad de la información.
Llegados a este punto es cuando hay que ver qué hemos conseguido al solapar distintos sistemas de gestión: tener una manera común de gestionar cosas distintas. Y ese creo que es precisamente el problema. Si buscamos el término integrar en el diccionario, vemos que hace referencia a la constitución de un todo, de algo global que sintetice las partes. Por lo tanto, creo que no basta con "integrar" la sistemática de gestión (que en realidad ya era la misma), sino que la clave para conseguir un sistema de gestión integrado es ser capaz de integrar aquello que se gestiona, es decir, poder gestionar de manera integrada la calidad, la seguridad o lo que corresponda en cada caso.
Para mí el primer requisito (necesario, pero no suficiente) de un Sistema de Gestión Integrado es, sin duda, que el alcance de ambos sea coincidente. Es más, no creo que se pueda hablar de que cosas distintas puedan estar integradas si su ámbito de aplicación no coincide. A partir de ahí, creo que para hablar de integración de verdad (permitidme que me centre en calidad y seguridad de la información, que es lo que mejor domino) tenemos que ser capaces de considerar de forma simultánea la calidad y la seguridad, y poder entender la una como parte de la otra (y viceversa). No creo que se pueda hablar de integración entre ambos sistemas de gestión si no consideramos la seguridad de la información en en nuestros procesos productivos, si la seguridad no es un factor intrínseco en la selección de proveedores, o si en nuestros análisis de riesgos no consideramos factores de riesgo relacionados con la calidad. En definitiva, creo que para hablar de un Sistema de Gestión Integrado tenemos que centarnos fundamentalmente en integrar aquello que se gestiona (que es lo difícil, obviamente). Y creo que esto es mucho más importante que tratar de que el responsable de calidad y el de seguridad sean la misma persona, ya que incluso se podría hablar de sistemas de gestión integrados en el caso de que sean distintos responsables.
En definitiva, creo que a veces las organizaciones pierden un poco el norte con tanto sistema de gestión normalizado, y se olvidan de que las empresas lo que deberían tener es un único sistema de gestión, el de la organización, independientemente de que el sistema cumpla o no los requisitos de más o menos sistemas de gestión normalizados, o de que ese cumplimiento esté o no certificado por alguien. La preocupación de cualquier organización debe ser el negocio, y negocio no sólo es calidad, o seguridad, sino la suma de todo ello y de mucho más. Así que estaría bien pensar un poco más en tener un sistema de gestión del negocio, que integre la gestión de todos los elementos que lo componen, y no preocuparnos tanto por modas o certificaciones que, si hacemos las cosas bien, se acaban integrando "solas"...
13 octubre 2009
Continuidad de Negocio en la practica
Aunque debo reconocer que últimamente mi agenda está más apretada de lo que a mí me gustaría, también es cierto que a veces esa agenda me da la oportunidad de participar en foros muy interesantes y hablar con verdaderos profesionales de nuestro sector.
La semana pasada tuve la suerte de participar en un foro sobre Continuidad de Negocio en la Universidad de Deusto, donde algunos tratamos de exponer nuestras experiencias y puntos de vista sobre la continuidad de negocio desde un punto de vista práctico. No voy a hacer un resumen de las ponencias que allí se presentaron, pero sí destacar algunos comentarios que allí se hicieron, y que creo que puede ser interesante recordar:
La semana pasada tuve la suerte de participar en un foro sobre Continuidad de Negocio en la Universidad de Deusto, donde algunos tratamos de exponer nuestras experiencias y puntos de vista sobre la continuidad de negocio desde un punto de vista práctico. No voy a hacer un resumen de las ponencias que allí se presentaron, pero sí destacar algunos comentarios que allí se hicieron, y que creo que puede ser interesante recordar:
- Negocio, Negocio, y Negocio: esa es la palabra clave de la continuidad. Lo siento por los tecnófilos, pero la tecnología es un medio, no un fin (aunque a veces sea un medio importantísimo).
- En un análisis de riesgos de continuidad, el impacto es más importante que la probabilidad, y por tanto su escala debería ser ponderada al alza (es decir, impacto alto y probabilidad baja supone mayor riesgo que probabilidad alta e impacto bajo).
- La clave de la continuidad de negocio es la eficacia, pero es desde la eficiencia desde donde conseguiremos "vender" los planes de continuidad e incluso encontrar el ROI.
- Si una organización es lo suficientemente madura no hace falta "vender" la continuidad, la propia dirección de la organización será quien se preocupe de que el negocio continúe y de sacar partido a los foros de continuidad desarrollados.
- Los incidentes son las pruebas de continuidad más perfectas que podemos encontrarnos: no perdamos la oportunidad de aprender de ellos.
- La comunicación es un factor clave en la gestión de la crisis, si no controlamos la imagen transmitida todos nuestros esfuerzos pueden verse abocados al fracaso.
Estos son sólo algunos de los mensajes que me vienen a la memoria. De todas formas, seguro que tanto los que estuvisteis allí como los que no tuvisteis la oportunidad tenéis otros mensajes igual de importantes que añadir a la lista. ¿Estáis dispuestos a compartirlos? Espero vuestros comentarios.
29 septiembre 2009
Matices de ISO 20000
En el último post prometía explicar la fórmula que sirve para entender la ISO 20000, o al menos aclarar los importantes matices que tiene. La fórmula en cuestión es la siguiente:
El segundo elemento de la ecuación son los procesos. La ISO 20000 plantea 13 procesos divididos en 5 grupos de procesos, que nosotros podríamos "reagrupar" en 3: procesos de provisión del servicio, procesos de relación y procesos de soporte al servicio (agrupando los de resolución, control y entrega). De este modo es fácil identificar la analogía con ITIL v2, ya que en gran medida la definición de procesos en ambos casos es solapable. No obstante, hay ciertas diferencias: ISO 20000 introduce la gestión de la seguridad dentro de los procesos de provisión (en ITILv2 es independiente), agrupa la gestión de la continuidad y la disponibilidad (en ITILv2 son procesos separados) e introduce como proceso la gestión de informes (en ITIL no existe), dando un mayor peso específico a la monitorización y reporte de información. Con algunos otros matices de menor importancia, podemos decir que en el resto de los aspectos ambas referencias son solapables, si obviamos el hecho de que la ISO 20000 habla de requisitos mínimos e ITIL de "referencias máximas".
Las diferencias más profundas entre ISO 20000 e ITIL vienen provocadas, principalmente, por su fecha de publicación. Mientras que ITIL v2 data de 2001, ISO 20000 fue publicada en 2005, e ITIL v3 lo fue en 2007. Esto hace que dicha evolución se pueda ver como un modelo incremental en el que se van incorporando evoluciones conceptuales, cuyo mayor exponente es el ciclo de vida del servicio. Mientras que ITIL v2 es un modelo "estático" ISO 20000 esboza dicho concepto en su apartado 5, mientras que ITIL v3 lo desarrolla completamente en su nuevo modelo de procesos.
Efectivamente, el tercero de los elementos que incorpora ISO 20000 es el desarrollo de los servicios, o más específicamente la planificación e implementación de los servicios. En realidad no es un concepto nuevo, dado que ya venía recogido en el olvidado libro de ITIL v2 Planing to implement service management. No obstante, ISO 20000 tiene el mérito de recuperar su esencia, muy en línea con conceptos tan de moda actualmente como el de Gobierno TI, e introducirlo como elemento imprescindible de un Sistema de Gestión de Servicios TI. Es en realidad uno de los aspectos más importantes de la ISO 20000, y el elemento diferencial para las organizaciones que, pese a haber adoptado un "modelo ITIL" para sus procesos, sienten que les falta alguna pieza... Y por último, también es un guiño para todos aquellos entusiastas de la ISO 9001 que, pese a todo, se hayan quedado con la sensación de que hay partes de esa norma que no quedan suficientemente cubiertas por la ISO 20000.
- ISO 20000 = ISO 9001 + ITIL + Desarrollo de los servicios
El segundo elemento de la ecuación son los procesos. La ISO 20000 plantea 13 procesos divididos en 5 grupos de procesos, que nosotros podríamos "reagrupar" en 3: procesos de provisión del servicio, procesos de relación y procesos de soporte al servicio (agrupando los de resolución, control y entrega). De este modo es fácil identificar la analogía con ITIL v2, ya que en gran medida la definición de procesos en ambos casos es solapable. No obstante, hay ciertas diferencias: ISO 20000 introduce la gestión de la seguridad dentro de los procesos de provisión (en ITILv2 es independiente), agrupa la gestión de la continuidad y la disponibilidad (en ITILv2 son procesos separados) e introduce como proceso la gestión de informes (en ITIL no existe), dando un mayor peso específico a la monitorización y reporte de información. Con algunos otros matices de menor importancia, podemos decir que en el resto de los aspectos ambas referencias son solapables, si obviamos el hecho de que la ISO 20000 habla de requisitos mínimos e ITIL de "referencias máximas".
Las diferencias más profundas entre ISO 20000 e ITIL vienen provocadas, principalmente, por su fecha de publicación. Mientras que ITIL v2 data de 2001, ISO 20000 fue publicada en 2005, e ITIL v3 lo fue en 2007. Esto hace que dicha evolución se pueda ver como un modelo incremental en el que se van incorporando evoluciones conceptuales, cuyo mayor exponente es el ciclo de vida del servicio. Mientras que ITIL v2 es un modelo "estático" ISO 20000 esboza dicho concepto en su apartado 5, mientras que ITIL v3 lo desarrolla completamente en su nuevo modelo de procesos.
Efectivamente, el tercero de los elementos que incorpora ISO 20000 es el desarrollo de los servicios, o más específicamente la planificación e implementación de los servicios. En realidad no es un concepto nuevo, dado que ya venía recogido en el olvidado libro de ITIL v2 Planing to implement service management. No obstante, ISO 20000 tiene el mérito de recuperar su esencia, muy en línea con conceptos tan de moda actualmente como el de Gobierno TI, e introducirlo como elemento imprescindible de un Sistema de Gestión de Servicios TI. Es en realidad uno de los aspectos más importantes de la ISO 20000, y el elemento diferencial para las organizaciones que, pese a haber adoptado un "modelo ITIL" para sus procesos, sienten que les falta alguna pieza... Y por último, también es un guiño para todos aquellos entusiastas de la ISO 9001 que, pese a todo, se hayan quedado con la sensación de que hay partes de esa norma que no quedan suficientemente cubiertas por la ISO 20000.
Suscribirse a:
Entradas (Atom)
