Luego de leer o asistir a tanto curso sobre mejores prácticas, marcos de referencia y/o cuerpos de conocimiento, la primera sensación que le queda a uno cuando se lee este tipo de información es un vacío enorme entre el qué y el cómo.
En los últimos años hemos estado literalmente bombardeados con la disponibilidad de teorías, prácticas, cuerpos de conocimiento, marcos de referencia, casos, normas, y demás información que pretende darnos acercarnos a toda esta teoría con el objetivo o bien que tomemos un curso y accedamos a una certificación, o que seamos suscriptores de sus portales.
La primera sensación que le queda a uno cuando se lee este tipo de información es un vacío enorme entre el qué y el cómo. Por lo general, estos documentos buscan ayudarnos a estructurar un qué, pero aportan muy poco en el cómo, no es su propósito. Sin embargo, lo que por lo general buscamos es un como, una receta, una lista de doce pasos, que podamos seguir para resolver una problemática o aprovechar una teoría administrativa.
En perspectiva, es importante hacer una diferenciación entre los tres tipos de documentos, y qué se pretende con cada uno.
Un Framework o Marco de Referencia (traducción libre) o Marco de Trabajo (traducción literal) es un conjunto de conceptos, prácticas y criterios expresados en forma estandarizada, para enfocar un tipo de problemática en particular y sirve como referencia para resolver nueva problemática de índole similar.
Un Body of Knowledge (BoK), o cuerpo de conocimiento (traducción libre) es un término que se utiliza para representar un juego completo de conceptos, términos y actividades que conforman un dominio profesional. Es la ontología (conceptos y la relación entre pares de conceptos) aceptada para un tema específico. Estos cuerpos de conocimiento son generados por asociaciones profesionales que generan su reconocimiento a través de certificaciones y fuertes campañas de mercadeo para sus certificados.
Por su parte, las “mejores prácticas” o “buenas prácticas” son un conjunto de acciones que por experiencia, han dado un buen o excelente resultado en un contexto, y se espera que si se aplican en contextos similares, los resultados también sean excelentes. Estas buenas prácticas dependen del autor de las mismas, de quien tuvo la experiencia, o hasta de una particular empresa de consultoría.
Las Normas, como su nombre lo dice, son el compendio de reglas, disposiciones y requisitos para normalizar un proceso. Una norma entonces es como una fórmula que tiene valor de regla, y tiene por finalidad definir las características que debe poseer un objeto y/o un servicio de tal manera que garantice calidad, repetitividad, y mejoramiento.
El marco de referencia de Zachman para la definición de Arquitectura Empresarial, o CobiT para la estructuración del tema de Gobierno Corporativo de TI son claros ejemplos del QUE. Son precisamente eso, una forma de explicar, en el primero, que debe constituir una arquitectura empresarial, y en el segundo, un conjunto de procesos que sugieren se deben desarrollar en las empresas para generar valor con la tecnología informática.
El PMBok (tal vez el más conocido) es el cuerpo de conocimiento sobre gestión de proyectos propuesto por el PMI, el Project Management Institute, y reúne eso, el conocimiento incorporado en diez áreas, precisamente llamadas de conocimiento, que se deben tener en cuenta para la gestión de proyectos. Pero no es el único. Tenemos el BABok (Business Analysis Body of Knowledge) EABok (Enterprise Architecture Body of Knowledge) entre otros muchos. Todos cumpliendo la misma función de compendio de conocimiento.
ITIL por su parte es una “mejor práctica” propuesta por el ITSM y originada en el Reino Unido para facilitar la entrega de servicios de tecnología informática de alta calidad. En este tema, también hay una Norma, la ISO20000, precisamente orientada a especificar los elementos necesarios para brindar calidad en la prestación de servicios de tecnología informática. La diferencia entre los dos entes de certificación, es que el primero certifica personas, el segundo procesos en una compañía.
Debe quedar claro que a través de ninguno de estos cuatro tipos de documentos y/o sus contenidos, encontraremos esa lista de cosas por hacer. Solo están los qué, y algunas pautas de algunos cómo. Es menester entonces de cada empresa que vaya a aplicar uno de estos elementos para la solución de un problema o el mejoramiento de un servicio, conocer todo lo que hay disponible y construir su propia receta!
Si advertimos que utilizar una herramienta para un uso distinto al que fué generada puede ocasionar resultados funestos. Por ejemplo, utilizar las herramientas y artefacctos de la arquitectura empresarial para efectuar una planeación estratégica de TI es un despropósito mayor, en el entendido que la primera busca estructurar la empresa, y la segunda alinear la tecnología. Si bien hay elementos que podrían ser comunes, no son sustitutos!