Metodología de desarrollo en una compañia

Continuando la discusión desde ¿Para qué dejar una OT a un usuario?:

Esto ya es otro tema, de como se trabaja u opera SAP en desarrollos/proyectos.

Si nadie dice nada de como operar te acomodas a como trabaje la consultora de turno. En mi experiencia (que es poca xD) cada empresa debería tener sus lineamientos de desarrollo en SAP, digamos que es buena práctica que todas las personas que intervienen en el tiempo en tu sistema trabajen de una sola forma.

hay de todo; empresas que esto no es de interés y nunca lo será, empresas que parten ordenadas y empresas que maduran a través del tiempo.

Según mi punto de vista, todo depende de la calidad de jefaturas que tengas (a cargo del sistema SAP) y que tan fuerte te golpeé auditoria (interna/externa)

Yo tengo ideas de que cosas se pueden documentar con este fin, pero dejó abierto el tema para ver que consideran ustedes se puede documentar y que todo personal desarrolle de una forma para su empresa.

Está bien, pero depende de cuándo se esté dando el “desarrollo” de SAP.
Es decir, si la empresa está implementando SAP, tendrá la metodología que tenga la consultora encargada de la implementación.

Yo he trabajado en varias empresas (consultoras) que implementan sobre otros clientes, y en algunas existía una fuerte cultura organizacional que transmitían al cliente, entonces le “enseñaban” al mismo cómo crecer con la implementación de SAP.

Otras empresas, en cambio, carecen de dicha cultura, y la implementación está en manos al 100% de los líderes del proyecto. Si el líder no tiene idea, usará en este caso de las OT, cualquier criterio, de hecho algunos dejan que cada consultor organice su módulo de la forma que él quiera. De esa forma, la empresa al final del camino (de la implementación) no tiene nada, nada más que un enjambre de cosas que no sabe cómo acomodar, si el consultor no lleva un orden o criterio para OT, y ese consultor al final de la vida del proyecto decide renunciar, pobre el consultor que lo reemplace!

Ni hablar del cliente, cuando la empresa implementadora se va… el cliente se queda con SAP funcionando pero un desconocimiento TOTAL de lo que ocurrió con las OTs.

Por eso depende mucho de cada empresa, y depende mucho de cada cliente.
Por más que el cliente tenga 100 años de experiencia en la industria “x”, al implementar SAP no sabrá lo que es una “OT”. :stuck_out_tongue:

Y bueno, alto debate.

ojo las generalidades. Solo por dar un caso en las implementaciones de rollout, viene gente que sabe y enseña desde otra empresa/sociedad por no decir los que se quedan trabajando donde implementan.

La metodología se refiere a un documento que contenga:

  1. Landscape de la empresa
  2. Convención en la denominación de ordenes de transportes y procedimientos relacionados a estos.
  3. ABAP
  • Convenciones para nombrar objetos (transacciones, tablas, campos, etc)
  • Prácticas de desarrollo ( tipificación; sangria, nombre de variables, documentacion de código; grupos de autorización objetos abap, paquetes de desarrollo a utilizar)
  • Procedimientos para solicitar clave de desarrollador, registro de objetos a modificar
  1. Seguridad
  • Listado de roles predefinidos para utilizar por personal externo (se actualiza a medida que se generen)
  • Listado de permisos críticos no asignables en ambiente productivo
  • Procedimiento para solicitud de usuario SAP (autorizaciones, permisos, periodos de validez)
  • Responsabilidad en la definición de roles SAP de desarrollos nuevos

por ejemplo…

Si, yo decía haciendo hincapié en el tema de las OT nomás.

Este tema se cerró automáticamente 91 días después del último post. No se permiten nuevas respuestas.