Procesos y procesos

A menudo me suele pasar que termino enfrascado en "discusiones" filosóficas sobre el sexo de los ángeles. Una de las habituales suele ser sobre qué es un proceso, y aunque parezca algo sencillo, os puedo asegurar que la discusión da mucho de sí.

El problema, en realidad, no está en la definición del concepto. Creo que referencias ya señaladas, como esta, aclaran bastante bien el término y sus implicaciones. A priori son conceptos sencillos de entender y fáciles de diseñar. Y sin embargo, son conceptos difíciles de acotar a la hora de hablar de ellos de forma genérica.

El problema de definir adecuadamente un proceso, desde mi punto de vista, es su dimensionamiento. Todos hablamos de macroprocesos, sistemas de procesos, procesos "a secas" y subprocesos utilizando el término genérico "proceso". Y aunque este abanico de términos sí que se puede usar para dar una idea del "tamaño" de los procesos a los que se refiere, nada nos asegura que su interlocutor los esté dimensionando de la misma forma, ya que no hay "tamaños de proceso" de referencia.

Creo que un ejemplo puede servir para ilustrar el problema. Es muy habitual que, en el mapa de procesos de muchas organizaciones, haya uno denominado "gestión de sistemas de información" (o similar). Recoge, en definitiva, las actividades de "los informáticos" de la empresa. Pero resulta que, si pensamos en ITIL, por ejemplo, tenemos definidos 10 procesos a desarrollar dentro del que ya teníamos. 11 si contamos con el de gestión de la seguridad en los términos de ITIL. Pero resulta que la gestión de la seguridad también puede ser un proceso de "gran tamaño" si pensamos en una organización con un SGSI implantado cuyo alcance sea toda la compañía...

Este problema, ya sea de terminología o conceptual, se puede agravar si pensamos en la estructura de procesos de algunas organizaciones. Porque muchas de ellas tienen implementada una "gestión por procesos" concebida como una ISO 9001 "avanzada" (una especie de ISO 9001 + ISO 9004 parcial). El problema es que, en muchos casos, la "evolución" de la ISO 9001 ha sido sencillamente adaptar a "formato proceso" los procedimientos ya desarrollados, e integrarlos de la mejor forma posible en el mapa de procesos. Con lo cual es fácil encontrarse con un mapa de procesos en el que aparecen procesos del tipo "gestión de las compras" con otros del tipo de "proceso de ajuste del grosor de la lámina", que no hacen otra cosa que agravar esta falta de criterio a la hora de dimensionar los procesos.

Si ahora pensamos en implantar un sistema de gestión (de calidad, de seguridad de la información, o cualquier otro) cuyo alcance se define "por procesos", podemos encontrarnos con que el problema ya no es sólo de terminología. ¿Es lo mismo establecer un SGSI, por ejemplo, para el proceso de "gestión de sistemas de información" que para el subproceso ITIL de "gestión de cambios"? Parece evidente que no. Y yendo un poco más allá: ¿Tiene sentido pensar en establecer un SGSI para el "proceso de ajuste del grosor de la lámina", que consiste en que un operario ajuste una tuerca hasta que el grosor de la lámina sea 'X'? A priori, y teniendo en cuenta que en los tres casos podemos estar hablando de un alcance "de un único proceso", todas las opciones podrían parecer similares. Y está claro que no lo son...

La solución creo que debería pasar por estandarizar (o formalizar, al menos) una terminología que permita determinar el "tamaño" de los procesos. No tengo claro si el término "proceso de negocio" podría servir para definir los procesos de "primer nivel" del mapa de procesos, o si quizás pueda llevar a confusión con otras clasificaciones de procesos (operativos/estratégicos/de soporte). Lo que sí me parece imprescindible es conseguir llegar a una terminología común para todos los que trabajamos con este tipo de conceptos. No sea que nos terminemos encontrando con clientes que quieran establecer sistemas de gestión "completos" (certificables) para procesos del tipo del "proceso de ajuste del grosor de la lámina", o con empresas que les quieran vender esa posibilidad...

Avances LOPD

Parece que el nuevo reglamento para la LOPD sigue su avance (lento, muy lento, pero avance al fin y al cabo). Aunque desde hace más de tres meses no había habido nuevas noticias al respecto, parece que la tramitación sigue su avance. Si hace unos días Martín Pérez anunciaba en su blog que el ministerio de justicia había enviado el borrador del nuevo reglamento a ASIMELEC para que desde esta organización lo valorasen, el pasado viernes fue la Asociación de Internautas quien publicó sus comentarios en relación a dicho documento. De estos comentarios quiero quedarme con dos detalles, que me parecen de particular relevancia:

• El nuevo reglamento debería dejar claro (comentario -c)-) el tratamiento que se ha de dar a la información recabada desde Internet. Probablemente sea la fuente de información más utilizada a día de hoy, y si no es así es seguro que lo será en un breve lapso de tiempo. Por lo tanto, me parece totalmente imprescindible que el nuevo reglamento regule el trato que se debe dar a estos datos, que hasta la fecha tantos quebraderos de cabeza dan a algunas organizaciones a la hora de pensar en tratar datos recogidos de estas fuentes.
• La conclusión que hace la Asociación de Internautas me parece fundamental. No tenemos que olvidar que la LOPD es una ley difícil de interpretar en algunos apartados, y por lo tanto el reglamento no debería ser únicamente una referencia para su aplicación práctica, sino también un lugar en el que se aclaren, acoten y delimiten, al menos, las principales indefiniciones contempladas en la ley, con el fin de disponer de un marco legislativo más completo que el actual. Ahora que ya llevamos unos años lidiando con el anterior reglamento, creo que un documento que complemente adecuadamente a la Ley también debería servir para no tener que depender tanto de las resoluciones de la AEPD a la hora de depurar la aplicación de la ley.

Espero que no sólo la Asociación de Internautas nos obsequie con la publicación de sus comentarios respecto al borrador del nuevo reglamento. Así será más fácil para todos ir viendo los derroteros de este esperado (temido?) documento.

Más que una moda

La seguridad informática es algo más que una moda pasajera. Empezó por ser una preocupación de organismos relacionados con la "seguridad" civil, de ahí pasó a las grandes multinacionales, posteriormente a las regulaciones y leyes nacionales de los países, y de ahí de nuevo a las empresas, aunque en este caso alcanzando a todo el tejido empresarial. Una evolución clásica, e incluso lógica, diría yo. Difundiéndose desde los sectores más "paranoicos" de la sociedad y en todas direcciones, a través de los entramados económicos y políticos de la sociedad moderna.

Sin embargo, el motivo de esta difusión no es símplemente económico o político. De fondo está motivada por la necesidad de que la seguridad informática se vaya extendiendo progresivamente, porque la inseguridad informática avanza a grandes pasos (y aquí sí que pueden ser más visibles los intereses políticos y económicos, tal y como nos recuerdan los expertos). Algo de esa necesidad hay en la última decisión de la Comisión Europea, que ve con preocupación el continuo crecimiento de los delitos informáticos. Un crecimiento que, sin conocer las propuestas que se presenten a final de año, tengo muchas dudas de que se consiga paliar de forma efectiva con este tipo de medidas. Y el motivo es sencillo: creo que hasta el momento ningún gobierno ni institución ha sabido encontrar una solución que permita que medidas como las que se puedan asociar a la seguridad informática den el último salto: de las empresas a las personas. Este punto, en el que confluyen la vía política y la económica, es la clave para conseguir que cualquier tipo de medida de seguridad informática sea realmente efectiva, y sin embargo es el punto al que en muy pocas ocasiones se consigue llegar.

Cuando intento explicar a algún profano en la materia de qué trata esto de la seguridad informática, siempre le pido que piense en una gran ciudad. Tiene su zona de negocios, su calle con boutiques de última moda, su casco histórico, sus colegios... Pero también tiene sus barrios de chabolas, sus parques mal iluminados, sus bandas callejeras o su barrio rojo. Y todo el mundo tiene muy claro qué se puede encontrar en cada zona, a qué horas no es aconsejable pasear o con qué tipo de gente no se quiere juntar. El problema es que en Internet los barrios de chabolas son tan elegantes como la zona de negocios, no hay zonas mal iluminadas y todo el mundo tiene el mismo aspecto. Y además en esta ciudad "está de moda" ir de "chico malo", y ser de los que "trapichean" con SW o de los que tienen su PC "tuneado" con los widgets más exclusivos.

En resumen, creo que nuestros instintos no nos sirven en Internet, y por eso la mayor parte de la sociedad está tan expuesta a los riesgos de esta "ciudad". Porque la evolución no nos ha preparado para un mundo virtual, y suplir nuestros instintos con formación y concienciación "digital" es una tarea enormemente compleja y prácticamente inabordable. Por eso creo que la seguridad informática debe ser algo más que una moda, que tenemos que ser capaces de superar y olvidar los distintos intereses que han convertido este tema en un negocio, para centrarnos en su verdadera esencia, que tiene que ser conseguir que la sociedad actual alcance el nivel de conocimiento necesario como para poder desenvolverse por esta "ciudad" de forma autosuficiente. Sabremos dar el último salto, y llevar la seguridad informática a todos los PCs particulares, y a todos sus usuarios? El tiempo lo dirá.

Referencias

Últimamente he recopilado y refrescado varias referencias de distinto tipo que creo que podrían ser interesantes para todos los lectores del blog, y como corro el riesgo de que se me vayan olvidando o extraviando, prefiero dejar constancia de ellas en este momento.

Las primeras tienen que ver con el control interno. En concreto son dos modelos de control interno inspirados en COSO, y que probablemente algunos ya conozcan. El primero es el modelo ECAR, un modelo de control interno y gestión de riesgos complementario a COSO, y el segundo es el modelo estándar de control interno (MECI) colombiano, vigente por decreto en las entidades del estado de ese país y perfecta referencia para complementar al modelo anterior.

El segundo grupo de referencias tienen que ver con la redacción de políticas de seguridad. En concreto, y para complementar un post anterior en el que Samuel Linares ya nos dejaba una buena referencia, creo que tanto en esta web argentina como en esta otra se pueden encontrar buenos ejemplos de políticas de seguridad. Y si no, las series del Centro Criptológico Nacional siempre constituyen una fuente de indudable calidad.

Y la última referencia que quiero dejar es este modelo de sistema integrado de calidad desarrollado por Telefónica. Muy buena referencia para todo aquél que tenga ya un alto grado de madurez en su gestión de la calidad y esté pensando en optimizarlo en base a una referencia integrada de metodologías, normas y técnicas. Ojo, sólo para empresas "realmente maduras" en temas de calidad, si es que se quieren obtener resultados útiles.

Espero que las referencia sean de interés, y sirvan para todos los interesados puedan profundizar en alguno de estos temas. Y como mínimo, como es mi caso , seguro que sirve para tener un repositorio localizado de referencias accesible desde cualquier lugar...

Más que políticas

Muchas veces, cuando nos ponemos a escribir políticas, se nos olvidan los motivos por los que se redactan. En resumen, una política es, básicamente, una serie de normas dictadas por la organización que regulan un ámbito concreto de la misma (por ejemplo, una política de seguridad para el uso del correo electrónico regularía el uso permitido para el correo electrónico, en aras de garantizar unos niveles mínimos de seguridad durante dicha actividad). Sin embargo, muchas organizaciones se quedan, a la hora de redactarlas, en eso: describir las normas aplicables para un determinado ámbito.

Yo creo que las políticas deben llegar más allá. Sobre todo, una buena política debería indicar las causas y motivos que justifican o llevan a dictar esa determinada norma. Y los motivos son múltiples:

• El personal no es el hijo pequeño al que se le dice "eso no se come". Si no queremos que lo coma, le tendremos que explicar que es perjudicial para su salud porque contiene dioxinas. Y el argumento tendrá que ser convincente, si queremos una razonable probabilidad de que se cumpla.
• Una determinada norma puede estar justificada en un momento determinado y perder su sentido en un futuro. Y si no está argumentada, corremos el peligro de establecer dogmas que no podrán ser contradichos, puesto que la justificación se ha perdido. O es preferible que pase como con los monos y los plátanos?
• Las políticas deben tener espíritu formativo, no sólo informativo. Si están bien redactadas, las políticas de la organización servirán no sólo como núcleo de los programas de formación interna sino como referencia permanente, oficial y actualizada de los contenidos formativos aplicables.
• La difusión de los motivos es más eficiente si están en la propia política. Es preferible dedicar algo más de tiempo a escribir una buena política, con todas las justificaciones y motivos que sea necesario, a tener que ir aclarándolo uno por uno a todo el personal. Y de ese modo las normas y sus justificaciones aparecen asociadas en todo momento.
• Las justificaciones no sólo se revisan y actualizan, sino que se establecen formal y oficialmente, a salvo de explicaciones incompletas o incorrectas (aunque no nos libre de que se puedan entender de forma incorrecta).

Probablemente se puedan añadir más justificaciones a esta pequeña lista, pero creo que con estas es suficiente como para ilustrar el comentario. Más vale sentarse con tiempo y calma a redactar unas buenas políticas, que indiquen tanto las normas como los motivos y justificaciones que llevan a tomar dichas decisiones, que lamentar los problemas que pueda causar un mal entendimiento de los mismos, o la oposición a su cumplimiento por falta de argumentos. Hagamos nuestra propia reflexión a tiempo...

Gestión sin burocracia

Algo que suele preocupar bastante a muchas organizaciones es cómo conseguir implementar una metodología de gestión eficiente, que cumpla su cometido pero sin caer en la burocracia. Y no es algo sencillo, sobre todo si pensamos en entornos reducidos, donde prácticamente todo el mundo hace de todo. En estos entornos, es probable que esos extensos procedimientos vendidos al peso por algunas consultoras no sean de mucha ayuda, si es que alguien se plantea usarlos realmente...

Hoy quiero plantear una solución sencilla y útil, asequible para casi todas las organizaciones independientemente del tamaño que tengan, y que permite cumplir con los requisitos mínimos de cualquier gestión normalizada que se nos pueda ocurrir. Incluso en términos de auditoría, creo.

En resumen, los requisitos de gestión que exige cualquier norma son básicamente los mismos: que exista trazabilidad de las decisiones y que se tomen y ejecuten de la forma correcta. Básicamente, que se cumpla para cualquier actividad el siguiente ciclo: propuesta, análisis, validación, ejecución, verificación y cierre. Pasos que, además, se pueden agrupar de cara al registro:

• Propuesta: Alguien propone algo (innovaciones, quejas, sugerencias, notificaciones de incidencias, solicitudes de cambio, ...).
• Validación: Alguien tiene que validar (o rechazar) la propuesta, indicando los motivos (es decir, el análisis realizado de dicha propuesta). Si es un rechazo, la validación se corresponde con el cierre.
• Ejecución: Quizás no se considere imprescindible, pero yo creo que es necesario algún tipo de registro sobre CÓMO se ha realizado la propuesta.
• Verificación: Alguien debe dar el visto bueno de la ejecución realizada, y dicho visto bueno también se puede considerar como cierre.

Para articular estos pasos, necesitamos definir el alguien y el algo. Vamos allá:

• Alguien: Cualquier persona dentro del grupo tiene capacidad para realizar las propuestas. Pero las validaciones y las verificaciones se las vamos a dejar al jefe (en entornos pequeños, normalmente suele ser el único cargo que está bastante claro). Y la ejecución... a quien indique el jefe.
• Algo: Este algo, como ya he comentado, puede ser cualquier tipo de propuesta. Pero las vamos a clasificar, por ejemplo, en las siguientes: Sugerencias, Normas, Cambios, Incidencias, No Conformidades (si alguien prefiere llamarlas quejas, también se puede).

Y ahora, metemos estos ingredientes en una coctelera, añadimos un poco de blogger, agitamos... y ya tenemos nuestra herramienta de "gestión sin burocracia". Tachan!!

Y ahora, me explico. Es muy fácil: lo primero que tenemos que hacer es abrir un blog (en blogger, por ejemplo), generar un usuario por cada persona del grupo, y definir el blog como privado. Así, sólo los usuarios de nuestra empresa tendremos acceso al mismo, pero no tendremos que mantener el sistema. Además, tendremos acceso al blog desde cualquier lugar con acceso a Internet, y los viajes dejarán de ser un problema porque el que tiene que dar las validaciones no vuelve hasta no se sabe cuándo. Eso sí, el requisito es la conexión a Internet. Si no, la solución no sirve. :-(

A continuación, tenemos que crear categorías. Una por cada tipo de "algo". Así, cada vez que alguien postee un comentario, lo asociará a la tipología de "actividad de gestión" correspondiente.

Después, nos tendremos que aprender la secuencia Propuesta-Validación-Ejecución-Verificación. Y todas las entradas llevarán una de las cuatro palabras al principio, e irán seguidas del "algo" en cuestión. De ese modo, si lo que queremos es "comprar un PC", podremos localizarlas visualmente y saber que si figura la entrada "Propuesta comprar un PC" tendremos que esperar hasta que el jefe confirme (o deniegue) la solicitud mediante "Validación comprar un PC".

Y por último, tendremos que acostumbrarnos a postear, durante los últimos 5 minutos de cada jornada, todas aquellas gestiones que hayamos realizado durante el día, si es que deben figurar en la "herramienta de gestión sin burocracia".

Sencillo, no? Seguro que los auditores tienen comentarios acerca de si sistemas de este tipo son válidos o no de cara a una certificación. Y probablemente los no auditores tengan comentarios acerca de la viabilidad, utilidad o comodidad de esta propuesta. Así que si alguien está interesado en hacer comentarios al respecto, ya sabe dónde puede realizarlos...