Gestión de la demanda

La gestión de la demanda es el proceso mediante el cual el área comercial del casino define la prioridad de los desarrollos y evolutivos que se han planteado a Organización y Sistemas.

La priorización de los proyectos se lleva a cabo desde la web http://gestiondemanda.central.cirsa.com/

Esta web, a la que se accede con las credenciales de CIRSA, contiene la hoja de ruta del equipo de desarrollo. La hoja de ruta es un panel con todos los desarrollos y evolutivos que se han solicitado y no se han desestimado. Para cada uno se puede descargar el archivo de definición y se puede ver, por ejemplo, el tiempo que se estima que tomará desarrollarlo.

Determinar el cronograma de desarrollos implica:

• Durante todo el trimestre, redactar requerimientos de desarrollo empleando la plantilla de evolutivos.
• Leer y corregir los que se presentan directamente desde la operación.
• El interlocutor en OyS (en la actualidad, Pablo Gimeno) lo añadirá a Backlog y devolverá el código único con el que se diferencia el desarrollo.

Cuando esté acabando el trimestre, el interlocutor de OyS solicitará que se prioricen los desarrollos para el siguiente Q.  En ese momento se debe descargar el backlog y hacer el siguiente ejercicio: hay que detectar la naturaleza de los requerimientos para definir si se acometen antes o después.

1. Los proyectos más prioritarios son aquellos que obedecen a normativas y leyes. Por ejemplo, si hay una ley en Perú que dice que la ficha de cliente debe tener un registro histórico y que -si no lo cumplimos- nos pueden retirar la licencia, obviamente este proyecto pasa a ser el primero de la lista de futuros desarrollos.
2. A continuación priman los desarrollos que afectan a cliente y que no tienen una solución ahora. Es decir, un desarrollo que beneficia al cliente de una manera en la que no se logra ahora. Por ejemplo, sería un desarrollo de esta índole que el teclado de la máquina incluya un botón que, al ser pulsado, avisa al personal de la sala para ir a atender al cliente (algo que no se puede hacer ahora).
3. En tercer lugar, los desarrollos de reporting que no tienen una solución ahora. Por ejemplo, nuevos KPIs, posibilidades de reporte, flags, etc. En definitiva, mejoras técnicas que mejoran la productividad de los sistemas.
4. A continuación, los desarrollos que afectan a cliente y sí que tienen una solución. En ocasiones, solicitamos desarrollos que benefician al cliente pero esos beneficios ya los están recibiendo. Por ejemplo, pedimos que las tablas de CWC se puedan programar desde PT porque programarlas en CRM hoy en día es complicado. Puesto que la solución ya existe, podemos esperar para mejorarla.
5. Finalmente, los desarrollos de reporting que sí tienen una solución ahora. Si hay reportes que ya podemos hacer de manera tediosa, pero que sí podemos hacer, este requerimiento pasará a la cola. No afecta al cliente (no afecta al ingreso) y solo significa trabajar más.

Cuando haya varios desarrollos en cada epígrafe, deben ordenarse en función de la urgencia que tengan las unidades de negocio en los países. Esto implica dialogar con ellos para consensuar la decisión.

La reordenación se debe llevar a cabo en el propio sistema, tal cual se explica en el siguiente vídeo:

Al finalizar el proceso, se debe informar al responsable de proyectos, quien reunirá entonces al equipo. Juntos,  determinarán qué pueden desarrollar en el próximo Q y qué no.