Governance, Risk & Compliance (GRC) y su aplicabilidad con la Nueva Ley 20.393 de Responsabilidad Penal de las Personas Jurídicas (aplica en CHILE)

Hace ya casi un año se promulgó la Ley 20.393  publicada en el Diario Oficial de 2 de diciembre de 2009 y que regula un sistema de responsabilidad penal de las personas jurídicas aplicable sólo a los delitos de lavado de activos, financiamiento del terrorismo y cohecho a funcionario público nacional e internacional, precisando que sólo pueden cometer estos ilícitos las personas jurídicas de derecho privado y las empresas del Estado.

Esto implica que las personas jurídicas serán responsables de los delitos que se señalan anteriormente y que fueren cometidos directa e indirectamente en su interés o para su provecho. (por sus dueños, controladores, responsables, ejecutivos principales, representantes o quienes realicen actividades de administración y supervisión, siempre que la comisión del delito fuere consecuencia del incumplimiento, por parte de ésta, de los deberes de dirección y supervisión.

Este marco legal indica que serán también responsables las personas jurídicas por los delitos cometidos por personas naturales que estén bajo la dirección o supervisión directa de alguno de los sujetos mencionados en el párrafo anterior (no serán responsables en la medida que las personas naturales hubieren cometido el delito exclusivamente en ventaja propia o a favor de un tercero) y se considerarán que los deberes de dirección y supervisión se han cumplido cuando, con anterioridad a la comisión del delito, la persona jurídica hubiere adoptado e implementado modelos de organización, administración y supervisión para prevenir delitos.  

El articulo 4° de la ley, menciona que las personas jurídicas podrán implementar un modelo de prevención de los delitos contemplando:

1.- Designación de un encargado de prevención (que puede ser Contraloría, Auditoría Interna)

2.- Definición de medios y facultades del encargado de prevención (deben tener la debida Independencia y Objetividad)

3.- Establecimiento de un sistema de prevención de los delitos (puede ser gestionado por medio del uso de  soluciones tecnológicas para la gestión de Governance, Risk & Compliance para darle sustentabilidad en el tiempo al modelo)

4.- Supervisión y certificación del sistema de prevención de los delitos. (También puede ser gestionado con una solución tecnológica GRC para darle sustentabilidad en el tiempo al modelo)

Estas medidas toman mayor relevancia, considerando que además constituyen factores atenuantes para las personas jurídicas, el hecho que tengan implementado modelos de prevención de delitos y que los mismos tiendan al monitoreo continuo en línea de las transacciones que se realizan y así identificar oportunamente cualquier delito de esta índole.

Claramente, las empresas que han diseñado modelos de control interno destinados al cumplimiento de la Ley Sarbanes Oxley (Ley SOX), se ven en ventaja en relación a las que no han implementado modelos de certificación del control interno, pero si nos referimos a la ley 20.393, estas medidas de prevención deben estar destinadas a cubrir  los delitos de lavado de activos, financiamiento del terrorismo y cohecho a funcionario público nacional e internacional  y no solamente el control interno del reporte financiero como lo exige la Ley SOX.

Por último, es importante tener presente que los modelos de control interno alineados con GRC (Governance, Risk & Compliance), al tener enfoques top-down, cubren los ámbitos financieros, operacionales y de cumplimiento, abarcando todas las unidades funcionales de la empresa (persona jurídica), partiendo de los ámbitos estratégicos hasta bajar a los niveles más operativos y/o tácticos de procesos de negocio,  por lo que resultan mucho más óptimos al momento de pensar en el cumplimiento de este tipo de marcos legales, pero no hay que olvidar el uso de las tecnologías para la gestión de estos modelos que son dinámicos en el tiempo y en donde se maneja gran cantidad de información histórica (evidencias, aprobaciones, certificaciones, etc.)

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

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.

Estrategia de Seguridad y Controles para un sistema ERP

Hoy en día la mayoría de las grandes empresas y en parte las medianas, han implementado, se encuentran en proceso o con planes de implementar un paquete de clase mundial ERP. Si nos situamos en el contexto de la Gobernabilidad Corporativa, Gestión de Riesgos y Cumplimientos, como se denomina en inglés “Governance, Risk and Compliance (GRC)”, concepto que paulatinamente se está situando y aplicando globalmente en las distintas industrias, implica que las empresas comiencen a llevar a cabo iniciativas para potenciar el control interno pero con una perspectiva más estratégica, lo que claramente se traduce en beneficios en el corto, mediano y largo plazo.

El hecho que las compañías lleven a cabo estas iniciativas, implica que necesariamente cambia la naturaleza de los controles, considerando que de muchos controles manuales en los procesos de negocio, al implementar el sistema ERP tiende a aumentar la cantidad de controles automáticos, puesto que la gran mayoría de los ERP tienen variadas posibilidades para implementar estos controles.

Esto ha implicado, que en el último tiempo las empresas consideren equipos de seguridad y control como parte de los frentes que implementan los sistemas ERP, de tal forma que estos se preocupen de abordar estos aspectos y con eso contribuir a que tanto los procesos relacionados con tecnologías de información y comunicación (TICs), como de negocios cuenten desde el inicio de la operación del sistema ERP, con mecanismos que permitan asegurar la integridad, confidencialidad y disponibilidad de la información y mitigar los riesgos de errores y fraudes.

Los equipos de seguridad y control, suelen estar compuestos por las unidades de auditoría interna, contraloría y especialistas en seguridad y controles en ERP, lo que genera una sinergia tal que contribuye con los frentes funcionales para el aseguramiento de la calidad de la implementación.

Cabe mencionar, que en la medida que los frentes de seguridad y control, estén compuestos por auditores internos, no es recomendable que estos se involucren en tareas relacionadas con la implementación de los controles o configuración de parámetros de seguridad del sistema ERP, dado a que esto haría perder independencia y objetividad cuando se tenga que auditar esos procesos en la organización, considerando que esta última es una de las normas esenciales del auditor, lo que hace recomendable que su rol esté relacionado con el aseguramiento de calidad y monitoreo de estos aspectos.

A continuación se mencionan las consideraciones de seguridad y control que deben tener presentes todas las empresas al momento de implementar un sistema ERP y como parte de sus planes de mejora continua:

1. Controles de Seguridad del ERP:

a. Calibración de controles relacionados con parámetros de seguridad de la aplicación: Password, user id, intentos fallidos, autenticación, entre otros.

b. Controles relacionados con la seguridad del sistema operativo, redes y base de datos que soportarán el ERP, denominados también controles generales de las TICs.

c. Definición de una estrategia de segregación funcional (privilegios incompatibles y críticos) para los roles y perfiles de usuario del ERP, en donde se consideran usuarios finales y súper usuarios que harán uso del sistema.

d. Controles para asegurar los desarrollos internos relacionados con funcionalidades no estándar tales como: Programas y tablas.

e. Definición de políticas y procedimientos de seguridad de la información, que contempla: Procedimiento de asignación de privilegios, administración del maestro de usuarios, control de cambios para los desarrollos internos, criterios y buenas prácticas para la configuración y mantención de parámetros de seguridad, entre otros.

2. Controles de Procesos de Negocio del ERP:

a. En este ámbito se establecen los controles de los procesos de negocio y el frente de seguridad y control realiza la revisión de los documentos que han sido preparados por los frentes funcionales, de tal manera de asegurar que se estén considerando los aspectos de control del proceso, ya que posteriormente los frentes implementadores deben tomar esta información y hacer las parametrizaciónes de los módulos integrados del ERP que sustentaran posteriormente los procesos de la empresa.

Aquí se recomienda que la parametrización de estos controles sea parte del alcance del proyecto de implementación del ERP.

A continuación se mencionan algunos controles típicos de procesos de negocio que deben ser adecuadamente parametrizados:

Ciclo de Gastos: Que se relaciona con los procesos de negocios compras, cuentas por pagar y pago (procesamiento de desembolsos) a acreedores:

- Bloqueos automáticos de facturas duplicadas de acreedores

- Aprobación automática de órdenes de compra definidas por montos (tramos)

- Consistencia orden de compra v/s factura

- Bloqueos automáticos de facturas no asociadas a órdenes de compra

- Controles para el pago de facturas de acreedor sin órdenes de compra

- Controles relativos a las propuestas masivas de pago a acreedores asociados a orden de compra

- Controles para la gestión de los contratos marcos u órdenes de compras abiertas

- Integridad y validez del maestro de proveedores, entre otros.

Ciclo de Existencias: Que se relaciona con los procesos de negocios gestión de stock de bodegas (aumento disminución de existencias) e inventarios:

- Límites de tolerancia en la recepción de productos en bodegas (consistencia orden de compra v/s guía de despacho del proveedor)

- Campos obligatorios para el registro de aumentos y disminuciones de existencias

- Control de movimientos de existencia

- Control de ajustes de inventario de existencias

- Parámetros de valorización de la existencia

- Integridad y validez del maestro de materiales

b. Todas estas consideraciones de control, deben ser sustentadas con políticas y procedimientos que permita reflejar los criterios de control aprobados por la administración, tales comomontos, porcentajes de tolerancias, aprobadores, etc. y así poder tener más claridad respecto a los criterios que se deben resguardar y monitorear en el tiempo.

Finalmente, es importante saber que muchas de estas consideraciones de seguridad y controles, actualmente han sido contempladas por las soluciones de Governance, Risk and Compliance (GRC) que los grandes proveedores de ERP de clase mundial han desarrollado y que paulatinamente las empresas los están evaluando para poder mantener un modelo de seguridad y control interno que sea eficiente, sustentable en el tiempo y apoyado por las tecnologías de la información.

La nueva tendencia Governance, Risk & Compliance (GRC) y el rol del auditor en las empresas

Dado a que hoy en día nos encontramos en un mundo globalizado, en donde las empresas están cada día aumentando su grado de interacción con otras latitudes ya sea producto de fusiones y/o adquisiciones o simplemente dado a la comercialización que llevan a cabo en relación a la oferta y demanda de bienes y/o servicios, esto ha implicado que las compañías tengan la necesidad de potenciar el grado de confianza de cara a los inversionistas ya sean locales o extranjeros, tomando en consideración los escándalos financieros ocurridos en EE.UU. a principios de la década con las empresas Enron y WorldCom, que implicó además la caída de una de las grandes firmas auditoras multinacional llamada Andersen, que era parte del selecto grupo de las denominadas "big five". Todas estas situaciones han implicado que tanto empresas como inversionistas actúen con más cautela, con especial énfasis aquellos que cotizan en la bolsa de Nueva York que actualmente están regidos por los estándares de cumplimiento de la Ley Sarbanes Oxley, que obliga a que tanto el CEO como el CFO, certifiquen respecto a la confiabilidad del control interno de su reporte financiero.

Todo esta problemática ha hecho cambiar la visión estratégica de las empresas en lo relativo al control interno y hoy en día surge con más fuerza el concepto de Gobierno Corporativo, que implica que las empresas tengan directrices que apunten a la transparencia, dotando de mecanismos orientados a la supervisión más rigurosa y a potenciar los códigos de ética aplicables desde los Directores al resto de los empleados.

Asimismo, para apalancar el cumplimiento de los objetivos estratégicos y específicos asociados a los procesos de negocio, las empresas están implementando modelos de gestión integral de riesgo de negocio, que les permita mitigar situaciones que los pueda poner en riesgo de perder valor, mermar el margen de contribución o la imagen, desde una perspectiva financiera, operacional y de cumplimiento, lo que claramente tiene como resultado perder la confianza de los inversionistas y por ende del mercado en la medida que estas situaciones se llagaran a materializar.

Para evitar el hecho que proliferen escándalos financieros y de otra índole, los mercados se están poniendo cada día más rigurosos en la exigencia de regulaciones y vale la pena citar lo que ocurre actualmente en EE.UU. con la industria financiera en donde no se han seguido criterios de control rigurosos relativos a la mitigación del riesgo de crédito para las hipotecas, ha generado una crisis financiera en el mercado local, que actualmente está repercutiendo en la economía global con el consiguiente impacto en las empresas, generando finalmente una crisis económica mundial. Esto implicará que en el corto y mediano plazo se emitan regulaciones de cumplimiento más rígidas que tiendan a evitar estos escándalos y crisis, exigiendo a las empresas el cumplimiento de ciertas directrices regulatorias tendientes a potenciar la confianza de los inversionistas, hacer que las empresas sean más sustentables y por ende contribuir a que los mercados y las personas no se vean afectados.

Lo mencionado anteriormente, implica que en la actualidad nos encontramos en un mercado global en donde las competencias de los profesionales que asesoran a las empresas en materia de control interno, tengan que dominar claramente todos los conceptos relacionados con la Gobernabilidad Corporativa, la Gestión del Riesgo y el Cumplimiento, lo que va de la mano con los estándares de clase mundial que actualmente se consideran para estas iniciativas, tales como: COSO II (ERM – Enterprise Risk Management), Basilea II (Industria Financiera), Sarbanes Oxley (SOX), COBIT, entre otros. Esto permitirá a que estos profesionales contribuyan a las empresas agregando valor en estos ámbitos que son de carácter más estratégico y por ende permite que el perfil del profesional Contador Auditor y otros a fines, esté en mayor sintonía con lo que hoy requieren las empresas tanto en el mercado local como internacional.

Actualmente existe una entidad global denominada OCEG (Open Compliance and Ethics Group - http://www.oceg.org/) que está generando directrices y buenas prácticas para ayudar a que globalmente se estandaricen los procedimientos y metodologías para la implementación de modelos de Governance, Risk & Compliance (GRC) en las empresas y los principales proveedores tecnológicos tales como SAP, ORACLE y CA, ya están considerando como parte de sus sistemas, soluciones destinadas a automatizar la gestión de GRC, lo cual también requiere de especialistas que manejen las funcionalidades asociadas a estas herramientas de TI.

Gestión de Roles y Perfiles de Usuarios en SAP - 12 Lecciones claves aprendidas a partir de las implementaciones de SAP

1. Es más óptimo administrar roles por función de negocio que roles hechos a la medida del usuario (se debe aplicar una lógica alineada con el negocio)
2. Los roles compuestos es más óptimo utilizarlos para ser relacionados con los cargos del negocio (si está HCM implementado se podría vincular los roles compuesto con las posiciones de RR.HH. y se optimiza la administración)
3. Se debe hacer roles especiales para las transacciones críticas del negocio, como por ejemplo: Liberación de Pedidos de Compra o Customizing SAP y para las visualizaciones
4. Se debe utilizar roles derivados Padre-Hijo solamente en aquellos casos en donde exista estandarización de funciones y diferentes unidades organizativas.  Ej.:  Bodegueros de Chile, Perú, Argentina hacen todos exactamente lo mismo en la gestión de stock
5. No se debe mezclar los roles por función estándar con los transacciones  Y-Z, por lo que se deben hacer roles especiales que contengan estas transacciones
6. Se debe agregar seguridad a los desarrollos ABAP (Y-Z) y debe ser asociado a una transacción SAP (Y-Z) (AUTHORITY-CHECK-Objeto de autorización)
7. Se debe realizar un análisis de incompatibilidades y de asignación de transacciones críticas en forma permanente
8. Es recomendable utilizar herramientas computacionales que permita hacer análisis de segregación funcional, con el fin de monitorear continuamente estos aspectos del negocio y así evitar los rediseños de roles y perfiles permanentes
9. La administración de roles y perfiles no debe ser realizada por las unidades de auditoría interna, toda vez que se merma el ambiente de control interno (juez y parte – se pierde independencia)
10. Es recomendable que exista una función de gestión de seguridad de la información que colabore con la línea para ayudar en la administración de los roles y perfiles
11. Si está implementado el módulo HCM la administración de roles y perfiles SAP, podría ser realizada por Recursos Humanos (ejecución de cambios en los roles y perfiles)
12. Las decisiones de cambios o asignaciones de privilegios las deben tomar los dueños de la información (dueños de procesos)

¿Por qué es importante la seguridad y auditoría de los sistemas ERP?

Dado que actualmente nos encontramos en un mundo globalizado donde las empresas cada vez más tienden a ser parte de un grupo multinacional o simplemente operan en forma local interactuando con empresas que se encuentran en otras latitudes. Esto ha implicado que cada día aumente la necesidad de que las empresas cuenten con información integrada y en tiempo real, tanto para la toma de decisiones como para el procesamiento de las transacciones rutinarias de negocios.

Es por esta tendencia que las empresas paulatinamente han tenido la necesidad de contar con un sistema ERP de clase mundial, que contribuya a ser más competitiva y eficiente la operatoria de sus procesos de negocio.
Cabe mencionar que actualmente en el mundo, los sistemas ERP que predominan en las empresas son SAP, ORACLE y PEOPLESOFT, de ahí radica la importancia de poder entender específicamente los aspectos de seguridad y auditoría asociados a estas aplicaciones.
ERP: Sistema de planificación de recursos de la empresa.

Gestionando los riesgos de accesos en los ERP

Los accesos a los sistemas de aplicación y los privilegios que son otorgados a los usuarios, pasan a ser un tema rutinario en las empresas y dado al dinamismo de estas tareas, los riesgos se incrementan día a día, puesto que no siempre se considera un análisis de criticidad o de la incompatibilidad que pudieran presentar ciertos privilegios otorgados a los usuarios.

Esto en el tiempo hace proliferar una serie de vulnerabilidades en la seguridad, lo que podría generar impactos en la disponibilidad, confidencialidad e integridad de la información del negocio, con consecuencias sobre los ámbitos financieros, operacionales o de cumplimiento.

Para mitigar estos riesgos, las empresas se han comenzado a sensibilizar, sobre todo considerando que en las actuales implementaciones de ERP, ya se contempla frentes de seguridad de la información, que se encargan de que estas problemáticas sean abordadas en el marco de estos proyectos con una visión integral de las unidades funcionales de la empresa y manteniendo un punto de equilibrio entre el control interno y la operatividad del negocio.

La otra forma de abordar la problemática, es gestionando la asignación de privilegios por medio de herramientas para el control de acceso que realizan evaluaciones de riesgo de segregación funcional en forma automática, gracias a las reglas pre-definidas que estas poseen y apoyados por soluciones tecnológicas orientadas a la gestión de identidades en los accesos.

Actualmente se puede ver como una buena práctica, el hecho que la gestión de privilegios de accesos, sea efectuada desde las áreas de recursos humanos y en la medida que se da de alta un empleado en los módulos de gestión de personal, este asume en forma automática los privilegios inherentes al cargo, pero para que esto sea aplicable debe existir un modelo de privilegios alineado con los cargos de la organización y depurados desde el punto de vista de la criticidad o incompatibilidad que pudiera tener, pensando siempre en el "control por oposición de interés", lo que a larga mejora sustancialmente la segregación funcional y por ende el ambiente de control del negocio.

Por consiguiente, podemos concluir que cuando se toman medidas oportunas en esta línea, se evitará los reiterados rediseños de privilegios que gran parte de las empresas que han implementado un sistema ERP ha tenido que realizar y por ende se evitará la materialización de incidentes de seguridad que pudieran poner en riesgo al negocio.

-------------------------------------------
Sígueme en Twitter: @pdhernandezf
-------------------------------------------

Impacto de los upgrade en los controles de ERP

Muchas organizaciones que poseen un sistema de clase mundial (ERP), tienen contemplado efectuar un upgrade para contar con nuevas funcionalidades o mejorar a las ya existentes, y así optimizar sus procesos de negocios.

Efectivamente, en el último tiempo los requerimientos de upgrade de las empresas en Chile han tendido a aumentar significativamente, especialmente producto de la necesidad de cumplir con los nuevos estándares para el reporte de la información financiera (IFRS), que entrarán en vigencia en los próximos años. Dado que un upgrade o actualización a una nueva versión en un sistema ERP aborda aspectos funcionales y técnicos, este puede producir impactos importantes en el control interno asociado. Entre las áreas que pueden verse afectadas, es importante considerar las siguientes:

Controles configurados:

- Impacto en los controles relativos a grupos de autorizaciones para la protección de nuevas tablas de las bases de datos físicas de los ERP.

- Impacto en los controles configurados que han sido desarrollados internamente (no estándar) a la medida del negocio, asociados a parámetros de la versión anterior.

- Nuevos campos obligatorios y controles configurados relacionados con las nuevas funcionalidades. Por ejemplo, controles de aprobación de órdenes de compra, controles de límites de tolerancia o controles de registro doble de facturas. Esto impactará en los ciclos de negocio, y por ende, en los procesos.

- Impacto en los controles configurados asociados a interfaces de los sistemas ERP con otras aplicaciones.
 

Controles configurados y lineamientos con IFRS:

- Nuevas funcionalidades asociadas (planes de cuentas, revelaciones adicionales, nuevo formato).

- Necesidad de desglosar los componentes más significativos de los estados financieros asociados a las líneas negocios (segmentación de negocio).

- Cambio de base de costo.

- Eliminación de corrección monetaria y control de corrección monetaria para propósitos tributarios.- Moneda funcional, entre otros.

Controles de autorización (perfiles de usuario):

- La actualización incorpora nuevas transacciones o funcionalidades, entre ellas transacciones críticas que los usuarios tendrán que tener en sus perfiles de usuario.

- Transacciones nuevas que generarán incompatibilidad desde el punto de vista de la segregación funcional.

- Nuevas tablas y programas que impactarán en los perfiles de usuario a nivel de los grupos de autorización que controlan el acceso.

- Transacciones antiguas que quedarán discontinuadas con las nuevas funcionalidades y que los usuarios deberán tener presente para no impactar la operación del negocio.

- Funcionalidades desarrolladas internamente a la medida del negocio que eventualmente tendrán problemas de ejecución, producto de la interacción con nuevas tablas y programas de la nueva versión, las cuales estarán dentro de los perfiles de usuario.

- Funcionalidades desarrolladas internamente que serán reemplazadas por transacciones estándar de la nueva versión.

Control de cambios (desarrollos internos):

- El impacto en este ámbito está referido a los desarrollos de tablas, programas y transacciones a la medida del negocio, ya que estos contemplan interacción con funcionalidades estándares de la antigua versión y eventualmente dichas funcionalidades podrían ser reemplazadas por transacciones nuevas.

Controles de integridad en la migración:

- Integridad a nivel de upgrade técnico y funcional (eventualmente podrían existir fallas a nivel de exactitud y totalidad de la información migrada).

- Funcionamiento de las transacciones desarrolladas internamente que serán migradas a la nueva versión, con especial énfasis en aquellas que son críticas.

Todas estas consideraciones de controles se deberán tener presente al abordar un proyecto de migración a una nueva versión de un sistema ERP, con el fin de no tener sorpresas o impactos no deseados en la operación del negocio y el ambiente de control interno.

Seguridad en el uso de ABAP Query en SAP

Uno de los típicos dolores de cabeza en las empresas que poseen implementado un ERP como SAP, está asociado a la seguridad de las consultas a las bases de datos por medio de herramientas que permiten desarrollar Query.

Dado a los riesgos sobre la confidencialidad de la información que implica el hecho de no considerar buenas prácticas de seguridad en este ámbito, se hace importante tomar en consideración y adoptar ciertas directrices tales como las que les comentaré a continuación, que sin duda alguna ayudará a tomar conciencia respecto a este tema tan sensible en las organizaciones:

- Es recomendable que los usuarios finales de SAP, solamente utilicen la transacción SQ00 para la ejecución de Queries ya desarrollados por usuarios más expertos y que esta asignación sea materializada a nivel del perfil de usuario, con el objeto de autorización S_QUERY segmentado a valor de actividad 23.

- Para aquellos usuarios con un grado medio de expertise en Query, es recomendable asignar la transacción SQVI que permite crear y ejecutar Queries propios de los usuarios, pero igual es riesgosa ya que da la posibilidad de tomar tablas que eventualmente pudieran tener información confidencial para la compañía.

- Respecto a las transacciones SQ01, SQ02 y SQ03, no es recomendable asignarla a usuarios finales, ya que cada una de estas permite:

- SQ01 Query SAP. Actualizar queries: Crear, modificar y eliminar un Query ya existente

- SQ02 Query SAP. Actualizar Infoset: Crear, modificar y eliminar un Infoset. Estos Infoset corresponde a segmentos o agrupaciones de bases de datos, cuya información se obtiene de las tablas físicas que están asociadas a las bases de datos logicas de SAP.

- SQ03 Query SAP. Actualizar grupos usuarios: Crear, modificar y eliminar grupos de usuarios. Estos grupos de usuarios generalmente son los que se crean para agrupar un cierto segmento de Infoset o Queries a 1 o N usuarios, dependiendo de la necesidad de delimitación que tenga la compañía.

Asimismo, las buenas prácticas de creación y mantención de Queries, recomiendan que para darle un uso sustentable en el tiempo a esta funcionalidad, se debe contar con un procedimiento que permita normar estas acciones y que en definitiva, en forma mandatoria se siga la siguiente secuencia para la creación de nuevos Queries:

Es recomendable que toda esta secuencia la haga un usuario experto en Query:

Paso 1: Crear el Infoset ==> Transacción SQ02

Paso 2: Crear grupo de usuario y asociar Infoset a grupo de usuario ==>Transacción SQ03

Paso 3: Crear Query y asociar Infoset del Paso 1 ==> Transacción SQ01
Paso 4: Informar a usuario para que pruebe Query ejecutando ==> Transacción SQ00

En resumen los riesgos que debemos considerar en materia de Queries en SAP son:

- Acceso a información confidencial o sensible de la compañía, por medio de consulta directa a la base de datos.
- Un query al estar mal desarrollado puede mermar el performance de la operación en ambiente productivo del sistema y por ende poner en riesgo la oportuna acción de ciertas transacciones SAP claves para normal operación del negocio.
- Robo o fuga de información sensible:
- Recetas de productos claves para el negocio
- Maestros (clientes, proveedores, personal, materiales)
- Información estratégica del negocio

ATENCIÓN: Vulnerabilidades en SAP R/3 ==> Uso de la Transacción SE16N y ejecución del comando &SAP_EDIT: Permite la modificación de tablas en forma directa estando el mandante cerrado incluso.

Respecto a la transacción SE16N (con autorización S_DEVELOP+valor 01 y 02) en SAP ejecutando el comando &SAP_EDIT, se puede modificar las tablas en forma directa. existe una nota (SAP Note 1420281) que permite dejar obsoleta la aplicación de dicho comando para modificar tablas directamente. Esta es una brecha de seguridad que existe en la mayoría de las empresas.

Esta modificación se puede hacer estando el mandante protegido incluso, lo que hace que sea más crítico aún. (tabla T000):

- Autoriz.para actual.objetos válidos para todos los mandantes
- Protecc.de programa p.copiar mandantes y herram.comparación

Los cambios a las tablas haciendo uso de este comando, quedan en un log estándar en las tablas: SE16N_CD_KEY (cabecera) y SE16N_CD_DATA (detalle).

-------------------------------------------
Sígueme en Twitter: @pdhernandezf
-------------------------------------------

Tips de segregación funcional en el control de cambios en SAP R/3

Las buenas prácticas de control interno recomiendan:

Control de Cambios en SAP R/3:
- El que libera las órdenes de transporte debe ser distinto al que ejecuta el cambio y distinto al que realiza el import al mandante de destino (3 actores):

Actor 1: Ejecutor del cambio y generador de la orden de transporte ej.: Programador ABAP
Actor 2: Liberador de la orden de transporte ej.: Oficial de Seguridad de la Información
Actor 3: Ejecutor del import al mandante de destino ej.: Administrador Basis

Ej.: Programador que ejecuta un cambio en ambiente de desarrollo sobre un programa ABAP, si bien debe generar la orden de transporte (a ambiente de prueba o productivo), no debe además liberarla por medio de la transacción SE10 y se recomienda que lo haga una instancia de control (seguridad de la información). Esta instancia de control debería ser de la línea y se recomienda que no sea el Auditor Interno ya que este último perdería independencia al ejecutar esas liberaciones.

Por lo tanto, los usuarios que ejecutan cambios en el sistema, no deberían tener la transacción SE10 liberación de órdenes de transporte.

Por otra parte, la materialización o import del transporte vía transacción STMS, debería hacerla un usuario distinto del que ejecuta el cambio y del que libera la orden de transporte y se recomienda que lo haga el Administrador Basis.

Con este procedimiento, mitigamos el riesgo de que un mismo usuario haga cambios indebidos por ejemplo de programas, tablas, roles y/o perfiles de usuario en ambiente de desarrollo y que los mismos no sean identificados antes de que lleguen a ambiente productivo de destino.

Esto debería estar contenido en un procedimiento o un marco de gobernabilidad de tal forma de hacer sustentable en el tiempo la operatoria de estas buenas prácticas.

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