Comentarios en: Procedimientos: si los hace, mejor que los haga bien.

Por: Alberto Rivas Sr

Alberto Rivas Sr — Mon, 22 Mar 2010 11:02:37 +0000

Estoy plenamente de acuerdo con el artículo y con vuestros comentarios posteriores y solo deseo añadir que llevo mas de veinte años documentando sistemas y creando procedimientos, y recibiendo por ello las críticas jocosas de compañeros que no consideran necesaria tal documentación, y cuyo pensamiento se transmite fácilmente a los directivos que deciden cuales son los presupuestos y medios necesarios para el área en la que trabajo, incidiendo en forma negativa el considerar que la documentación de sistemas y la creación de procedimientos no aporta valor añadido al resultado fina.
Afortunadamente para eso están las uaditorías y sus resultados suelen ser bastante claros en los requerimientos de documentar sistemas y procedimientos en uso ya que de palabra las auditorias no son válidas, las evidencias hay que presentarlas.
Por último decir que es frecuente encontrarse con procedimientos que fueron escritos tiempo atrás y nunca se revisaron, siendo recomendado por los auditores que se revisen con una periodicidad de no maas de dos años.
La cosa va mejorando pero no mucho, salvo auditorías que empujen.

Un saludo

Por: Francisco Benet

Francisco Benet — Wed, 17 Feb 2010 14:20:18 +0000

Antes que nada, gracias por tu comentario.

En el caso de las incidencias para mi tiene una mención especial y aparte por diversos motivos:

1 – Una incidencia empieza a ser documentada desde que se notifica al equipo de soporte. En este caso siempre se debe disponer de una herramienta, como las que vosotros teneís, para que la labor de documentación sea ya parte de la propia resolución de esta.

2 – Una incidencia debe dar lugar siempre – despues de su resolución – a una reflexion sobre las acciones preventivas y reactivas a la incidencia. Ejemplo: revisar un procedimiento, adecuar un control especifico, implantar un nuevo control para prevenir futuras incidencias…Y es en este punto donde tiene un papel importante la documentación.

Estoy de acuerdo que, mientras ejecuto la resolución de la incidencia o desconozco su solución final, no puedo estar ‘dando a la tecla’ para escribir algo que puedo dejar atrás, pero como en todo siempre existen dos aproximaciones, y en base a esto puedo decir que Vodafone, desde atención al cliente (esta claro que no es lo mismo que una gestión técnica) deja rastro de cada acción en una incidencia de negocio. No conozco el caso de IBM a la perfección, pero alguna vez he visto que su sistema de gestión de ¿incidencias? deja bastante rastro.

Naturalmente de la incidencia al procedimiento hay un paso largo (una puede ser causa y otra consecuencia), pero una relación muy estrecha.

Siempre es necesario encontrar cual es el equilibrio en la gestión en tiempo ‘real’ de los sistemas y las labores de gestión ‘offline’.

Muchas gracias por tu visión y aproximación!!!

Por: Salva

Salva — Wed, 17 Feb 2010 12:24:35 +0000

“Chapeau” por el artículo, que me parece, además de interesante, una referencia a mi trabajo actual tan acertada,que me siento plenamente identificado en el contexto o labor de técnico/documentador.

Obviamente estás hablando de las dificultades que se pueden encontrar a la hora de documentar, y si bien es cierto que es así, debo aportar un punto de vista adicional a lo dicho:

Me voy a referir a las incidencias: aquello que surge por primera vez y provoca tanta inseguridad a tantos usuarios y responsables.

El ansia de documentación que impera en un entorno distribuido -dónde habitualmente se mueven muchas personas realizando labores que DEBEN ser documentadas- es tal que, en momentos concretos, y ante una incidencia de cualquier tipo, los responsables quieren (y deben) saber detalles de los eventos, poco menos que en el preciso instante en que se producen.
Me parece justo, necesario e imprescindible que así sea, pero para el técnico que está resolviendo una incidencia, se genera a su alrededor un entorno estresante, que puede llegar a complicar y retrasar incluso la disponibilidad del entorno afectado. No se puede documentar DURANTE la resolución de un problema, ya que puede salir algo así:
- Sospecho que el problema surge por un fix de sistema operativo aplicado por seguridad…… (pasan horas… mucho estrés…)
- Descargo un nuevo parche XYZ987123 recomendado por el fabricante.
- Muevo el parche por ftp al servidor
- arranco la herramienta de configuracion/instalación de parches
- ejecuto instalacion del arreglo en el sistema que tiene la version 18.33 SP1
- verifico que se activa correctamente
- confirmo el arreglo
- devuelvo el sistema al entorno.

Y prácticamente… (el ejemplo no es el más adecuado, pero lo resume) has ocupado el 75% del tiempo en escribir eso. No es que no se deba hacer, sino que me parece que NO se debería hacer al mismo tiempo que estás usando de tu profundo conocimiento (o desconocimiento) del entorno para solventar un problema que perturba la producción. Creo sinceramente que bastaría con decir tres cosas en tres momentos diferentes:
1.- Se detecta un problema (determinado o no) en tal sistema, procediendo a su investigación.

2.- Se ha encontrado la solucion al problema X y la duración prevista de la no disponibilidad será en torno a n horas/n minutos.

3.- Se ha solucionado la incidencia: Se emitirá en breve un informe/procedimiento sobre el problema encontrado.

Y ya, con el sistema en producción, proceder a documentar. No pienso que sea una tarea dura, excepto si estás informando en tiempo real, por escrito, por teléfono, por telepatía (a algunos les gustaría ver/escuchar en tiempo real lo que estás escribiendo o diciendo), respecto al problema.

No puedo escribir más, porque mi jefe de proyecto me pide que documente lo que estoy investigando (esperando respuesta del fabricante) en relación a una incidencia surgida… y es para ayer.

Saludos.