Gestión holística de TI

El mapeo de los procesos de soporte y TI es sin duda el primer paso para seguir utilizando y posicionando SAP Solution Manager. Una vez introducidos el service desk y la gestión de cambios, el tema de la asignación de costes y servicios adquiere cada vez más importancia.

Esto adquiere importancia a más tardar cuando los responsables de TI tienen que rendir cuentas detalladas o quieren saber ellos mismos en qué sumidero se cuelan los gastos.

Ahora, por supuesto, SolMan también puede utilizarse para medir y presentar los esfuerzos además de los procesos de TI, pero hay algunas cosas que deben tenerse en cuenta aquí. Mi objetivo es siempre evitar posibilidades de interpretación en los informes y evaluaciones. Esta situación se produce a más tardar cuando los datos se introducen de forma redundante en distintas herramientas.

Desde el punto de vista de la gestión de cambios y solicitudes de SolMan, una visión uniforme de los proyectos, así como de los servicios ya prestados, sólo puede lograrse de forma razonable con la gestión de proyectos y carteras.

El componente SAP PPM se introdujo relativamente tarde con SolMan 7.1 y ahora, por supuesto, también está disponible en una variante optimizada en la versión 7.2.

El uso del componente PPM no es tanto una cuestión de personalización como de organización. En general, los proyectos de mayor envergadura no deben asignarse mediante cambios individuales, sino como una versión o un proyecto.

Ya aquí, por supuesto, surge el primer reto: alejarse de un uso universal de los "cambios urgentes", hacia un control de los cambios en los proyectos. Estos proyectos -si se quiere utilizar PPM- no deben crearse directamente.

El uso habitual de las solicitudes de cambio es más bien trabajo adicional para proyectos que, de todos modos, solían ser aprobados por un comité. Tiene sentido crear los proyectos en la gestión de proyectos y carteras y mantener allí la estructura de proyectos.

No basta con crear un paquete de trabajo que luego se denomine simplemente "programación" o "aplicación". Más bien hay que establecer y definir todos los paquetes de trabajo individuales.

En este contexto, los esfuerzos previstos también pueden registrarse al mismo tiempo. Un paquete de trabajo puede dar lugar a un cambio, pero no necesariamente. Este es el caso, a más tardar, cuando también se definen los paquetes de trabajo para el despliegue, como la migración de datos, la asignación de autorizaciones y similares.

La interfaz entre PPM y ChaRM es tan buena que se puede crear un cambio directamente a partir de un paquete de trabajo. Normalmente es el gestor del proyecto quien lo inicia.

La creación de un documento de modificación a partir de un paquete de trabajo en PPM crea un vínculo único entre los dos objetos. Esto permite a los usuarios de TI registrar los esfuerzos en el cambio.

Estos esfuerzos se sincronizan con el paquete de trabajo en el PPM. Si el registro del esfuerzo se lleva a cabo de forma coherente, se pueden crear análisis relevantes para los gestores de proyectos a partir del PPM. Un requisito previo importante para ello es, por supuesto, que no sólo se registren los tiempos, sino que el responsable del paquete de trabajo también mantenga continuamente el grado de realización.

Así, por un lado, el proyecto puede controlarse mediante ratios (esfuerzos frente a servicios, avance del proyecto, paquetes de trabajo abiertos). Paralelamente, los tiempos de imputación de actividades reales también pueden transferirse a la hoja de tiempos multiaplicación (CATS) del sistema ERP.

De este modo, el registro central de las actividades y la estructuración de los paquetes de trabajo dan como resultado un registro claro de los datos, de modo que quedan excluidas las interpretaciones. En resumen, con el PPM para SolMan, SAP pone a su disposición una herramienta muy valiosa que está a la espera de ser puesta en práctica.

Por supuesto, hay que crear los requisitos previos organizativos para el despliegue. Sin embargo, tiene sentido utilizarlo en cualquier caso. Una y otra vez tengo clientes que luego empiezan a almacenar campos específicos del cliente, como el centro de costes y el pedido interno en el Cambio.

Así, aunque los requisitos de información pueden cumplirse parcialmente, con ello no puede llevarse a cabo un control holístico de los proyectos.