La importancia de una buena metodología para la implementación de nuevas tecnologías dentro de una organización

1 Introducción 

Todos los días  se van realizando nuevas actualizaciones o upgrades de nuevas tecnologías  distintas organizaciones y que presentan un alto impacto. Abundan los casos de éxito o bien de casos que fallaron. Todas esas eventualidades, exitosas y las no tanto, tienen un factor en común: Procesos.

Las empresas, privadas o públicas, tienen procesos de negocio. Todas, aunque no los tengan documentados, monitoreados ni gestionados. Y de las organizaciones que si tienen gestionado sus procesos, éstas poseen variada madurez dependiendo del ciclo de desarrollo en el que se encuentren.

2 Desarrollo

Para evitar el riesgo de fracasar en la implementación de un software o que el impacto en la organización sea lo menos negativo posible, se debe contemplar una metodología robusta que no deje cabos sueltos ni definiciones pendientes. Esta metodología de implementación debe ser conocida y apoyada por los altos ejecutivos de la organización (Sponsoring) y difundida a todos los usuarios del negocio y participantes del proyecto. Muchas empresas y consultoras tienen sus métodos relativamente alineados y enfocados a darle una visión de procesos a las implantaciones de software de alta complejidad.

Es por eso que:

1.- La metodología debe ser conocida por todos los participantes del proyecto.

2.- La metodología debe ser difundida correctamente a todos los usuarios de negocio y futuros usuarios del nuevo sistema.

Y entonces: ¿por qué la importancia de conocer los procesos de negocio?

Un proceso de negocio bien documentado, bien nutrido, nos debe señalar la secuencia lógica de actividades realizadas por cada ejecutante (personas), nos debe indicar las distintas variables para realizar una misma actividad, los sistemas participantes y puntos claves etc.

Cuando se actualiza o cambia el sistema, el proceso en esencia no debiese cambiar, solamente  modifica la forma o el tratamiento de realizar las actividades. Es por eso que ante la implementación de un software o un upgrade lo que importa es el proceso de negocio antes que el nuevo sistema o tecnología.

Conocer el bosque antes de ver los árboles.

Conocer todos los procesos vinculados desde una mirada global (“Big picture”) y en donde los sistemas actuales o vigentes operan, sirve de pilar para el nuevo sistema pues es ahí donde interactuará. Además servirá para la determinación de Gaps o brechas que son relevantes para la organización y que posiblemente desee mantener aun cuando la nueva solución tecnológica esté trabajando.

¿Cómo conocemos las particularidades del proceso de negocio que se deseen conservar?

Para poder conservar una determinada particularidad del negocio ante un cambio en las tecnologías, debe ser un punto o variable de importancia y que el fundamento justifique dicha consideración en el nuevo proceso nuevo (to be) con el nuevo sistema.

¿Cuáles son las características de los Gaps?

• Estos son considerados como brechas entre lo que se tiene versus a lo que se quiere llegar o a lo nuevo y tienen las siguientes características:
• Particular para un proceso

Contrario a lo anterior, puede repetirse en varios procesos siendo éste un gap de importancia.

Pueden clasificarse (a gusto de la organización) en: Gap de proceso, Gap de sistema, Gap normativo o de política interna, etc.

Un gap de proceso, quiere decir que existe un proceso total o parcialmente completo que no se considera en el nuevo proceso a definir con la nueva tecnología a implementar.  También se consideran aquellas particularidades que se repiten en uno o varios procesos de negocio.

Un gap de sistema, corresponde a toda la información gestionada por uno o varios sistemas antiguos o legados que no se contempla en el nuevo. Esto, de todas maneras, depende mucho si la organización requiere o puede seguir realizando sus actividades sin la información que el sistema legado puede brindar. Esto quiere decir si el nuevo sistema es capaz de brindar reportes o consultas o funcionalidades que sean mejores o iguales a las actuales. Como por ejemplo, tablas de información que son informadas a los clientes como “cartolas” o reportes diarios entregados a los ejecutivos de ventas. Esta información si no es entregada con la nueva tecnología puede implicar una pérdida o fuga del valor total entregado al cliente final.

Un gap normativo o de política interna, señala que el proceso actual está adaptado y considera las particularidades decretadas por una norma legal o bien por una política establecida por la organización. Como por ejemplo, los procesos contables de una empresa x que contemplan la ejecución de la contabilidad IFRS donde aun muchos sistemas o tecnologías aun no están abordando dicho marco.

Según la organización, ellos también pueden ir clasificando los gaps, los cuales dependen de la industria o sector en la que se desenvuelva.

Pero, y ¿cómo obtenemos los gaps?

Los gaps deben provenir del proceso documentado (levantado y modelado) donde se indique en una determinada profundidad las actividades realizadas por cada proceso. Es por eso que es importante realizar previamente un mapeo de los procesos. En otras palabras: dibujar el bosque.

Este bosque o modelo general de proceso, puede verse reflejado en una  cadena de valor (Michael Porter en su obra “Competitive Advantage: Creating and Sustaining Superior Performance”) el cual ordena de forma lógica y secuencial todos los procesos. También pueden ordenarse según el ordenamiento de los procesos E2E (procesos end to end).

Esta visualización, de lo general a lo particular, otorgada por las cadenas de valor conocidas por la organización nos permitirá además priorizar y abordar los procesos que a la empresa le entregue mayor interés.

Teniendo los procesos priorizados, podemos conocer las actividades en detalle. Estas actividades deben tener asociado un responsable, un sistema, fuentes de información, riesgos (si es posible) entre otras características.

Luego de tener modelado los procesos actuales (AS IS), debemos preparar los nuevos procesos donde el sistema participará. En ésta fase, la colaboración de especialistas del negocio, de procesos, TI o informática de la organización y expertos que conozcan el nuevo sistema a implementar es vital. Esta mezcla de participantes, utilizando los procesos como pivote, podrá sacar a luz los procesos futuros o “to be”.

Estos procesos futuros deben ser lo suficientemente descriptivos en cuanto a la interacción con el sistema por parte del usuario y con los flujos de información con la que se trabaja. Es por eso que la importancia de especialistas de Informática y representantes del nuevo sistema es fundamental después del experto en procesos.

Luego, el trabajo para la organización en conjunto con especialistas en procesos es comparar los procesos actuales versus los propuestos. En este trabajo se deben identificar diferencias en cuanto al proceso (procedimiento), flujos de información que alimenta al sistema nuevo, riesgos que se puedan mitigar y los emergentes y principalmente cambios en la información  que el sistema le entrega al usuario/cliente. Este último punto es relevante debido a que el sistema el cual impacta en el proceso no debiese afectar negativamente el valor en el servicio o en los productos que se le entregan al cliente final.

Finalmente obtenemos los gaps!!!

Al visualizar las diferencias entre el proceso actual y el propuesto podemos encontrar los gaps, los cuales deben ser clasificados utilizando, por ejemplo, los tipos indicados anteriormente. Existirán procesos más importantes o críticos que otros. Y se tendrá que realizar seguimiento sobre ellos.

Este seguimiento implica, la difusión y publicación de aquellos gaps a los participantes del proyecto y a los usuarios claves (jefaturas y ejecutivos) pertenecientes del negocio. Pues son ellos quienes tendrán que dictaminar si efectivamente se considerarán dichas diferencias identificadas en el nuevo proceso propuesto.

Los escenarios generales son los siguientes:

• Gap Aceptado: La particularidad actual del proceso de negocio tendrá que llevarse al proceso propuesto afectando al sistema a implementar sea como una “customización” o desarrollos nuevos. Se recomienda seguir los fundamentos de SOA en este punto.
• GAP aceptado con observaciones: la diferencia, como en el punto anterior, fue aceptada pero no en un 100%. En otras palabras los procesos de negocio y la organización tendrán que adaptarse medianamente al proceso propuesto y al sistema venidero.
• Gap rechazado: el proceso propuesto y el sistema a implementar posee la información y es capaz de entregar o mejorar el valor a los productos  o servicios entregados al cliente ya se interno o final.  La organización y el negocio en sí se tendrán que adaptar a la solución TI a implantar.

Las prioridades además pueden ser las siguientes:

• Gap prioritario: el cual es estrictamente necesario para operar y ejecutar los procesos de negocio. Esto quiere decir que el gap es tan importante que si no está resuelto con anticipación el software no podrá iniciar su etapa de “Go live” o salida en vivo.
• Gap necesario: Esta prioridad nos señala que el gap puede aplazarse pero debe ser resuelto en un periodo determinado por la organización. Como por ejemplo, deben ser resueltos el primer mes de ejecución del proceso con la solución TI para cumplir con normativas contables.
• Gap simple: Este gap puede ser resuelto en un periodo mayor al determinado como “gap necesario” y no afecta a que el sistema salga en vivo.

¿Qué hacemos con los gaps aprobados?

Los gaps los cuales tendrán que ser asumidos por la solución TI a implementar y por el proceso propuesto tendrán que ser evaluados y estimados. Probablemente originen “mini-proyectos” que estén paralelos al proyecto principal o bien se estime que se resolverán en el tiempo acordado. Es por eso que el seguimiento de ellos adquiere también importancia pues es parte del producto final entregado por el proveedor de la tecnología nueva a utilizar. Y es realmente fundamental considerar los gaps aprobados, estos pueden convertirse en bolas de nieve y hacer que un proyecto fracase rotundamente ya sea por plazos, presupuestos o mala gestión y acuerdos.

Conclusiones:

Una metodología robusta como ésta es sin duda una gran herramienta para poder realizar proyectos de tecnología de envergadura y que impactan a toda una organización. Muchas empresas para poder controlar los plazos se asesoran con oficinas externas de proyectos PMO y también con asistentes que mantengan la formalidad de la documentación para que todos los acuerdos, la documentación técnica y de procesos cumpla cierto estándar normado por la organización.

Además ésta metodología se contrapone a lo típicamente empleado la identificación de gaps entre el o los sistemas actuales versus el o los sistemas propuestos dejando de lado lo que es realmente lo importante: los procesos de negocio.

La combinación de colaboradores del negocio, de las áreas de tecnología de información, de la empresa proveedora de la solución TI y de los especialistas de procesos permitirán que un proyecto de ésta índole sea éxito cumpliendo los plazos y presupuesto acordados.