Me escribe Jordi y me pide mi opinión sobre estándares de gestión de TI como ITIL. Bueno, realmente fue hace ya unos días, pero estaba un poco "atascado". Aprovechando los comentarios de Fernando y Luis en el post de los salarios , creo que es buen momento para retomar ese post pendiente.
Antes, voy a comentar un ejemplo reciente ligeramente relacionado con estándares. Una compañía del grupo contrato un desarrollo a una pequeña consultora. El proyecto se ha desarrollado en varias fases, con versiones y modificaciones (lo normal). Bueno, pues cuando hemos empezado a hacernos cargo de la aplicación vemos que el mismo concepto se utiliza en unas tablas/pantallas como numérico o como texto, los campos de valores SI/NO a veces son lógicos, otras numéricos de 0/1 y otras texto (S/N) y las fechas pueden ser campos tipo DATE o textos DDMMAAAA o DD/MM/AAAA. Caótico.
He estado 8 años en una consultora grande. Claro que creo en los estándares. Es la única manera de gestionar cuando tienes que tratar con grandes números (sean PCs, desarrolladores, proyectos o usuarios): si gestionas 15.000 PCs (o 300), no es manejable tener 15.000 configuraciones diferentes. Pero el equipo que da salida a los camiones en el almacén tampoco puede ser idéntico al del equipo de comunicación externa o a los de control de gestión.
Pero también soy el responsable de "Calidad" en mi compañía. Calidad en "sentido ISO". Y he visto como las auditorias de AENOR caen en auténticas aberraciones para garantizar el cumplimiento de los estándares.
Mi posición es que es necesario establecer estándares de gestión, sean ITIL u otros. Pero hay que evitar el fundamentalismo en la aplicación de los mismos. Que un concepto se defina como Gestión del Incidente o Gestión de incidencias me parece irrelevante, que olvidemos, como dice Antonio , que la métrica es un medio y no un fin, me parece gravísimo. Pero seguramente, cambiando ligeramente los nombres, se podría aplicar a un departamento financiero o de RRHH.
Hace muchos años un gerente me decía que "los sistemas tienen que ser reductores de la complejidad". En cierto modo son, por definición, estándares de como trabajar. Pues creo que el departamento TIC también necesita unas normas o procedimientos (sean ITIL o no), pero más importante es tener a las personas adecuadas para dirigirlos y aplicarlos. Como dice Antonio España y sus "momentos de la verdad ": "una atención excelente destaca precisamente cuando nos saltamos las normas".

13 ago 2007 | 05:37 PM
Al final se reduce a planificar vs. improvisar. Trabajar planificando cómo se van a hacer las cosas es mejor que ir improvisando sobre la marcha.
Una metodología es un plan que dice cómo se debe trabajar. ITIL, el PMBoK o SCOR no son más que una colección de mejores prácticas que te pueden ayudar a desarrollar una metodología de trabajo.
Como indicas, no se debe ser fundamentalista, ya que por un lado, no todas las posibles circunstancias han sido contempladas en la metodología y por otro (en algunas actividades más que en otras) el trabajo requiere la aplicación de experiencia, conocimientos y habilidades de forma creativa.
Me permito incluir un enlace a algunos artículos que he escrito sobre el tema:
http://www.scribd.com/people/view/69313-lucas-rodriguez-cervera
13 ago 2007 | 06:27 PM
Ya que en tu post mencionas un comentario mio sobre ITIL, me daré por aludido :). Mi interés por ITIL nació de un descontento con la forma de trabajo en diversas organizaciones por las que he pasado: se trabaja sin orden ni concierto o, dicho más finamente, de una forma ad hoc. Ojo, que no digo que se trabaje mal, si no más bien con una falta de método en los diversos procesos que componen el negocio o en planificación para hacer desarrollos.
Así pues, por cuenta propia estudié ITIL para conocer como ayudaba el empleo de este disciplina (no creo que esta palabra sea la más adecuada para traducir framework, pero la falta de oxígeno y glucosa en mi cerebro a día de hoy debido a unas intempestivas vacaciones impide el encontrar un término más adecuado en castellano) a estructurar los procesos de un departamento de informática y como se podía beneficiar el negocio de esto. Y la verdad, resultó que me gustó el modelo, principalmente por la flexibilidad que da. De hecho uno de sus principios es "adopta y adapta", es decir, coge ITIL como referencia y haz con ella lo que te apetezca. De hecho, y retomando el tema de las métricas, ITIL no establece unas determinadas, te da la libertad de escoger. Y eso, me parece uno de los aspectos más positivos, ya que toda metodología o disciplina estricta y rígida está abocada al fracaso pues o muy poca gente las seguirá o no se emplerá en su totalidad y se modificará. Asumiendo esto, ITIL elige ser flexible.
No puedo pasar por alto que ITIL es algo que conozco a nivel teórico, nunca he trabajado en una organización estructurada de esta forma, con lo cual no puedo decir que sea la panacea para el departamento de las TIC. Pero creo que, como bien dices, no se debe ser fundamentalista. Hay que coger las ideas buenas de allí de donde vengan. O dicho de otra forma, se puede ser del PSOE y aceptar buenas ideas del PP, aunque la realidad de la política española sea otra a no ser que el pleno del ayuntamiento trate del sueldo de los concejales y alcaldes. Y esto es lo que me proporcionó ITIL: algunas ideas muy buenas y otras regulares que tendré en cuenta y sopesaré llegada la ocasión.
Por otro lado, resulta que al final, lo quieras o no, algo de ITIL vas terminar usando. Y si no, preguntáselo a mi jefe actual. Resulta que la regulación de compras electrónicas, a la cual tenemos que adherirnos ahora, pues el grupo donde trabajo adquirió una empresa dedicada a ello, contempla que tengamos que autorizar y registrar las peticiones de cambio para el cortafuegos. No me extiendo en los detalles de este proyecto pero, vamos, que el bueno de mi jefe, con la de años que lleva intentando eludir cualquier metodología, y ahora tenemos que implementar a pequeña escala algo similar al "change management" de ITIL. Cuanto menos curioso.
De todas formas, he de reconoce mi ignorancia en lo tocante a otras metodologías que se empleen para la parte de operaciones de las TIC y no me es posible realizar una comparación. Me gustaría aprender COBIT, pero todo se andará, de momento prefiero ahondar más en ITIL.
Y volviendo al tema de las buenas ideas, Rafa, gracias por tu blog que es una buena fuente de donde quitar buenas ideas :). Como siempre deseo que este comentario contribuya con ideas positivas a todos aquellos que lo lean.
4 sep 2007 | 11:02 AM
Hola a todos y en primer lugar, gracias Rafa por el post "dedicado" ;-)
Estoy de acuerdo contigo en que el fundamentalismo nunca es positivo. ITIL es un conjunto de mejores prácticas generales que te invita a utilizar las que se ajusten más a las necesidades en cada caso, pero no hay que olvidar que las que en realidad serán las mejores prácticas serán aquellas que realmente cubran bien todas las necesidades de una compañia en particular. Rollo receta de cocina, donde el mejor cocinero será aquel que sepa adaptar mejor la receta "estándar" al gusto de los comensales en cada momento.
Por otro lado y en la mayoria de los casos, simplemente consiste en aplicar la lógica. Hay compañías que les podrá ir bien durante un tiempo con la metodología ASM (a salto de mata), pero ¿durante cuanto tiempo podrán trabajar sin problemas graves?, ¿y con que nivel de riesgo? Creo que estamos de acuerdo en que las metodologías y estándares son la mejor forma de ahorrarse riesgos innecesarios.
5 sep 2007 | 11:32 PM
Me apunto lo de la metodología ASM.
14 dic 2008 | 12:44 PM
Muy bueno el artículo y las aportaciones de todos vosotros.
Como veo (y me enorgullece ;-) ) que ha salido el tema de la metodología ASM, os paso un link para quien le interese saber más en detalle y de sus próximas versiones... ;-)
http://metodologiaasm.blogspot.com
Un saludo ;-)
P.D: estamos recopilando información para ilustrar y estandarizar esta metodología, se aceptan sugerencias.