jueves, 30 de septiembre de 2010

Tips de buenas prácticas en control de cambios para SAP R/3


A continuación comparto algunos tips de buenas prácticas en control de cambio:

·                     Los cambios en las organizaciones que poseen el ERP SAP pueden ser por:  mantención de programas, mantención de tablas (customizing), roles/perfiles de usuarios (la mantención contempla: creación, modificación, eliminación)
·                     Los cambios se deben hacer en forma mandatoria en un ambiente de desarrollo (DES) y ser probados en un ambiente de calidad (QAS) antes de ser pasados a productivo (PRD)
·                     No se deben hacer cambios directamente en ambiente productivo (PRD)
·                     Los cambios no deben ser transportados desde ambiente de calidad (QAS) a productivo (PRD)
·                     El ambiente productivo debe permanecer cerrado y protegido de tal manera que no se pueda hacer transportes desde este mandante a otro (no puede ser mandante de origen de un cambio…solamente mandante de destino)
·                     Es recomendable poseer un ambiente SANDBOX para hacer ciertos cambios de pruebas funcionales y estos no hacerlos directamente en el ambiente de calidad (QAS) o se pierde el sentido de este último ambiente (en caso de pruebas con datos)
·                     Debe existir segregación funcional en el control de cambios (3 actores a lo menos para que exista un control por oposición de intereses):

    • Actor 1:               Autor del cambio  y genera orden de transporte Ej.: programador ABAP, consultor funcional (FI-CO-MM-SD, etc.), administrador de perfiles
    • Actor 2:               Liberador del cambio è Ej.: Oficial de Seguridad de la Información (valida la razonabilidad del cambio y si es válido lo libera)
    • Actor 3:               Transporta el cambio è Ej.: Administrador Basis, exporta el cambio desde el ambiente de origen (DES) al destino (QAS-PRD)
         
·                     Ningún usuario final debería tener acceso a ambiente de desarrollo (DES).  A menos que tenga funciones de key user funcional y le toque hacer customizing de tablas
·                     Los cambios funcionales deben ser aprobados por los dueños de procesos (dueños de la información)
·                     Los cambios del componente basis deben ser aprobados por el dueño del proceso de TI
·                     Solamente se deben liberar para transportes cambios validos
·                     Los cambios deben ser monitoreados por la función de seguridad de la información de la organización
·                     Auditoría interna debería auditar como parte de su plan anual de auditoría el hecho que los cambios estén operando bajo un entorno de control interno razonable
·                     Debería existir una política y procedimiento que le proporcione gobernabilidad al control de cambios y que esta sea sustentable en el tiempo
·                     Finalmente, las transacciones que se mencionan a continuación, deben estar restringidas en ambiente productivo y eventualmente asignadas solamente en modo display en dicho ambiente, excepto la transacción SE16N que no debería estar asignada en ambiente productivo por ningún motivo, por el riesgo de edición directa de tablas en dicho ambiente:

    • Transacciones:          
                                                                                                                                     
      • SE38:                          Cambios de programas ABAP  / Actor: Programador ABAP
      • SPRO:                         Cambios de customizing  / Actor:  Key user funcional – Consultor funcional
      • SM30 Y SM31:            Cambios sobre tablas / Actor:  Key user funcional – Consultor funcional
      • PFCG:                         Cambios de roles de usuarios / Actor: Administrador de roles y perfiles de usuario
      • SU02:                          Cambios de perfiles de usuarios / Actor:  Administrador de roles y perfiles de usuario
      • SE16N:                                   Cambios vía edición de tablas (comando &SAP_EDIT) / Actor: Key user funcional – Consultor funcional (Solamente ambiente DES.  Nunca PRD)
      •  SE10:                         Liberación de ordenes de transporte / Actor:  Oficial de Seguridad de la Información
      • STMS:                         Transporte de ambiente de origen a uno de destino / Actor: Administrador BASIS

domingo, 26 de septiembre de 2010

GRC...el nuevo concepto

Quizás usted ha leído en algún artículo relacionado con control interno, gobernabilidad corporativa o gestión de riesgos, la sigla "GRC" (Governance, Risk & Compliance), lo más probable es que si no la ha visto hasta el momento, muy pronto se encontrará con alguna publicación que lo mencione y con mucha fuerza.

El Governance, Risk & Compliance, habla del nuevo concepto de control interno, que le da especial énfasis a la gobernabilidad corporativa, gestión integral de riesgos del negocio y cumplimiento de leyes y regulaciones, lo que como concepto resulta mucho más amplio que hablar de Control Interno.

Generalmente, los profesionales del control interno asocian esto último con COSO, COSO II, etc. pero hoy en día nos encontramos con el concepto de GRC, que involucra un todo y ese todo, implica directrices de alto nivel de los comités de directores de las compañías, aspectos de cumplimiento tales como Ley Sarbanes Oxley o aspectos ambientales y de responsabilidad social empresarial (RSE).

El concepto GRC, le da especial énfasis a la automatización de la gestión de gobernabilidad, riesgo y cumplimiento, de tal forma que estas acciones sean apoyadas por medio de herramientas o soluciones que permita gestionar tanto riesgos estratégicos, específicos y hacer management de los controles que sustentan un modelo GRC en el tiempo de manera automática y eficiente, sin perder de vista los aspectos regulatorios que conllevan al cumplimiento de diversas normativas tanto locales como internacionales que deben cumplir las empresas.

Hace un tiempo atrás se anhelaba contar con soluciones que permitieran poder gestionar el control interno de las empresas en tiempo real y privilegiando los enfoques más bien preventivos que detectivos o reactivos y hoy en día es una realidad. De hecho las empresas que han implementado paquetes World Class (ERP) para la gestión de sus empresas, actualmente cuentan con la posibilidad de automatizar la gestión de todos los controles automáticos y manuales, riesgos estratégicos y específicos, por medio de soluciones orientadas al GRC como las siguientes:

- SAP GRC
- ORACLE GRC
- CA GRC
- Entre otras.