The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

La importancia de transmitir el conocimiento / The importance of transferring knowledge

La importancia de transmitir el conocimiento

A estas alturas empieza a ser difícil encontrarse con una organización que no quiera invertir tiempo y esfuerzo en la seguridad. Aunque queda camino por recorrer, poco a poco la madurez en la seguridad está evolucionando desde el “si no falla ni nos han entrado, no pasa nada” al “debemos controlar el riesgo“, de modo que ha habido una migración en los últimos años en cuanto al foco de la seguridad. Ésta ya no se centra sólo en la disponibilidad de los servicios, sino también en la integridad de los mismos; las diferentes normativas que se han elaborado en estos años, como la LOPD o el Esquema Nacional de Seguridad ha ayudado mucho a que la seguridad esté cada vez mas presente en todas las organizaciones. Conceptos como “correlación”, “IPS”, “consola de gestión” o “monitorización” son cada día más conocidos y ya no suenan a jerga especializada.

Sin embargo, a pesar de esta mejora la seguridad sigue siendo vista no como un aspecto que debe envolver todos los demás, según una perspectiva holística, sino como otro elemento más en nuestra infraestructura de red (el firewall, un router, la VPN) o como una auditoría que nos revela fallos que solventamos. Es decir, como un elemento o acción puntual y aislada que nos permite incrementar nuestra seguridad o a veces tan sólo la percepción de seguridad. Existen varios efectos colaterales de esta manera “compartimentada” de abordar la seguridad, que les indico a continuación:

  • Los beneficios del proyecto no se trasladan de manera efectiva a la organización, sino que se limitan a aquel departamento que ha promovido la iniciativa. No resulta nada raro que una organización decida abordar una auditoría 27002 pero el resultado efectivo sea la mejora de aquella parte de la seguridad de la que el departamento promotor es responsable, generalmente IT, por una simple cuestión de autoridad y competencias.
  • Las implantaciones de nuevos sistemas, productos o elementos se quedan “cojas”, introduciendo incluso nuevos problemas de seguridad; un concentrador VPN es mucho más que un elemento de red que nos permite acceder remotamente a la organización: requiere procedimientos de alta y baja de usuarios, revisión periódica de usuarios, actualizaciones, políticas de utilización acceso remoto (y teletrabajo si es una de sus funciones), etc.
  • El propio enfoque de la seguridad, unido a que se trata en muchos casos de iniciativas o proyectos “departamentales” e incluso en ocasiones casi personales, hace que no sea nada raro que el conocimiento y la experiencia que se deriva de estas iniciativas quede “atrapado” en el personal implicado en el proyecto. De este modo, no se incorporan al know-how de la organización, y se limita su utilización en posteriores iniciativas.

Aunque los tres efectos indicados son igualmente perniciosos, me gustaría incidir un poco más en el último. Si las lecciones aprendidas quedan dentro de las “cabezas pensantes” del personal de comunicaciones, el personal de sistemas, o tan sólo el responsable de IT, y no se traducen en documentos y acciones formales o incluso informales, no se tarda mucho en convertirse en departamentos reactivos, incapaces de responder de forma coordinada y sobre todo, anticipada y preventiva. Por utilizar una expresión que seguro que muchos conocen, el resultado es que nos limitamos a apagar fuegos. Claro que más de uno pensará: ¿Cómo demonios me voy a poner a pensar en detectores de humo cuando tengo una habitación llena de fuego? Pues haciendo que los cambios en la manera de trabajar se introduzcan de forma gradual, poco a poco. Es fantasioso pretender que elaborar procedimientos, documentación o introducir algo de necesaria burocracia en el día a día no vaya a afectar a nuestra manera de trabajar, tanto en la carga de trabajo que implica su elaboración e implantación, como en el rechazo que mostramos ante cualquier cambio de rutina, aunque su consecuencia sea positivo.

La cuestión, al final, radica en garantizar que el aprendizaje diario permanezca en la organización y no en la cabeza de esta o aquella persona, ya sea a través de procedimientos formales o informales, que permitan cumplir con la legalidad, retener el conocimiento, y que deben ser aplicables en el día a día de la organización. Esto en ocasiones puede entrar en conflicto con una mala concepción de la “imprescindibilidad” que algunas personas tienen, pero sólo de esta manera seremos capaces de transmitir el conocimiento de las personas a la organización, evitando caer en pequeñas parcelas de conocimiento y de poder, que sólo obstaculizan el normal funcionamiento de la empresa.

(Entrada elaborada en colaboración con Manuel Benet)

The importance of transferring knowledge

At this point begins to be hard to find an organization that wants to invest time and effort on security. Although it remains to be done gradually in the safety maturity is evolving from the “if it fails or we have entered, nothing happens” to “we must control the risk,” so there has been a migration in recent years with regard to security focus. This is no longer focused only on the availability of services, but also on their integrity, the various rules that have been developed in recent years, as the Data Protection Act or the National Insurance Scheme has really helped that security is increasingly present in all organizations. Concepts such as “correlation”, “IPS”, “management console” or “monitoring” are becoming more known and no longer sound like jargon.

However, despite this improved security is still seen not as an issue that must involve all the others, according to a holistic perspective, but as another element in our network infrastructure (firewall, router, VPN) or as an audit reveals bugs solved. That is, as an isolated or specific action that allows us to increase our security or sometimes only the perception of safety. There are several side effects like this “compartmentalized” to address security, which are indicated below:

* The project benefits are not transferred effectively to the organization, but merely a department that has promoted the initiative. Not at all uncommon for an organization decides to address an audit 27002 but the actual result is the improvement of that part of the security that the department is responsible developer, IT generally, by a simple question of authority and competence.
* The implementations of new systems, products or elements are “lame”, even introducing new security, a VPN concentrator is much more than a network element that allows remote access to the organization, procedures required for high and low users, periodic review of users, updates, use remote access policies (and telework if one of its functions, etc.).
* The very approach to security, plus the fact that it is in many cases, initiatives or projects “department” and even at times almost personal, does not make it not strange that the knowledge and experience derived from these initiatives is ” trapped “in the personnel involved in the project. Thus, not incorporated into the know-how of the organization, and limits their use in subsequent initiatives.

Although all three are equally pernicious effects indicated, I would like to emphasize a little more in the past. If lessons are learned in the “talking heads” of the communications staff, systems staff, or just the head of IT, and do not translate documents and formal or informal actions, does not take long to become reagents departments unable to respond in a coordinated and above all, early and preventive care. To use an expression I’m sure many know, the result is that we just put out fires. Clear that more than one think: How the hell I’m going to start thinking in smoke detectors when I have a room full of fire? For making the changes in the way of working are introduced gradually, little by little. It is beguiling to be developed procedures, documentation and introduce some necessary bureaucracy in the day to day will not affect the way we work, both in the workload involved in its development and implementation, as in the refusal to show to any change of routine, although its impact is positive.

The question, ultimately, is to ensure that the daily learning remain in the organization and not the head of this or that person, whether through formal or informal procedures that enable compliance with the law, retain knowledge and should be applicable on the day to day organization. This can sometimes conflict with a misconception of the “indispensability” that some people have, but only in this way will we be able to impart knowledge of the people to the organization, avoiding patches of knowledge and power, only impede the normal operation of the company.

(Entry created in collaboration with Manuel Benet)

Comments are closed.