Búsqueda


29 de abril de 2008

El número 191 de Novática

En algún momento anuncié en este blog que estaba participando en el equipo editorial de Novática para producir un monográfico sobre IT Governance que tendría que mostrar el estado del arte en este tema.

novagran-2007

Pues bien, el número 191 de Novática ya está aquí. En estos momentos debe estar viajando desde la imprenta a tu casa o a tu oficina y el próximo día 14 de Mayo se hará una presentación de este número en un breve acto cuya convocatoria es la siguiente:

Es un placer invitaros a la presentación de la monografía sobre IT Governance del número 191 de la revista Novática, que tendrá lugar el próximo miércoles 14 de mayo en la sala Verdaguer del Ateneo Barcelonès.


La AGENDA de la sesión será:
1. Presentación de la monografía de IT Governance.
2. Estado del arte de los modelos y marcos referencia de IT Governance.
3. Situación de IT Governance en España.
4. Presentación del punto de vista de un usuario de una gran institución.


Datos generales del acto:
Fecha: 14/05/08
Horario: de las 18.30 a las 20 h.
Lugar: Sala Verdaguer, Ateneus Barcelonès
Carrer de la Canuda nº 6
08002 Barcelona
Inscripciones: secrecat@ati.es / 934125235
Esta misma información la encontraréis en:
http://www.ati.es/article.php3?id_article=924

Esta monografía ha sido un auténtico reto, tanto dentro de la trayectoria habitual de Novática como de organización, ya que hemos podido contar con estrellas nacionales, el Grupo de Trabajo del itSMF España que firma uno de los artículos presentados o Jorge Fernández entre otros y estrellas internacionales como Jan van Bon o Rob England (más conocido como The IT Skeptic).

Si puedes asistir al evento, creo que será una oportunidad interesante de ver otras aproximaciones al Gobierno de las TIC desde una entidad con tanto peso como ATI. Y si no puedes, haz lo posible por conseguir un ejemplar de la revista porque será un bombazo.

Desde aquí mi más sincero agradecimiento a todos aquellos que han hecho posible la publicación del número 191 de Novática y a aquellos que me dieron la oportunidad de participar en el equipo editorial.

Nuevo estándar ISO para el Gobierno de las TIC

Hace un poco más de un año, en Noviembre del 2007, Jan van Bon pasó por Barcelona y dio una conferencia en un evento del capítulo Catalunya del itSMF España. Durante esa conferencia dejó caer que se estaba cocinando un nuevo estandard para el Gobierno de las TIC a partir de un estándard australiano que no debíamos dejar de revisar porque estaba en modo Fast-Track para convertirse en una norma ISO.

Como el tema me llamó la atención, hice un poco de búsqueda de información hasta que pude echarle un ojo a la norma australiana: la AS8015-2005 y publiqué en este blog un post en el que explicaba los contenidos de esta norma.

Bueno, ha pasado un año y medio y el nuevo estándar verá la luz el próximo 22 de Mayo en Holanda (cómo no!) donde bITa Center ha organizado un evento de presentación donde se explicarán los contenidos de la nueva norma ISO/IEC 38500 - Corporate Governance of Information Technology.

Aún no he podido leer la nueva norma, pero Mark Toomey (uno de los promotores de la norma) ha explicado en algunos foros las bases principales de la norma:

  1. Es una versión corregida y aumentada de la norma australiana AS8015-2005
  2. Define seis principios para "el buen gobierno del uso de las TIC": Responsabilidad, Estrategia, Adquisición, Rendimiento, Cumplimiento y Comportamiento Humano (los mismos 6 principios presentes en la AS8015)
  3. Establece las tareas que se deben implementar en el Sistema de Gobierno (ojo!): Evaluar, Dirigir y Monitorizar el uso actual y futuro de las TIC para el cumplimiento de los objetivos de la organización.

Uno de los comentarios más interesantes es al respecto de la aproximación "de fuera a adentro" que hace esta visión del Gobierno: estamos hablando "del uso que se hace de las TIC" y no "de la provision que hacemos desde las TIC hacia 'el negocio'".

IT is a tool of business. It is the job of business to determine how, when, where and why it will use the tool – and it is the job of IT to then deliver the tool that fulfils the need. In too many organisations, the business abdicates its role to IT - and wonders why IT does not get it exactly right. In some organisaitons, having abdicated its own job to IT and been dissatisfied, the business then either abdicates its role further – outsourcing supply and trying to outsource its own responsibilities as well – or trying to take on the delivery (supply) role of IT.

The new ISO standard is actually an umbrella that spans both demand (what the business is responsible for) and supply (what the IT department is responsible for). This should help organisations be more clear about what is happening when they do an ITIL of other supply side initiative, and it should help with clarifying what’s not covered by such projects.

 

Por último, otra de las perlas de Mr. Mark es al respecto del concepto de Sistema de Gobierno, algo que sonar, me suena feo... pero que con la explicación de Mark suena mucho, pero que muchísimo mejor:

But “system” is also a fundamental concept. When we think of a system, we think of a set of processes, performed by people with appropriate skills and training, operating within some sort of an organisaiton or control (or authority) structure, and with supporting tools and technology. A Governance System comprises all of these elements, and to get the right system means that work must be done to design and implement that system. Corporate Governance of IT does not merely “happen” – it must be planned and implemented. And once implemented, it must be improved on an ongoing basis to ensure that it continues to be effective, efficient and acceptable.

23 de abril de 2008

De birras con el sector duro

I amar prestar aen
Han mathon ne nen
Han mathon ne chae
A han noston ned wilith
[...]

El mundo está cambiando
Lo siento en el agua
Lo siento en la tierra
Lo huelo en el aire
Mucho de lo que era, se ha perdido...
pero nadie vive que lo recuerde

Interpretación libre del Señor de los Anillos

Los días 21 y 22 de Abril se hizo historia. Tuve el increíble privilegio de que Jan van Bon me invitara a la conferencia organizada por itSMF-NL (si no la cuna, el sitio donde ITIL creció) y por bITa Center en un pequeño pueblo de Holanda llamado Ede.

Cuando vi el cartel de la conferencia, no le presté demasiado interés al título; ya se sabe, que eso es cosa de "los de marketing" y poco importa... pero esta vez iba en serio: Beyond ITIL. Beyond Control. Tenía que significar algo así como "Más allá de ITIL. Más allá del Control" y yo le di el significado de..."Hasta el infinito y más allá", pero no tardaría en darme cuenta de cuán equivocado estaba.

Cuando comencé a ver a los ponentes, vi (en realidad ya lo sabía, pero lo pude confirmar en ese momento) a Rob England entre ellos: mi apreciado IT Skeptic iba a estar en Holanda!

Pero cuando llegué allí, me encontré con que no sólo compartiría mesa con Jan y Rob... además había personajes de la talla de Ian Clayton, Paul Wilkinson o Brian Johnson (no! el cantante de AC/DC, no.. ese no!) y la preconferencia fue una fantástica tarde/noche que acabó más allá de las 12 de la noche entre cervezas, charla y crítica... mucha crítica.

Al día siguiente, una apretada agenda de conferencias (lástima, casi todas en Holandés y sin traducción, pero con un track en inglés que fue más que suficiente) en el que se fue perfilando claramente que el sentido de "Más allá de ITIL" en realidad era algo así como "Ya está bien de ITIL" y lo de "Más allá del control" en realidad era "Y nos vamos a librar del control".

Señores, el pensamiento crítico que ha hecho visible Rob England en su blog y que en realidad viene como una corriente subterránea acercándose desde hace dos décadas, ha confluido en Ede esta semana, ha marcado historia y la comunidad más avanzada del mundo en temas de Service Management ha dicho claramente que hacen falta alternativas, mejoras y nuevos puntos de vista.

El mundo está cambiando (I amar prestar aen), pronto veremos alternativas más prácticas, abiertas, colaborativas y sobre todo, no ligadas a un copyright, trademark o propiedad exclusiva.

Porque mucho de lo que era, se ha perdido...pero nadie vive que lo recuerde, aunque en el caso de ITIL autores como Brian Johnson que participaron en los primeros libros de ITIL V1 sí que recuerdan cuál era el espíritu original: la comunidad de usuarios, el cliente, la Gestión del Servicio, el cliente, la profesión y el cliente.

P1020712

17 de abril de 2008

Aléjate de la tecnología

Leo en el blog de Jacques una fábula entretenida, pero la frase de cierre del post es la que me gusta y me hace hacerle una referencia-reverencia desde aquí:

Si quieres gestionar bien la informática de tu empresa, opta por la asepsia. No te metas. Compra cosas probadas y garantizadas. Con garantía de 3 ó 4 años. Cuando finalice la garantía, cambia de modelo. Y, si tienes la tentación irresistible de acercarte a la tecnología, analiza la información; qué haces con ella; quién la recibe; para qué la usa.

Siempre con el lápiz afilado, Jacques! :-)

14 de abril de 2008

Integrar las herramientas

Como veíamos en el artículo anterior de esta serie, hay una serie de condiciones que pueden justificar la unificación de herramientas:

  • Actividades externalizadas "autocontenidas"
  • Equipos de trabajo monocliente
  • Posición de fuerza de negociación con los proveedores

Pero hay muchos casos en los que no se dan las condiciones necesarias como para poder unificar las herramientas: los proveedores de servicios utilizan las economías de escala para reducir sus costes y obtener los beneficios que justifican estas líneas de negocio, y eso en el sector servicios se consigue garantizando la ocupación del 100% de la carga de trabajo en actividades que reporten beneficios a la compañía.

Esta situación nos lleva directamente a que, para hacer rentable un equipo de trabajo, el outsourcer tiene principalmente dos opciones:

  • Conseguir un contrato que le permita facturar el 100% de la ocupación del personal al mismo cliente (lo que nos lleva a la situación de equipos monocliente)
  • Conseguir múltiples contratos con diferentes clientes y ocupar al equipo en actividades multicliente.

Esta segunda opción es la que nos encontraremos en la gran mayoría de situaciones, donde un grupo de trabajo (operadores, administradores, desarrolladores, etc) dedica su actividad a diferentes clientes, aprovechando de esta manera "los tiempos muertos" y permitiendo hacer una aproximación al mercado de menor coste (por cliente) pero de mayor beneficio (global).

Así, rompemos la premisa que nos permite unificar herramientas y vemos que la aproximación de integración de herramientas comienza a cobrar fuerza, pero es una vía llena de obstáculos y dificultades.

Para poder llevar con éxito un proceso de integración de este estilo, es recomendable seguir una aproximación más o menos metodológica al proyecto:

  1. Definir lo más detalladamente posible los resultados esperados de la integración.
  2. Diseñar / Modificar el modelo de procesos (integrados) para asegurar que pueda producir el conjunto de resultados esperados.
  3. Construir el meta-modelo de datos, sabiendo qué datos deben fluir, cuándo y con qué mapeos de información.
  4. Escoger la herramienta que nos permitirá hacer todo esto.
  5. Implementar una maqueta / piloto que nos permita refinar todo lo diseñado en los pasos anteriores
  6. Implementar la integración
  7. Diseñar / Modificar los procedimientos operativos, para asegurar que permiten generar los resultados esperados y que se adaptan a los nuevos requerimientos generados por el proceso de integración.
  8. Paso a Producción
  9. Matenimiento in-eternum de la integración

Si llegas con éxito al punto 8, las cosas habrán cambiado de una forma drástica en la forma de trabajar. A partir de ese momento, ocurre que la integración comienza a desvelar toda una serie de situaciones que antes no se notaban: las <n> compañías ahora están atadas por un vínculo que no tiene sentido común ni creatividad y que "canta" los errores que se producen.

quantum-marker-art-bgAsí, cualquier variación en los datos que están incluidos en el meta-modelo significa que se debe adaptar la integración (por ejemplo, una modificación en las categorías de la organización 1 implica que se debe decidir a nivel de integración qué queremos hacer con esa categoría en la organización 2); otro ejemplo es que algunos de los cambios que se produzcan en las operativas de cualquiera de estas organizaciones puede afectar seriamente a la integración (ya que tenemos definido en qué momento se traspasa la información, sea por el mecanismo que sea).

En este momento, es muy fácil que la integración se vea como un obstáculo a la evolución de todas las organizaciones participantes del sistema: pero en realidad lo que ocurre es que antes de la integración cada entidad iba por libre, con intercambios de información nulos o mínimos, en un conjunto de sistemas independientes que evolucionaban cada uno como quería y, desde el momento en que los hemos unido con una cuerda, los sistemas ya no son independientes y deben "tenerse en cuenta" unos a otros.

Por lo tanto, hay un par de factores que son especialmente sensibles y que deben ser analizados con cuidado antes de lanzarse a una aventura como esta:

  1. ¿Vale la pena? Es decir, los beneficios que vamos a obtener una vez analizado el punto (1) de nuestra aproximación metodológica son superiores al esfuerzo y costes que vamos a incurrir? Quizás no es únicamente una cuestión de coste/beneficio sino de necesidad / ley /cumplimiento.
  2. ¿Tengo un circuito de cambios maduro, que me garantice que no vamos a romper la integración continuamente por modificaciones no controladas?
  3. Para garantizar la agilidad, ¿la herramienta escogida me acompaña?

Por último, y como consejo aprendido en las trincheras, a polvo, sudor y hierro (como el Cid): KISS Hazlo simple, no compliques en exceso el nivel de detalle con el que quieres intercambiar información porque en el extremo de esa complicación está el modelo de herramientas unificadas. Todo en su justa medida.

8 de abril de 2008

Mejor huevo que hamburguesa

No suelo hacer "copy&paste" de posts que vea en otros blogs, pero este me ha gustado, es simpático y está lleno de empuje y ganas de hacer (trempera, que dirían los catalanes).

Lo he leído en el blog de Infonomía, "la red de innovadores" y lo ha escrito Jose Luis Montero, director de Innova, aunque en realidad proviene de un post de Ynnova-Te, el blog del autor.

¡Qué bueno!

El futuro lejos de parecerse a una hamburguesa, se asemeja a un huevo. El huevo que encierra en su cáscara una clara y yema indomables. Una clara y yema que al caer en la sartén se expanden en todas direcciones de forma impredecible. Y es que los planes estratégicos son útiles para conocerse, calcular fuerzas y, sobre todo, construir sueños a los que aspirar. Pero el futuro jamás será una hamburguesa, para nuestra fortuna es un indómito huevo. Y es que, como decía Ortega y también mi abuela: la Vida son nuestros actos. En esto reside la gracia de la Innovación.

Unificar las herramientas

Una de las posibles opciones que aparecían como ganadoras en la encuesta que comentábamos en el post anterior es la de unificar.

La idea que hay detrás de unificar las herramientas es simple de explicar, pero bastante difícil de conseguir: la organización diseña sus procesos, implanta una herramienta que los soporte y consigue que sus proveedores utilicen esta herramienta para el seguimiento de todas las actividades dentro de los procesos establecidos.

La principal ventaja que nos da esta aproximación es que toda la información relativa a las actividades de un proceso queda almacenada en un único sitio, con lo que la complejidad del seguimiento, monitorización, extracción de métricas y reporting se reduce considerablemente.

A priori, y desde el punto de vista de la organización que externaliza, todo parece perfecto pero... es en el interior de esta herramienta única donde comienzan a aparecer las dificultades.

El primer punto complicado es conseguir convencer a mis proveedores de que deben utilizar mi herramienta y seguir mis pautas de trabajo: si lo tengo resuelto por contrato (es decir, tuve en cuenta esta situación en el momento de firmar el acuerdo de externalización), posiblemente será mucho más sencillo; pero si ya tengo al proveedor en casa y he de cambiar su forma de trabajo, la cosa puede ser administrativamente complicada.

Una vez que lo haya conseguido, me encontraré con la segunda parte complicada: cuando uno externaliza una parte de las actividades de TI, quiere olvidarse de la gestión operativa del día a día, de la contratación de nuevo personal, de su formación... uno compra "un servicio", porque de lo contrario, lo que haría es contratar personal. Pero en esta herramienta debo mantener, por ejemplo, los grupos de trabajo a los que se escalan las incidencias, las cuentas de cada uno de estos usuarios y estar informado de los movimientos que se realizan en el personal para que se mantengan en la aplicación.

Vamos a poner un par de ejemplos especialmente dolorosos:

¿Podremos entrar en la herramienta todas aquellas personas que van a participar en la provisión de una nueva línea de comunicaciones, para poder ir asignando la petición de uno a otro técnico y de uno a otro grupo de trabajo?

¿Podremos tener en la herramienta las cuentas de usuario de todos los programadores hindúes que participarán en el mantenimiento evolutivo de mi SAP, y de los jefes de proyecto y coordinadores?

Así, cuando los equipos de trabajo que me prestan los servicios están trabajando "en mi casa" o son lo suficientemente reducidos y estables como para que los podamos mantener correctamente, puede ser que la unificación de herramientas sirva como alternativa para algunos tipos de procesos, pero no para todos.

El tercer punto de fricción lo vamos a encontrar cuando los diferentes proveedores que van a trabajar con mi herramienta quieran tener diferentes formas de trabajar. Aquí se puede armar un lío de consideración, así que la única solución posible es mano dura y firmeza: soy yo quien define los procesos, y por lo tanto soy yo quien define la manera de trabajar. Porque si no lo hacemos así, tendremos que parametrizar (configurar, diseñar o lo que sea) la herramienta para múltiples modelos de procesos, con lo que terminaré con 10 herramientas metidas en una sola y además administrándola yo!!

Por último, está el aspecto económico de la cuestión (que debe ser consensuado en el momento de la contratación de los servicios): ¿Quién paga las licencias de usuario?

En definitiva, y como conclusión: desde mi punto de vista, la unificación de herramientas es un modelo que sirve cuando las actividades externalizadas están "autocontenidas" y los equipos de trabajo que nos prestan el servicio son monocliente, como por ejemplo cuando externalizo la atención telefónica y un equipo de personas presta este servicio únicamente a mi organización.

Es en estos casos en los que se puede definir una única manera de trabajar (porque no habrá conflicto con las maneras de trabajar de otros clientes que utilicen al mismo equipo), una única herramienta (porque tampoco tendremos a un equipo de gente trabajando con tantas herramientas como clientes) y porque podremos realizar una administración centralizada de esta herramienta.

7 de abril de 2008

Integrar, unificar o ninguna de las anteriores

Cada vez más nos encontramos en que los Departamentos de TI no trabajan de una forma independiente o aislados del mundo exterior; el concepto de "People, Process & Technology" ha evolucionado y ahora se debe hablar casi que obligatoriamente de People, Process, Technology & Partners y es muy frecuente (cotidiana, más bien) la externalización de parte de los procesos o actividades dentro del área TIC en contratos con terceras partes.

De igual manera, es cada vez menos habitual encontrar compañías que tengan acuerdos de carácter exclusivo y que trabajen únicamente con un único proveedor, por lo que es fácil que lleguemos a encontrar tres o más proveedores diferentes dando distintos tipos de servicios (ya sean profesionales o servicios TIC).

Así, ¿quién no ha visto un Departamento TIC con parte del soporte (aunque sea el tercer nivel) contratado con un tercero, a la vez que dispone de un servicio de Hosting por parte de otro proveedor diferente, el desarrollo del ERP contratado con otro y el desarrollo de las páginas Web en un cuarto?

Es normal que contratemos en el exterior aquello que necesitamos, y además lo contratemos a diferentes empresas en función de los parámetros de compra que tengamos (especialización, homologación de proveedores, precio, etc); pero en un entorno organizado por procesos (y recordemos que los procesos son cross-funcionales) esta contratación en el exterior puede complicar realmente las cosas.

¿Cómo puedo realizar una correcta gestión del cambio cuando tengo el proveedor de hosting y el de desarrollo en diferentes compañías? ¿Como puedo hacer un correcto seguimiento (y medición) de estas actividades? ¿Cómo le escala mi proveedor de ServiceDesk una incidencia al proveedor de aplicaciones en modo ASP de Noruega?

Obviamente, no hay demasiadas alternativas: por una parte está la correcta coordinación y control de todo esto (que desde mi punto de vista debe ser ejecutado en un 99% de los casos por personal propio de la empresa en cuestión: es decir, se puede externalizar/subcontratar la ejecución de las tareas pero no la gestión y gobierno, salvo excepciones muy, pero que muy contadas), por otra parte está el tener en cuenta esta característica de "multiempresa" en el diseño de los procesos y, por último, está la esencial toma de decisión al respecto de qué pasa con las herramientas que nos van a permitir articular o implementar nuestros procesos.

Este último punto es el que provocó a principios de año la realización de una pequeña encuesta que se publicó en este blog y cuyos resultados aún se pueden encontrar al final de la barra de la derecha.

Vaya por delante que los resultados de la encuesta no sirven nada más que para saciar nuestra curiosidad, porque con 19 votos y además de respuesta múltiple no vamos a ningún sitio, pero...

  1. El 42% dijo que integraría las herramientas propias con las del proveedor
  2. Otro 42% optó por la unificación: una única herramienta (mía) y que los proveedores la usen.

Y aquí es donde nace el título de este post... integro, unifico o ninguna de las anteriores (que son las otras diferentes opciones que hay en la encuesta).

5 de abril de 2008

Metodologías Ágiles y Gestión de Organizaciones

No soy, para nada, un experto en el mundo de las metodologías ágiles; ni si quiere puedo decir que sea un entendido, ni tan sólo apenas un conocedor, pero me llama mucho la atención el crecimiento que está teniendo este concepto.

Para mi todo empezó con el primer post de Sistemas Decisionales, donde ya comenzaban a aparecer estos conceptos, y después de eso se han ido sucediendo alguna que otra lectura, conversaciones con gente como Jorge Fernández, y (y esto es lo que más me ha llamado la atención) una pregunta hecha por cada vez más clientes y alumnos cuando hablamos de metodologías "rollo ITIL, y tal": ¿Y esto cómo cuadra con las Metodologías Ágiles?

Así que quizás comienza a llegar la hora en que estudiemos, experimentemos y probemos, para poder dar una respuesta a la gran pregunta en algún momento.

Para ayudarnos a todos aquellos que queramos entrar en este mundo, y a los que ya estén ayudarlos a seguir cada vez mejor, acaba de nacer la comunidad Scrum Manager, en palabras textuales, 

Comunidad profesional para la gestión flexible de proyectos y organizaciones TIC

O, como dicen en Navegapolis al respecto del lanzamiento,

Para estar al día en gestión de proyectos ágil, evitando costosos o exclusivos "seminarios de formación": una comunidad en la que los profesionales son miembros, no por el pago de una cuota, sino por la participación y por compartir su experiencia.

2 de abril de 2008

¿Preparado para el V3 Foundations?

Durante las últimas semanas/meses ha habido bastante ruido en el mercado de las certificaciones sobre ITIL V3, pero parece que las aguas vuelven a su cauce natural. Hasta hace poco, sólo estaba disponible el examen de ITIL V3 Bridge, que es válido sólo para aquellos que ya disponían de una certificación ITIL V2 Foundations, pero recientemente se ha finalizado la preparación del examen V3 Foundations y Exin ya ha publicado los contenidos en su sitio web.

Este examen, de tipo test de 40 preguntas, tiene una duración de 60 minutos y para aprobarlo tendrás que superar un 65% de las preguntas (26 concretamente), pero lamentablemente aún no está disponible en castellano.

Las entidades examinadoras, Prometric y Pearson VUE ya están aceptando peticiones de exámenes y aunque en el website de Exin indica que la fecha prevista para el inicio de estos exámenes es el próximo 10 de Abril, Pearson informa en su website que estará comenzando los exámenes el próximo 3 de Abril (mañana mismo!)

¿Estás listo?

¿Has asistido a un curso de formación de Fundamentos ITIL V3? ¿Te ha parecido suficiente, o quizás es demasiada materia para poco tiempo?

ACTUALIZACION 09-Abril-08

El amigo IT Skeptic ha publicado 8 fuentes para obtener preguntas o exámenes de ejemplo para el ITIL V3 Foundations. Las puedes encontrar aqui:

http://www.itskeptic.org/node/542