Ofensiva ChaRM

Con la versión 7.2 del s, SAP también está cambiando algunas cosas en la Gestión de Solicitudes de Cambio, especialmente en la vinculación de las Solicitudes de Cambio con la documentación.

Este siempre ha sido un punto delicado cuando he hablado con clientes sobre la gestión del cambio y también sobre la gestión de la documentación asociada.

La introducción de ChaRM tiene sentido, pero también debe estar bien planificada. Es imposible lanzarlo como un submarino, por así decirlo, en SAP Basis y luego dejarlo salir a la superficie en algún momento.

Dado que la gestión del cambio abarca todas las disciplinas, desde la aplicación hasta la puesta en marcha a través de un flujo de trabajo, naturalmente también intervienen diversas áreas de TI hasta el departamento especializado.

El primer paso comienza con un objetivo esencial. En primer lugar, ¿por qué quiere un departamento de TI introducir la gestión de solicitudes de cambio?

¿Cuáles son los objetivos asociados? En los últimos años he visto toda una serie de objetivos. Desde evitar la discontinuidad de los medios hasta la cuestión de los requisitos normativos, muchos objetivos son legítimos.

Sin embargo, es importante contar con esta especificación, idealmente combinada con guardarraíles, porque en un debate posterior sobre procesos y procedimientos, siempre se puede tener en cuenta en qué medida las distintas variantes contribuyen al objetivo.

Las implantaciones de ChaRM que se limitan a sustituir una herramienta existente -aunque sea Excel en un recurso compartido de Windows- suelen estar condenadas al fracaso. Con una implantación de ChaRM, también hay que analizar los procedimientos existentes.

Por eso es importante desarrollar un concepto para los procesos. En mi opinión, los llamados prototipos ChaRM, que luego se utilizan en un entorno de sistemas productivo una vez realizada la personalización básica, no son muy eficaces, ya que suelen prescindir de los procesos y la documentación.

La aplicación sólo tiene sentido una vez que se ha establecido el concepto. Para la creación del concepto deben tenerse en cuenta y detallarse, en particular, los siguientes puntos:

• ¿Qué procesos de modificación existen actualmente para las modificaciones de SAP?
• ¿Cómo debe documentarse un cambio de software en el futuro?
• ¿Cómo son los paisajes objetivo?
• ¿Cómo se gestiona el bloqueo de objetos entre sistemas?
• ¿Cómo se describen los requisitos y quién los aprueba y planifica?
• ¿Se desea la gestión de versiones?

Así que hay muchos puntos abiertos que, desde luego, no pueden aclararse en un taller. Más bien requieren un animado debate, incluso dentro de TI.

Como los procesos informáticos no pueden definirse en democracia de base, la dirección informática tiene que definirlos. El asunto que más me ha sorprendido en los últimos meses ha sido el de un cliente que quería implantar un proceso de cambio general, pero quería trazar un flujo de trabajo especial para dos usuarios clave. Tiene sentido cortar exactamente este tipo de trenzas.

Las autorizaciones son un tema muy querido. Por desgracia, un cliente sin un flujo de trabajo ChaRM suele limitarse a documentar sus requisitos y cambios de forma muy rudimentaria.

Sin embargo, son precisamente estos clientes los que se preocupan en ChaRM de que cada usuario clave pueda leer también las solicitudes de cambio del departamento vecino. Aunque es posible establecer amplias estructuras de autorización para ello en Solution Manager, habría que considerar detenidamente si realmente merece la pena el esfuerzo administrativo.

No es difícil establecer que sólo pueda tramitar el cambio el informático al que está asignado. Sin embargo, siempre me pregunto cómo quiere actuar el cliente cuando precisamente este empleado está enfermo.

Dado que el tema de la documentación también está estrechamente relacionado con ChaRM, este aspecto también debe aclararse. Aquí es relevante definir plantillas y también exigirlas en los respectivos flujos de trabajo para una solicitud de cambio o una modificación.

En resumen, un concepto y una hoja de ruta son lo más importante para una introducción con éxito. La implementación técnica es -como suele ocurrir en el ámbito de las herramientas del ciclo de vida de las aplicaciones- el factor que menos esfuerzo requiere.

No hay que descuidar los cambios organizativos, que a menudo son la garantía del éxito de la introducción.