COMPLIANCE: ”Lo esencial es invisible a los ojos...”
Quizás sea algo pretencioso el título del artículo,
pero en verdad, es lo que me surgió cuando pensé en desarrollar el texto,
veamos cómo llegamos al final del documento...
En la actualidad, nos encontramos ante un escenario muy
complejo, que tiene miles de aristas de análisis cuando consideramos una
solución de base tecnológica. De hecho, una misma persona puede resolver una
problemática de distintas maneras, con distintas estrategias, brindar las
mismas soluciones ante problemas similares, pero que muchas de las cuestiones
que interactúan en este, entiendo que merecen un desarrollo particular y
especifico.
Si consideramos una solución tecnológica,
cualquiera sea esta, vamos a ajustar a los requerimientos de nuestro
solicitante… (eso está bien?), en primera instancia podemos asegurar que sí,
dado que si le brindamos algo que no resuelva su problema, estamos en
problemas, entonces OK (1).
Otro aspecto a considerar es tener en cuenta
cual es la posibilidad de resolverlo con lo que tenemos (aunque una idea en background es que las TICs más eficaces
no administran la pobreza…), con lo cual podemos inferir que la solución deberá
contar con una organización/infraestructura que aporte su parte ($$$) para que
nuestra solución, nuestro esfuerzo, no tenga inconvenientes en los distintos estadios
que debe pasar…, y aunque cada vez menos, pero que cumpla con el proverbio que
esgrimen muchos clientes que dice que
“presionando un botón, sale todo…”, Entonces nuevamente OK(2).
Entre otros aspectos que vamos a evaluar, es
crear un micromundo en el cual nuestros desarrolladores y administradores de
bases de datos, experimenten la sensación de contar con una infraestructura de
procesamiento que le dispensa una ilimitada memoria, un espacio almacenamiento
inagotable y de asignación performante, donde pasen desapercibidas la totalidad
de falencias que puedan tener el venerado código. Superando este pequeña
prueba, otra vez OK(3).
Bien…ahora cuando pensamos que estamos en
condiciones de suponer que hemos superado todas esas pruebas, nuestro
requirente nos plantea que planea/ha convenido operar con otras empresas, que
debe intercambiar información, pero que para hacer dicho intercambio necesita
un esquema que proteja los datos desde su generación, transformación,
almacenamiento, y resguardos aplicando Normas de Seguridad de la Información.
Este esquema define perfiles, accesos, que le permita tener la confianza
suficiente para que su negocio no corra riesgos…es el momento en que aparece
otro viejo lema, que reza que “la solución más confiable, es la que no tiene
usuarios…” mmmmmm…!!!. Creo que estamos en un momento de –OK(4).
Ustedes se preguntarán que tiene que ver el
termino COMPLIANCE… con todo lo que venimos escribiendo (yo también me lo
cuestiono…), entonces los invito a que realicemos en conjunto un segundo nivel
de análisis considerando el término. De acuerdo a la publicación de
worldcomplianceassociation.com, estamos haciendo referencia a procedimientos y
buenas prácticas adoptados por Organizaciones para identificar y clasificar los
riesgos operativos y legales, y establecer mecanismos internos de prevención,
gestión, control y reacción frente a contingencias.
Estos se encuentran compendiados en voluminosos escritos que en muchos
casos con de cumplimiento obligatorio en determinados mercados, otros (también
escritos) desarrollan conceptos
elementales y genéricos, a los cuales
algunas organizaciones puede o no adherirse, donde en ese universo, algunos de
ellos, “garantizan” que de su aplicación se alcanzará una completa
gobernabilidad de la solución informática. En otro ámbito, el escenario se
completa con otros que aseguran que proveen un esquema de control por
“objetivos de negocios”, otros por buenas prácticas para generar el mejor
código…(¿?¡¡), pero ya tenemos la solución…¡¡¡.
Entonces, se hace presente entre nosotros una
enorme sombra que se dirige a nuestro lugar de trabajo, y nos invade el cerebro,
provoca escalofríos un temblor que nos hace llegar hasta las lágrimas, cuando
empezamos a darnos cuenta que en la mano derecha, tenemos la documentación de
nuestra solución tecnológica y en nuestra mano izquierda (pero también apoyada
en una mesa con patas reforzadas…) tenemos la colección completa de los
distintos COMPLIANCE que el mercado
nos exige, el requirente considera necesario, los controlers respaldan sus
informes, los security Officers aseguran su fortaleza, cuando en
realidad, estamos tratando de hacer combinar un circulo con un triángulo y
pretender que no existan espacios sin cubrir uno dentro del otro.
Porque puede considerarse esto resulta muy
claro, porque no existen topologías que sean absolutamente iguales que permitan
construir una planimetría exacta de acuerdo a un patrón común(standard), sino que este patrón se
expresa en instancias, circunstancias, servicios y/o funcionalidades que no son
repetibles. Resulta imposible encontrar dos infraestructuras iguales.
Una de las primeras consecuencias que podemos
determinar al estructurar una solución tecnológica desde un estándar/compliance es una diferencia temporal
que se genera entre la actualización de los documentos/escritos con la dinámica
de los cambios en la tecnología(en cada una de sus ramas) con lo cual es la
carrera de la liebre y la tortuga… o mejor dicho, el coyote y el correcaminos…
lo que me parece más adecuado dado que sin proveer los conceptos relevantes, plantean
soluciones que conllevan una serie de expuestos que muchas veces por decisiones
de estrategia empresarial y otras tantas, por las limitaciones propias de la
plataforma tecnológica.
Tal como citara al principio del documento, el
ingreso a una solución de base tecnológica no es para una improvisación,
“haciendo como que hacemos” la solución o para condicionar/limitar el soporte
económico que permita una adecuada puesta en producción la totalidad de los
recursos instalados.
En este punto, se hace imprescindible la
generación de “knowledge-bridges”, cuyo principal función será la
de establecer los puntos de encuentro entre lo requerido y lo funcionalmente
posible, con el objetivo de reducir a su mínima expresión los baches generados
entre la desactualización de los recursos documentales y las
capacidades/limitaciones de los recursos de tecnología. Acá es donde el
profesional, debe volcar (sin condicionamiento de ninguna naturaleza) su
conocimiento, experiencia y capacidad en forma ética. Existen miles (o
cientos…) modelos/guías de gestión, control, gobernabilidad de TI, y demás
sabores, pero nada va a poder contra la
importancia del saber…(en su conjunción de realizar, entender, operar,
estructurar y articula con otros conocimientos), de otra manera, solo seriamos
quienes supimos dar como respuesta adecuada, en un momento histórico oportuno,
en que nos preguntaron aquello que podíamos recitar casi sin razonarlo, un
contenido memorizado.
Entiendo que debo estar olvidándome de una
serie de cuestiones que también son importantes al momento de definir, evaluar,
considerar, implementar, controlar y gobernar un esquema de información, pero
que quizás en otro momento volvamos sobre el particular.
Hablamos de conocimiento, experiencia y capacidad, sumado a la ética con el
objetivo fundamental de hacer lo mejor posible con lo que se tiene (en
particular, si debemos restringirnos a un estándar o un “compliance”), es el valor agregado que cada uno de quienes nos
especializamos en alguno de los tantos tópicos en que se divide la tecnología, ponemos
en los trabajos, cualquiera sea la actividad que nos solicitan. ¡Donde estos
últimos elementos, fundamentalmente, y confirmamos que LO ESENCIAL ES
INVISIBLE A LOS OJOS…!!! Pero que por esa misma condición, nadie tiene la
capacidad y derecho a condicionar…
Ya hablaremos de Auditoria de TI, riesgos,
entre otros temas que son tan representativos y éticamente propios…
No hay comentarios.