antonidavia 19 abril, 2020

Una de las mayores dificultades para un IT Manager en un nuevo puesto es re-definir la forma en la que los diferentes departamentos hacen llegar sus necesidades e ideas hacia el departamento de IT. Definir un flujo transparente, en el que las ideas se concreten en iniciativas, estan sean aprobadas en coste y plazos por la Dirección, y se establezcan métodos de seguimiento para el reporting y control del desarrollo de los planes.

En muchas ocasiones, el descuido de esta función clave esta en el centro de la pérdida de credibilidad del departamento de IT frente a la organización, lo que tiene consecuencias muy negativas para esta área y le dificulta mucho su actuación posterior. Si esto ha sucedido, restablecer el proceso debe ser una prioridad.

Y como hacerlo? Hay grandes empresas que se pueden permitir el disponer de departamentos enteros dentro de IT dedicados a esta tarea, con profesionales especialistas, los famosos IT Business Partners. Si no el caso , los que trabajamos en empresas de tamaño medio, necesitamos métodos sencillos, que no requieran una gran inversión en herramientas y personal.

Por donde empezar? Definiendo el léxico, los conceptos para que la organización entienda lo que queremos decir dentro de este proceso:

  • Portfolio de servicios – es la base para estructurar el proceso. En otro post hablo de esto. La definición del alcance de cada servicio es lo que permite identificar interlocutores para cada sistema, lo que es imprescindible para ordenar la gestión.
  • Usuario de referencia – es la persona de la organización que será el referente para la gestión de todos los aspectos de un sistema de información. Es aconsejable que no sea un directivo, ya que la función requiere conocimiento en detalle de los procesos y herramientas, así como dedicación.
  • Necesidad o idea – cualquier usuario, en el desarrollo de su actividad, puede identificar algo que o bien no funciona en el diseño de un sistema, o bien un cambio que haría mejorar su funcionamiento. En la organización se generan decenas, centenares de ideas constantemente, y la correcta canalización de las mismas es clave para conseguir que los usuarios no entren en el pensamiento de que nadie atiende sus necesidades, y que IT no escucha al negocio, Más adelante explicamos la propuesta para ello.
  • Iniciativa – la idea llega al usuario de referencia, quien discierne sobre aquello que realmente puede ser interesante o posible, entendiendo como el cambio en el sistema impacta en el proceso de negocio. La iniciativa debe plasmarse en un formato adecuado para hacerse llegar a IT, de forma que se fije de forma clara la propuesta de cambio en el sistema y pueda hacerse la valoración de tiempo y esfuerzo.
  • Comité de gestión de la demanda – debe existir un comité, con representación de las áreas de negocio, que realice la aprobación de las iniciativas que se seleccionen, con una priorización y atendiendo a las posibilidades de carga de trabajo y presupuesto.
  • Evolutivo – aquellos cambios que no requieran mucha inversión, y con impacto menor, se consideran una evolución del sistema. Estos mini-proyectos tienen una forma de gestión diferenciada, con una metodologia más sencilla. La forma de tratar los evolutivos es normalmente con metodologías Scrum, donde se acuerdan con el proveedor los plazos para las entregas en periodos determinados de los evolutivos. El backlog de tareas puede ser similar para todos ellos, con una fase de diseño, de desarrollo, pruebas y puesta en explotación, lo que hace que se pueda gestionar de forma ordenada sin un gran esfuerzo. La definición de estas fases y su esfuerzo estimado es clave para controlar los costes de desarrollo, que siempre tienden a descontrolarse en este ámbito de los evolutivos si no se va con estas precauciones.
  • Proyecto – cuando un cambio implica la instalación de nuevas infraestructuras, la compra de nuevo software, o muchas horas de programación, pasaremos a gestionarlo como un proyecto, que lleva otro ritmo y método. No entraré aquí en este tema, ya que daria para muchísimo y no es el objetivo.

Con estas definiciones, una posible propuesta es la siguiente:

En este modelo, las claves son:

  • La figura del usuario de referencia como intermediario entre la organización e IT. Es importante que la persona escogida se postule ante los usuarios como la persona de referencia, que lidere el desarrollo del sistema y actúe como un autentico product owner
  • Hacer visible que IT no prioriza los proyectos, sino que el Comité de la demanda representa los criterios de negocio a la hora de decidir que se hace y en que orden, Es necesario que se perciba que en caso de haber algo que debe ser prioritario, es la dirección de la compañía la que debe actuar y priorizar, no IT
  • Introducir la cultura de los requerimientos claros y la concreción en la organización a la hora de realizar peticiones a IT. Hacer comprender a los usuarios que sin entender con precisión que se necesita es imposible hacer proyectos.

Espero que este post os ayude en clarificar algunos conceptos que seguro que aplicáis, pero que a veces cuesta sintetizar para compartirlos con la organización. Suerte con vuestros clientes internos!

Deja un comentario.

Tu dirección de correo electrónico no será visible. Los campos obligatorios están marcados con *