En esta fase, se define y documenta de forma detallada el alcance del proyecto de implantación, una vez terminadas las reuniones de trabajo. También se genera el Business Blueprint, que es un documento en formato Word con todos los requisitos de la compañía completamente detallados. El equipo de consultores funcionales junto al equipo de negocio han de lograr un entendimiento común sobre cómo la empresa va a llevar a cabo sus procesos de negocio dentro del sistema R/3, a través de las reuniones de trabajo llamadas Business Blueprint Workshops. El siguiente esquema lo muestra perfectamente:
Ilustración 3. Blueprint
Gestión de proyecto
El primer paquete de trabajo dentro de esta fase es la correcta gestión del proyecto. El establecimiento de un ciclo de actividades de proyecto adecuado asegura que la implantación se realice en fechas. La gestión de proyecto incluye toda la planificación del proyecto y el control de las posibles modificaciones. Las principales actividades son:
• Realización de reuniones de seguimiento con el equipo de proyecto (Comité de seguimiento). En estas reuniones cada equipo muestra el estado de avance de su módulo, compartiendo la información entre todos. Deben sacarse todos los ítems que impacten tanto en el presupuesto como en la duración y los recursos. Esta coordinación es muy importante.
• Realización de reuniones de seguimiento con el Comité de dirección.
Toma de decisiones que no pueden llevarse a cabo por el equipo de proyecto: recursos, presupuesto…
No se debe olvidar la formación del equipo del proyecto, que debe reflejar el alcance de la implantación y las necesidades de cada uno de los miembros del equipo. Es importante que todos los miembros del equipo tengan la capacitación adecuada. Llegados a este punto, aparece un paquete de trabajo nuevo: es necesario instalar y configurar correctamente los sistemas de desarrollo y de pruebas/calidad. Los fundamentos de este diseño técnico ya han sido establecidos en la Fase 1 de preparación inicial. Las definiciones de alcance de la implantación son ahora utilizadas para un análisis más detallado del hardware necesario a comprar, sistema operativo qué se va a implantar, base de datos a utilizar, y necesidades de red. También es importante definir estrategias de horizonte, donde se fijarán los pasos a seguir a la hora de realizar upgrades tanto del sistema como del SO y la BBDD. Este diseño técnico ha de ser aprobado y firmado por el comité de dirección al final de esta fase.
Aunque en realidad no es necesario tener configurado el sistema de desarrollo hasta el final de esta fase, es muy conveniente tenerlo preparado con la mayor antelación posible. De este modo, el equipo técnico puede comenzar a trabajar en el sistema antes de programar o adaptar el customizing. ASAP contiene una checklist para verificar la instalación y configuración de R/3. También es necesario en este punto tener definida la política de backup/restore y la conexión con el servicio OSS, para no esperar que ocurran problemas de alcance en medio del arranque.
El Manual de Operaciones para el administrador de sistemas comienza a gestarse aquí. Contendrá la documentación de la instalación del sistema y las políticas y procedimientos de administración, con descripciones detalladas, personas responsables y matrices y procedimientos de escalado para todas las actividades de gestión del sistema. Por ejemplo, a qué teléfono de guardia llamar si se cae la BBDD, quién es el último responsable de esa llamada…
Definición de la estructura organizativa
Un paso importante en la implantación de R/3 es el mapeo de la estructura de la empresa utilizando las unidades organizativas que tiene R/3. La selección y las especificaciones de uso de las unidades organizativas de SAP debe ser llevada a cabo al principio del proyecto, y deben implicarse tanto los diferentes gestores (jefe de proyecto, jefes de equipo…) y los propios usuarios de los diferentes departamentos.
Por lo general, hay varias posibilidades de mapeo para las unidades de organización específicas de una empresa. Se pueden definir escenarios alternativos a fin de comparar y seleccionar el más adecuado. ASAP ofrece la herramienta R/3 Structure Modeler.
Al estar integrada totalmente con ASAP, la herramienta es muy potente para definir la estructura organizativa, ya que emplea gráficamente los mismos conceptos que SAP para la definición de estructuras organizativas, cada una con una forma o color diferente: estructuras de ventas, canales de distribución, grupos de compras….Además del R/3 Structure Modeler, ASAP ofrece una serie de cuestionarios para trasladar a los usuarios, a fin de identificar mejor las unidades de la estructura organizativa.
Una vez definida esta estructura, el siguiente paso es identificar y definir los procesos de negocio para el Business Blueprint. Ahora lo que hay que hacer es mapear los requerimientos de la empresa cliente con los procesos de negocio de SAP R/3, para realizar el diseño conceptual para la implantación de R/3. Es necesario llevar a cabo en este punto las siguientes actividades:
• Reuniones de trabajo o workshops por módulo
• Completar el Business Blueprint, revisarlo y conseguir la aprobación
• Establecer el calendario de formación a usuarios
• Identificar los requerimientos de informes, interfaces y cargas desde otras aplicaciones, autorizaciones y ampliaciones del sistema.
La importancia de estas reuniones es altísima, ya que toda la información que se reúna en ellas a través de rodos los asistentes servirá para realizar el documento Business Blueprint, la guía maestra para la implantación del sistema. Las principales herramientas ASAP para identificar y definir los procesos de negocio son el Modelo de Referencia R/3 y la Base de Datos de Preguntas y Respuestas, que se verán de forma detallada a continuación.
Modelo de Referencia R/3
El modelo de referencia R/3 contiene más de 1.200 procesos de negocio, y ha sido creado utilizando feedback por parte de los clientes de SAP R/3 a lo largo del tiempo.
Esta estructura y representación gráfica contienen todo los procesos de negocio y es muy útil para ilustrar la funcionalidad de las distintas áreas de SAP. Existen diferentes tipos de modelos dependiendo de a quién van dirigidos, o el propósito.
El modelo de referencia puede ser útil para comparar la funcionalidad estándar de R/3 con los procesos de negocio de la compañía y las estructuras organizativas de ésta, a fin de generar el Business Blueprint y para optimizar los propios procesos de negocio.
Los diferentes tipos de modelo de referencia, según los grupos a los que vaya dirigido, son los siguientes:
• Modelo de procesos. Contiene vistas del flujo de procesos de toda la funcionalidad R/3, por ejemplo, procesamiento de pedidos de compras.
El modelo de procesos, junto a la estructura organizativa forma una potente herramienta para el modelado de todos los requisitos de procesos de negocio y su optimización.
• Jerarquía de componentes.
En la jerarquía de componentes se seleccionan aquellos componentes que se va a utilizar en la compañía a fin de soportar los procesos de negocio. Por ejemplo: los componentes de Recursos Humanos (RRHH) o gestión de pagos a proveedores (FI-AP). Los componentes que se seleccionen en esta jerarquía influirán en la estructura de los siguientes componentes:
– Guía de implementación IMG.
– Session Manager, que es la pantalla inicial de SAP R/3.
– Generador de perfiles de usuario.
Ilustración 4. Jerarquia de componentes
• Modelo de objetos de negocio (BO Model).
Es una descripción de unos 200 Objetos de Negocio, como pueden ser clientes, vendedores, empleados…El propósito principal del BO Model es la determinación de las entradas/salidas de cada objeto de negocio del sistema.
Cada objeto en el sistema representa una entidad del mundo real, por ejemplo, un pedido de venta o un cliente. Desde la visualización del BO Model se podrá acceder también a toda la información técnica de cada objeto.
Ilustración 5. Información técnica del Objeto
El modelo de referencia R/3, junto al modelo de procesos, la jerarquía de componentes, modelo de objetos de negocio y otros modelos de datos con sus enlaces, se almacena en el Repositorio R/3. En este Repositorio también se almacenan las definiciones de datos, programas, pantallas, ampliaciones…
Base de datos de Preguntas y Respuestas
La Base de Datos de Preguntas y Respuestas (Q&Adb) contiene cuestiones técnicas y de negocio, cuyas respuestas son el input para la creación del Business Blueprint. Esto sucede porque las preguntas están diseñadas para definir los requerimientos de negocio de la empresa de forma detallada, en un entorno integrado.
En cada implantación se puede añadir, cambiar y eliminar el contenido de la Q&Adb por los miembros del equipo de proyecto, a fin de adecuarlo más a las necesidades concretas del cliente. Está estructurada en forma de árbol, y desde ahí se pueden ver todos los procesos de negocio implementados en el sistema R/3. A partir de esta herramienta también se pueden generar perfiles de autorización, así como enlazar directamente con actividades de la IMG.
Conclusiones
El Business Blueprint sirve como plan maestro conceptual y debe plasmarse en un documento escrito muy detallado. Este documento resume y documenta las necesidades del negocio en un detalle de grano muy fino, y sirve de base para la organización y configuración del sistema R/3 e incluso para los desarrollos que se llevarán a cabo.
Con el Business Blueprint se asegura de que todo el mundo tiene una comprensión exacta del alcance total de la implantación del proyecto, en relación con los procesos de negocio, la estructura organizativa, el entorno técnico del sistema, la formación del equipo de proyecto y los estándares del sistema R/3. También deben abordarse las cuestiones relativas a probables cambios en el alcance, que conlleven impacto sobre el presupuesto y/o la planificación de recursos.
El Business Blueprint debe ser generado y aprobado incluso en aquellas instalaciones en las que no se siga a pie de la letra la metodología ASAP, sin instalar las herramientas y los aceleradores. De hecho en la mayoría de los casos es así, se puede prescindir de gran parte de las herramientas, pero el Blueprint debe quedar finiquitado y firmado. También es recomendable hacer uno por cada módulo funcional.
La Fase 2 del ciclo de vida del proyecto SAP, conocida como «Business Blueprint» (o Esquema de Negocio), es una etapa fundamental en la que se definen los requisitos comerciales detallados y se crea un plan detallado para la implementación del sistema SAP. Durante esta fase, se trabaja estrechamente con los usuarios finales y las partes interesadas para comprender completamente los procesos comerciales existentes y definir cómo se implementarán en el sistema SAP:
- Recopilación de requisitos:
- Se lleva a cabo un proceso exhaustivo de recopilación de requisitos para comprender las necesidades comerciales y los objetivos del proyecto. Esto implica entrevistar a los usuarios finales, realizar talleres de trabajo, revisar la documentación existente y recopilar comentarios de las partes interesadas.
- Análisis de procesos comerciales:
- Se analizan y documentan en detalle los procesos comerciales existentes, desde la entrada de pedidos hasta la facturación, identificando las áreas de mejora, los puntos de dolor y las oportunidades de optimización.
- Definición del alcance del proyecto:
- Se define el alcance del proyecto, incluyendo los procesos comerciales que se incluirán en la implementación del sistema SAP, los objetivos del proyecto, los entregables esperados y los criterios de éxito.
- Diseño de soluciones:
- Se desarrolla un diseño de solución detallado que describe cómo se implementarán los procesos comerciales en el sistema SAP. Esto incluye la configuración del sistema, la personalización de funciones, la definición de flujos de trabajo y la integración con sistemas externos.
- Creación del Blueprint del negocio:
- Se crea un documento formal llamado «Blueprint del negocio» que describe los procesos comerciales, los requisitos del sistema, el diseño de solución propuesto y otros detalles relevantes del proyecto. Este documento sirve como guía y referencia para la implementación del sistema SAP.
- Validación y aprobación del Blueprint del negocio:
- El Blueprint del negocio se revisa y valida con los usuarios finales y las partes interesadas para garantizar que capture con precisión los requisitos comerciales y refleje las necesidades del negocio. Una vez aprobado, se convierte en la base para el desarrollo y la implementación del sistema SAP.
- Planificación detallada del proyecto:
- Se desarrolla un plan detallado para la implementación del sistema SAP, que incluye actividades, plazos, recursos necesarios, presupuesto y cualquier otro aspecto relevante del proyecto. Esto asegura que el proyecto se ejecute de manera eficiente y cumpla con los objetivos establecidos.
- Formación inicial y preparación del equipo:
- Se proporciona formación inicial al equipo del proyecto y a los usuarios finales sobre los procesos comerciales y el sistema SAP. Esto ayuda a preparar al equipo para la implementación y promueve una comprensión común de los objetivos y las expectativas del proyecto.
- Establecimiento de métricas y criterios de éxito:
- Se definen métricas clave de rendimiento (KPIs) y criterios de éxito que se utilizarán para evaluar el rendimiento y el impacto del sistema SAP una vez implementado. Esto ayuda a mantener el enfoque en los resultados comerciales y a medir el retorno de la inversión del proyecto.
- Aprobación del Blueprint del negocio y del plan del proyecto:
- Una vez completadas todas las actividades de la Fase 2, se obtiene la aprobación formal del Blueprint del negocio y del plan del proyecto por parte de las partes interesadas y la dirección del proyecto. Esto marca el final de la Fase 2 y el inicio de la fase de preparación para la realización del proyecto.