Procesos de Cierre: Las Peores Practicas

En este post voy a llevar la contraria al tópico recurrente de “Las mejores prácticas en…”.  

Voy a exponer  lo que hacemos repetidamente de manera incorrecta sin darnos cuenta de eso.     


                                                                                                                                     

¿Que es un proceso de cierre?

                                         

Una vez  finalizados los procesos operativos del  día, las instituciones requieren ejecutar procesos de cierre automatizados para actualizar sus bases de datos con  las  transacciones realizadas durante el periodo diario, mensual o anual que corresponda.

Los procesos de cierre que he revisado a lo largo de mi carrera profesional han sido sumergidos en las siguientes “peores practicas gerenciales” aplicadas en el área de sistemas que se resumen en esta frase:

Nadie entiende verdaderamente lo que sucede allí adentro y lo que es peor: a nadie le importa.

Peores Practicas Gerenciales en la Gestión de los procesos de Cierre

·         El software no tiene documentación ni técnica ni funcional.

     Una pésima práctica que se repite una y otra vez consiste en no exigir a los proveedores de software una documentación técnica y funcional de los procesos desarrollados.

    Algunos proveedores engañan al cliente argumentando que el software esta autodocumentado. Ni los analistas de Organización y métodos ni lo analistas funcionales son involucrados en el proceso de evaluación del software antes de adquirirlo.

    Por otra parte, los desarrolladores de la empresa no están dispuestos ni preparados para dedicar tiempo ni esfuerzo a documentar los desarrollos o los ajustes que realizan.

·         Rotación de recursos sin transferencia de conocimientos.

  

     En un taller mecánico dedicado a la reparación de automóviles, cuando se va quien repara los frenos, se sustituye por otro empleado mecánico que realiza el mismo trabajo que el anterior casi inmediatamente. Sin embargo, en productos donde está implicada la propiedad intelectual, como ocurre en el área de sistemas, es un error aplicar ese mismo concepto de la sustitución inmediata sin transferencia de conocimientos.

    En una institución para la cual trabajé hace algún tiempo, era de carácter obligatorio la planificación de una sesión de transferencia de conocimientos a la cual debía asistir todo el personal de IT, independientemente del lenguaje de programación, del equipo o de la funcionalidad del producto desarrollado.

    Los desarrolladores debían explicar técnica y funcionalmente la aplicación instalada así como sus conexiones con otras aplicaciones y con las áreas funcionales de la institución. Además debía entregarse una documentación detallada que debía ser almacenada en una carpeta compartida de acceso controlado para que  todo producto desarrollado e instalado por el área de sistemas quedase como patrimonio intelectual de la institución. 

     Este caso, a mi entender, ha sido una excepción en mi carrera profesional en el marco del “deber ser” institucional. Esta falta de procedimientos para el área de sistemas tiene múltiples causas que serían tema para otro post. Quien esté interesado en el desarrollo de este tema puede solicitármelo  por el blog y con gusto redactare otro artículo con este punto en particular.      

·         Subestimación de la importancia de un proceso de cierre.

     Los procesos de cierre son importantes cuando fallan, cuando no fallan no son el centro de atención de nadie en la organización. Esto es como el paso de los huracanes: importan cuando suceden o si se presenta un escenario que hace probable que sucedan. De resto, casi nadie revisa los reportes del clima.

·         No hay una división óptima de las funciones del personal y  además hay falta de recursos calificados.

    La dinámica de los procesos diarios y la urgencia por resolver las incidencias que exige la operativa del negocio y a falta de recurso humano disponible para realizar esta tarea de análisis y revisión de los desarrollos de la empresa.

    En mi opinión se necesitan dos grupos de personas en el área de IT. Aquellos que gestionan las soluciones de las incidencias diarias y aquellos que piensan, analizan, revisan y auditan los desarrollos realizados y gestionan los próximos desarrollos. Prácticamente ninguna organización en la que he estado tiene identificadas estas dos funciones.

    Por otra parte hay personas más calificadas para atender incidencias y otras para ocuparse de los procesos de gestión de soluciones de desarrollo importantes a mediano y largo plazo. El ejercicio del pensamiento creativo a veces se confunde con hacer arte, poesía, literatura, etc. Sin embargo, la creatividad es un término mucho más amplio que implica el ejercicio consciente y repetido de las funciones del lado derecho del cerebro. En su libro “El pensamiento Lateral” Edward de Bono expone varios ejercicios prácticos para desarrollar el cerebro derecho. La expansión de estos atributos no se restringe solo al área del arte sino a cualquier disciplina, oficio o tarea.

·         Lemas que hemos practicado culturalmente durante mucho tiempo.

     “Si no está roto no lo arregle”. Esto último se enfrenta a los nuevos conceptos disruptivos presentados en el libro de Robert Kriegel  y Louis Patler titulado: “Si no está roto, rómpalo”. Estos conceptos obsoletos que atentan contra el cambio y la innovación mantienen a las instituciones lejos de la curva de crecimiento puesto que el recurso humano es empleado recurrentemente en resolver los problemas de siempre sin dejar espacio para preparar estrategias operativas alternas de crecimiento a mediano y largo plazo.

    Puedes leer la presentación del libro resumida en slides en este enlace

                   Enlace Slides: Si no esta roto, rompalo

     Peores Prácticas en el desarrollo de los procesos de Cierre.

·         Un diseño de base de datos ineficiente que obliga a realizar distintos programas para acceder continuamente al mismo archivo en momentos diferentes del proceso. Cuando se piensa en el diseño de las funcionalidades del sistema debe incluirse dentro de las funcionalidades consideradas los procesos de cierre e incluirlo como una ENTIDAD de la organización cuyos requerimientos deben ser atendidos con el mismo peso e importancia que cualquier área funcional del negocio.

·         Los parches que se colocan a lo largo de tiempo para no tocar procesos previos y dar una respuesta rápida y no pensar más en el asunto ni incluirlo como punto de atención dentro de las tareas a realizar. Es decir, se queda sin seguimiento y revisión.

·         Incluir la creación forzadas de índices de acceso a lo largo del proceso de cierre. Esta pésima práctica se ha generalizado para evitar el uso de índices de acceso permanente en aras de un mejor tiempo de respuesta global de las aplicaciones. A la larga, a medida que aumenta la data y hay más clientes o productos en la institución, se ocasionan retrasos enormes en el tiempo de ejecución de los procesos críticos ya que los caminos de acceso a la información deben ser creados eliminados y recreados continuamente. 

    El uso indiscriminado de comandos como CRTLF, CRTPF,  y OPNQRYF en procesamiento masivos y cíclico de importantes volúmenes de data son desastrosos  en la programación de  procesos de cierre en CLP y RPG.

·         Incluir comandos propios de mantenimiento del equipo en los procesos de cierre tales como Reorganización de archivos: RGZPFM. Este y otro tipo de comandos deben ser incluidos en tareas cargadas en el SCHEDULER del equipo para que sean ejecutadas en horas nocturnas o fuera del cierre.

·         Ejecutar el cierre interactivo.

    El subsistema Qinter es el favorito de los desarrolladores de cierres en el Iseries, AS400 y afines. Sin embargo, procesos largos que requieren la actualización de  de volúmenes de data importantes o de largas cadenas de procesos, no deben ser programados en función de ser ejecutados en la QINTER. Los subsistemas Batch han sido configurados para acceder a pools de memoria propios del procesamiento masivo de data y están construidos y diseñados de tal manera que ofrecen un mejor rendimiento en este tipo de procesos que los procesos interactivos.

    Ejecutar procesos interactivos de cierre con la ilusión de que van a procesarse más rápido es un gran error: todo lo contrario.

    La ilusión del programador de que allí mismo puede ver el mensaje y tomar acción corresponde simplemente a una ilusión. Las respuestas que puede requerir el proceso para tomar decisiones internas en caso de error pueden ser contestadas en la consola sin problemas.

    Los mensajes de error desde un proceso Batch pueden ser direccionados a la consola del operador quien debe reportar el error ocurrido. Suprimir la consola como medio de monitoreo de mensajes y asignarle esta función a cualquier estación de trabajo interactiva también está equivocado. La consola permite manipular recursos de manera más eficiente a través del panel de control que le es asignado al momento de su configuración.

·         No auto-documentar los procesos de cierre.

    Esto se trata de incorporar en el código fuente del programa comentarios, ayudas, explicaciones observaciones, etc., que cualquiera puede leer, interpretar y comprender.

    En este tópico recuerdo una documentación de un programa fuente que tenía escrito algo como esto: “las siguientes instrucciones son validas hasta el 15 de abril luego deben ponerse en comentario”.

     ¡Qué barbaridad! Las múltiples aplicaciones que no nos imaginamos se le pueden dar al concepto “auto-documentar”. Es decir si el programador encargado se enferma, es despedido, se va de vacaciones, se le olvida o se muere, ¿que sucederá  el 16 de abril?  quien sabe...



                                                                                                                                     

     Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo. 

    Autor: Ing. Liliana Suárez