La problemática del presupuesto discrecional
Su respuesta está en la estructura de control
El presupuesto discrecional es una tierra de nadie que puede provocar enfrentamientos entre los equipos de TI y las unidades de negocio. Entre los grandes proyectos estratégicos y el soporte diario de un presupuesto de TI, se encuentra el apartado discrecional. El punto medio de algo suele ser un lugar seguro, pero no en un presupuesto de TI. Este aspecto financia las peticiones de negocio que ocurren durante el año: elaboración de informes o el cambio del diseño de las interfaces. Aunque el punto medio es un lugar donde las TI tienen una oportunidad de mejorar su reputación.
En muchas empresas, la consolidación de la plantilla de TI en grupos más pequeños y centralizados ha conseguido hacer grandes logros con el trabajo discrecional. Las unidades de negocio que ya no tengan grupos dedicados a las TI deberán competir por el tiempo del personal técnico para desarrollar sus proyectos discrecionales. El personal de TI necesita atender estas peticiones al mismo tiempo que implementa proyectos estratégicos y ofrece soporte a las aplicaciones actuales. La consecuencia suele ser el abandono a medida que se retrasan sus previsiones y peticiones de implementación, de forma que las unidades de negocio se sienten ahogadas e ignoradas. De esta forma, los departamentos de TI reclaman un control popular o estructura de control para dar salida a proyectos de TI concretos, pequeños y desfasados del resto, al mismo tiempo que ayuda a identificar e implementar los importantes.
Las peticiones de trabajo discrecional aparecen en cualquier momento y evolucionan a través de una serie de reuniones difíciles y poco eficaces (llamadas telefónicas y correos electrónicos). No hay un proceso ni un criterio para juzgar las necesidades, y los clientes consideran de manera hostil cada intento de rechazar o reducir la prioridad de una petición. Gracias al control popular, se pueden consolidar todas las peticiones y solicitar cualquier petición que todavía no hubiera sido enviada. Después se elimina casi un tercio de las mismas porque eran redundantes, obsoletas o irrelevantes.
Por otra parte, las unidades de negocio recuerdan no muy positivamente, los intentos de categorizar e implementar proyectos tecnológicos, en parte porque confian excesivamente en comunicaciones entre la cúpula directiva. Esta vez, con una estructura de control definida, los comunicados se dirigen directamente a aquellos que solicitan los servicios (mandos intermedios y la plantilla de las unidades de negocio). Así mismo, una estructura de control detalla la necesidad de tiempo, dinero y personal, y aseguran que todos los proyectos encajan con las prioridades de la empresa. Para conseguir la información de todas las unidades de negocio, se necesita implementar un nuevo proceso que requiere un formulario estándar para todas las peticiones.
Para ello, se diseña un formulario básico que contenga la información necesaria para valorar objetivamente cada petición (después se migra a un sistema on line). El formulario pide al solicitante que explique de qué forma el proyecto puede incrementar los beneficios, reducir costes, respetar las normas o simplificar la realización del trabajo. En ese momento, varios son los beneficios que obtienen como son crear una plantilla para proponer trabajos, eliminando su confusión y frustración por no saber cómo se deben presentar sus peticiones, un ahorro de tiempo a ambas partes eliminando las reuniones y correos electrónicos normalmente necesarios para definir pequeños trabajos y, finalmente, conocer que el departamento de TI ha recibido y está considerando su petición, eliminando la necesidad de seguir concertando reuniones para asegurarse de que sus proyectos siguen en marcha.
Desarrollo del formulario
La utilización de un sólo formulario obliga al cliente a definir el problema en lugar de indicar una solución. Para ello, se han creado siete categorías generales, denominadas Programas TI, y se designan administradores de proyectos como personas de contacto para cada uno de ellos. Estas categorías son finanzas, que incluye áreas como presupuestos, y los servicios asociados, que abarca los recursos humanos, nóminas y el plan de existencias de la empresa. Esta estructura permite recibir y procesar trabajo de forma uniforme y sin crear una burocracia fragmentada.
Cada administrador de proyectos domina su categoría y es responsable de recibir y administrar las peticiones de trabajo, así como de realizar una reunión mensual con el equipo implicado. Durante las reuniones, los administradores y los técnicos de TI revisarán los proyectos, analizarán los proyectos y considerarán los factores principales de cada uno, tanto desde la perspectiva del negocio como del equipo de TI: plazos internos, cambios normativos, disponibilidad de recursos y fondos o cualquier otro. Se propondrán presupuestos y planes de desarrollo técnico para justificar la decisión de implementar o rechazar la petición. En la mayoría de los casos, este equipo decidirá la prioridad de cada petición, buscando la ayuda de sus superiores sólo en las pocas ocasiones en las que sea realmente necesario. Cada semana, se realiza una revisión de la lista de proyectos donde los miembros del personal asignado actualizan los formularios on line y el sistema le asigna un estado de “presentado”.
A medida que la petición avanza por el sistema, su estado cambia automáticamente hasta que alcanza el estado de “completado” o “rechazado”. El resultado es conseguir que logros, que antes hubieran quedado ocultos, se hagan visibles tanto para la dirección de TI como para la empresa. Son una prueba fehaciente ante la dirección de la empresa de que la mejora tanto de las relaciones con las unidades de negocio como de la percepción del valor de las TI. Además, ayudan a justificar el tiempo necesario para desarrollar el sistema y a subir la moral del equipo de TI.
Plantilla de un formulario
-----------------------------------
Cabecera Sirve como título, un resumen de una sola línea del trabajo solicitado. Por ejemplo, “añadir segundo apellido al nombre de un comprador”. Aunque el sistema automático asigna un número a la petición de trabajo, este campo se convierte en el nombre común y se usa en los informes. Aconseje que escriban primero la descripción antes de que escriban la cabecera ya que encontrarán el título dentro de la descripción.
Producto Una clasificación genérica del área en el que ocurre el trabajo. Esto ya existía para los productos que vendíamos, por lo que creamos la categoría genérica “INTSYS” para nuestros sistemas internos.
Aplicación Subconjunto de la categoría de producto, es el área específica que necesita el trabajo. Podría ser Contabilidad o Finanzas. Nuestros sistemas internos se controlan a través de una unidad denominada Centro de Competencias, por lo que creamos “CNTRCOMP” para todas las aplicaciones internas.
Componente Un subconjunto más detallado de categorías para nuestros sistemas internos. Por ejemplo, los trabajos para nuestro sistema SAP podrían clasificarse como “SAP CF” (cuentas a favor) o “SAP NOMINAS”.
Solicitante La persona que realiza la petición.
Descripción Lo que quiere que se realice.“Arréglenlo” no es una descripción suficientemente específica, por lo que nosotro
En muchas empresas, la consolidación de la plantilla de TI en grupos más pequeños y centralizados ha conseguido hacer grandes logros con el trabajo discrecional. Las unidades de negocio que ya no tengan grupos dedicados a las TI deberán competir por el tiempo del personal técnico para desarrollar sus proyectos discrecionales. El personal de TI necesita atender estas peticiones al mismo tiempo que implementa proyectos estratégicos y ofrece soporte a las aplicaciones actuales. La consecuencia suele ser el abandono a medida que se retrasan sus previsiones y peticiones de implementación, de forma que las unidades de negocio se sienten ahogadas e ignoradas. De esta forma, los departamentos de TI reclaman un control popular o estructura de control para dar salida a proyectos de TI concretos, pequeños y desfasados del resto, al mismo tiempo que ayuda a identificar e implementar los importantes.
Las peticiones de trabajo discrecional aparecen en cualquier momento y evolucionan a través de una serie de reuniones difíciles y poco eficaces (llamadas telefónicas y correos electrónicos). No hay un proceso ni un criterio para juzgar las necesidades, y los clientes consideran de manera hostil cada intento de rechazar o reducir la prioridad de una petición. Gracias al control popular, se pueden consolidar todas las peticiones y solicitar cualquier petición que todavía no hubiera sido enviada. Después se elimina casi un tercio de las mismas porque eran redundantes, obsoletas o irrelevantes.
Por otra parte, las unidades de negocio recuerdan no muy positivamente, los intentos de categorizar e implementar proyectos tecnológicos, en parte porque confian excesivamente en comunicaciones entre la cúpula directiva. Esta vez, con una estructura de control definida, los comunicados se dirigen directamente a aquellos que solicitan los servicios (mandos intermedios y la plantilla de las unidades de negocio). Así mismo, una estructura de control detalla la necesidad de tiempo, dinero y personal, y aseguran que todos los proyectos encajan con las prioridades de la empresa. Para conseguir la información de todas las unidades de negocio, se necesita implementar un nuevo proceso que requiere un formulario estándar para todas las peticiones.
Para ello, se diseña un formulario básico que contenga la información necesaria para valorar objetivamente cada petición (después se migra a un sistema on line). El formulario pide al solicitante que explique de qué forma el proyecto puede incrementar los beneficios, reducir costes, respetar las normas o simplificar la realización del trabajo. En ese momento, varios son los beneficios que obtienen como son crear una plantilla para proponer trabajos, eliminando su confusión y frustración por no saber cómo se deben presentar sus peticiones, un ahorro de tiempo a ambas partes eliminando las reuniones y correos electrónicos normalmente necesarios para definir pequeños trabajos y, finalmente, conocer que el departamento de TI ha recibido y está considerando su petición, eliminando la necesidad de seguir concertando reuniones para asegurarse de que sus proyectos siguen en marcha.
Desarrollo del formulario
La utilización de un sólo formulario obliga al cliente a definir el problema en lugar de indicar una solución. Para ello, se han creado siete categorías generales, denominadas Programas TI, y se designan administradores de proyectos como personas de contacto para cada uno de ellos. Estas categorías son finanzas, que incluye áreas como presupuestos, y los servicios asociados, que abarca los recursos humanos, nóminas y el plan de existencias de la empresa. Esta estructura permite recibir y procesar trabajo de forma uniforme y sin crear una burocracia fragmentada.
Cada administrador de proyectos domina su categoría y es responsable de recibir y administrar las peticiones de trabajo, así como de realizar una reunión mensual con el equipo implicado. Durante las reuniones, los administradores y los técnicos de TI revisarán los proyectos, analizarán los proyectos y considerarán los factores principales de cada uno, tanto desde la perspectiva del negocio como del equipo de TI: plazos internos, cambios normativos, disponibilidad de recursos y fondos o cualquier otro. Se propondrán presupuestos y planes de desarrollo técnico para justificar la decisión de implementar o rechazar la petición. En la mayoría de los casos, este equipo decidirá la prioridad de cada petición, buscando la ayuda de sus superiores sólo en las pocas ocasiones en las que sea realmente necesario. Cada semana, se realiza una revisión de la lista de proyectos donde los miembros del personal asignado actualizan los formularios on line y el sistema le asigna un estado de “presentado”.
A medida que la petición avanza por el sistema, su estado cambia automáticamente hasta que alcanza el estado de “completado” o “rechazado”. El resultado es conseguir que logros, que antes hubieran quedado ocultos, se hagan visibles tanto para la dirección de TI como para la empresa. Son una prueba fehaciente ante la dirección de la empresa de que la mejora tanto de las relaciones con las unidades de negocio como de la percepción del valor de las TI. Además, ayudan a justificar el tiempo necesario para desarrollar el sistema y a subir la moral del equipo de TI.
Plantilla de un formulario
-----------------------------------
Cabecera Sirve como título, un resumen de una sola línea del trabajo solicitado. Por ejemplo, “añadir segundo apellido al nombre de un comprador”. Aunque el sistema automático asigna un número a la petición de trabajo, este campo se convierte en el nombre común y se usa en los informes. Aconseje que escriban primero la descripción antes de que escriban la cabecera ya que encontrarán el título dentro de la descripción.
Producto Una clasificación genérica del área en el que ocurre el trabajo. Esto ya existía para los productos que vendíamos, por lo que creamos la categoría genérica “INTSYS” para nuestros sistemas internos.
Aplicación Subconjunto de la categoría de producto, es el área específica que necesita el trabajo. Podría ser Contabilidad o Finanzas. Nuestros sistemas internos se controlan a través de una unidad denominada Centro de Competencias, por lo que creamos “CNTRCOMP” para todas las aplicaciones internas.
Componente Un subconjunto más detallado de categorías para nuestros sistemas internos. Por ejemplo, los trabajos para nuestro sistema SAP podrían clasificarse como “SAP CF” (cuentas a favor) o “SAP NOMINAS”.
Solicitante La persona que realiza la petición.
Descripción Lo que quiere que se realice.“Arréglenlo” no es una descripción suficientemente específica, por lo que nosotro
