Dlver Crear Modelo de Autorizaciones Sap (1)

INDICE GENERAL

Pág. Introducción ………………………………………………………………………….. 5

Capitulo I ..... ………………………………………………………………………….. 7

Planteamiento del problema ………………………………………………… 7

Justificación …………………………………………………………………... 9

Objetivos ………………………………………………………………………. 11

Obj. General ………………………………………………………….. 11

Obj. Específicos ……………………………………………………… 11

Capitulo II ……………………………………………………………………………... 12

Marco teórico ………………………………………………………………….. 12

¿Qué es SAP? ……………………………………………………….. 12

Características generales del SAP R/3 ……………………………. 14

Módulos de operación ……………………………………………….. 16

Bases teóricas ………………………………………………………………… 20

¿Qué son las autorizaciones? ……………………………………… 20

¿Porque que se necesitan autorizaciones? ……………………..... 21

Desarrollando un modelo de autorizaciones ………………………. 23

Elem. y term. básicas del modelo de autorización de SAP ………. 27

Capitulo III ……………………………………………………………………………… 29

Marco metodológico …………………………………………………………… 29

Revisión del modelo de seguridad anterior …………………………. 29

Disposición a usar para organizar la creación de roles …………… 30

Necesidades de cada cargo en cada modulo de la empresa .….. 31

Creación de los roles …………………………………………………. 32

Puesta a prueba de los roles ………………………………………… 33

Conclusiones …………………………………………………………………………. 36

Recomendaciones ……………………………………………………………………. 37

Referencias …………………………………………………………………………….. 38

3

LISTADO DE FIGURAS

Pág.

Figura 1. Papel de los roles …………………………………………………………… 22

Figura 2. Roles compuestos …………………………………………………………. 23

Figura 3. Pasos para administrar autorizaciones ………………………………….. 24

Figura 4. Diseño de roles ……………………………………………………………… 26

Figura 5. Pasos para el diseño de un modelo de autorizaciones …………………. 28

Figura 6. Transacciones repetidas en roles …………………………………………. 33

4

CAPITULO II

MARCO TEORICO

¿Qué es SAP?

SAP (Sistemas, Aplicaciones y Productos), con sede en Walldorf (Alemania),

es el primer proveedor de aplicaciones de software empresarial en el mundo. Como

empresa, comercializa un conjunto de aplicaciones de software para soluciones

integradas de negocios, entre ellas mySAP Business Suite, que provee soluciones

escalables que permiten mejorar continuamente, con más de 1.000 procesos de

negocio consideradas las mejores prácticas empresariales.

SAP es considerada como el tercer proveedor independiente de software del

mundo y el mayor fabricante europeo de software. Con 12 millones de usuarios,

100.600 instalaciones, y más de 1.500 socios, es la compañía más grande de

software Inter-empresa. A finales de 2005, SAP empleaba a 35.873 personas

(fuente empleados) en más de 50 países y sus ingresos anuales fueron de 8.513

millones de euros.

SAP fue fundada en 1972 en la ciudad de Mannheim, Alemania, por antiguos

empleados de IBM (Claus Wellenreuther, Hans-Werner Hector, Klaus Tschira,

Dietmar Hopp y Hasso Plattner) bajo el nombre de "SAP Systemanalyse und

Programmentwicklung". El nombre fue tomado de la división en la que trabajaban en

IBM. Después de haber dominado el mercado, la empresa afronta una mayor

competencia de Microsoft e IBM. En marzo de 2004 cambió su enfoque de negocio

en favor de crear la "plataforma" que desarrolla y utiliza, la nueva versión de su

software NetWeaver. Es en este punto donde SAP se encuentra enfrentado con

Microsoft e IBM, en lo que se conoce como "la guerra de las plataformas". Microsoft

5

ha desarrollado una plataforma basada en la web llamada .NET, mientras IBM ha

desarrollado otra llamada WebSphere.

A comienzos de 2004 sostuvo conversaciones con Microsoft sobre una

posible fusión. Las empresas dijeron que las conversaciones finalizaron sin un

acuerdo. Sin embargo, a comienzos del 2006 fue anunciada una alianza muy

importante entre SAP y Microsoft para integrar las aplicaciones ERP de SAP con las

de Office de Microsoft bajo el nombre de proyecto "Duet". La compra de SAP por

parte de Microsoft habría sido uno de los acuerdos más grandes en la historia de la

industria del software, dado el valor de mercado de la alemana, de más de 55.000

millones de euros (junio 2004).

SAP ha conquistado clientes de forma consistente para aumentar la cuota

del mercado global entre sus cuatro principales competidores a un 55% a fines de

2004, desde un 48% dos años antes. La participación combinada de Oracle y

PeopleSoft declinó de un 29% a un 23%.

SAP trabaja en el sector de software de planificación de recursos

empresariales (o ERP por las siglas en inglés de Enterprise Resource Planning). El

principal producto de la compañía es R/3, en el que la R significa procesamiento en

tiempo real y el número 3 se refiere a las tres capas de la arquitectura de proceso:

bases de datos, servidor de aplicaciones y cliente. El predecesor de R/3 fue R/2.

Otros productos de SAP son APO (Advanced Planner and Optimizer), BW (Business

Information Warehouse), Customer Relationship Management (CRM), SRM

(Supplier Relationship Management), Human Resource Management Systems

(EHRMS), Product Lifecycle Management (PLM), KW (Knowledge Warehouse) RE

(Real Estate), FI/CO (Financial Accounting/Controlling).

SAP también ofrece una nueva plataforma tecnológica denominada SAP

NetWeaver. Esta plataforma tecnológica convierte a SAP en un programa Web-

enabled, lo que significa que estaría totalmente preparado para trabajar con él

6

mediante la web, se puede trabajar con SAP mediante cualquier navegador de

internet si se tienen los componentes apropiados de SAP NetWeaver (SAP Portals).

Aunque sus principales aplicaciones están destinadas a grandes empresas, SAP

también se dirige a la pequeña y mediana empresa con productos como SAP

Business One y mySAP All-in-one.

SAP cuenta también con verticales y microverticales. Las verticales son

conocidas también como IS o Industry Solution y son SAP orientados a diversas

industrias, como por ejemplo periódicos, mineras, compañias de

telecomunicaciones. Las microverticales son SAP que atienden a industrias

específicas, como por ejemplo: empresas agroexportadoras, piscifactorías, etc. Las

Verticales son desarrolladas por SAP y las microverticales por los socios de SAP.

En muchos casos la adopción de SAP por las empresas se hace mediante la

contratación de consultoras especializadas

Características generales del SAP R/3

Las múltiples ventajas del software R/3 hace que se haya convertido en uno

de los estándares de hecho dentro de las grandes corporaciones. A continuación se

detallarán algunas de estas ventajas:

Exhaustivo: El sistema R/3 engloba la práctica totalidad de los procesos de

gestión de la empresa. En el siguiente apartado veremos detallados la cantidad

de módulos que incluye. Integrado Tal cantidad de módulos no aportarían

demasiado valor añadido a la empresa si no fuera por la integración. Las

interrelaciones estrechas entre módulos de SAP permiten tener disponible en

tiempo real y con exactitud los principales indicadores de gestión. Como ejemplo

ilustrativo diremos que una entrada de mercancías en R/3 puede producir una

actualización del inventario de almacén, un apunte contable en la contabilidad

7

financiera, una actualización del sistema de información del control de costes y

un aviso a producción de que hay nueva materia prima en almacén.

Abierto: Tecnológicamente hablando, SAP es un sistema abierto. Podemos

implantarlo en una variedad enorme de servidores diferentes y ejecutarlo sobre

sistemas operativos y sistemas de gestión de bases de datos de diversos

fabricantes. Esto nos permite escalar nuestro sistema adecuándolo a nuestro

tamaño de empresa y elegir a nuestros proveedores de hardware y software de

sistemas sin estar atados a ninguno. La arquitectura sigue varios de los

estándares de sistemas abiertos como POSIX o X/OPEN.

Flexible: Podemos utilizar junto con SAP R/3 otros productos de software de

otros fabricantes, existen interfases con productos de Microsoft, Lotus u Oracle

entre otros. SAP posee también un amplio menú de parametrización que nos

permite adecuar el sistema a nuestras necesidades, así como un completo

sistema de desarrollo para crear nuestros nuevos programas y que mantengan

la integración con el estándar.

Global: El sistema R/3 soporta su utilización en varios idiomas, la contabilización

de documentos en cualquier moneda y tiene recogidas las particularidades

fiscales y de gestión de recursos humanos de un gran número de países. Esta

globalidad es el argumento de mayor peso en la decisión de una multinacional a

la hora de adquirir SAP.

Actualizado: Dos de los grandes problemas de los departamentos de TI a finales

de los 90 han sido el efecto 2000 y la entrada en vigor del euro. El software SAP

R/3 tiene contemplados y solucionados estos problemas. Además, la constante

investigación llevada a cabo por SAP hace que su software este al día

incluyendo la última tecnologías disponibles como EDI, Data Warehouse,

clientes Java, comercio electrónico, etc.

8

Módulos de operación Como se menciona anteriormente el software de SAP es un compendio realmente

exhaustivo de aplicaciones de gestión. A cada uno de los componentes que sirven

para gestionar cada una de las áreas de la empresa se les denomina módulos y se

les nombra con dos letras correspondientes a las iniciales del nombre en inglés. Los

módulos principales (finanzas, logística y recursos humanos) se componen a su vez

de subm´odulos. Estos son los principales módulos y sus características:

Gestión Financiera. FI Financial Accounting: Reúne todos los datos de la

empresa relevantes para la contabilidad financiera. Recibe todas las

imputaciones contables del resto de módulos y las centraliza en una base de

datos actualizada en tiempo real. Esto nos permite conocer el estado

contable de nuestra compañía (balance y cuenta de pérdidas y ganancias)

en todo momento. Los subm´odulos que la componen son los siguientes.

o Control de Gestión CO Controlling: La contabilidad financiera no

siempre puede proporcionar información desde todos los puntos de

vista que una gestión eficaz de costes requiere y es, en este punto,

donde actúa el módulo CO. Partiendo de los datos de FI, la

contabilidad analítica nos muestra los ingresos, gastos e inversiones

desde vistas diferentes. Si juntamos esto con el sistema de

planificación y previsión de costes obtendremos un sistema de

información completo con las comparativas del plan contra el real que

nos permiten saber si nos ajustamos al presupuesto y el porqué.

o Tesorería TR Treasury: Representa la solución completa para una

gestión económico financiera eficaz. Nos permite asegurar la liquidez

de la empresa en todo momento y estructurar los activos financieros

de la manera más lucrativa posible.

o Activos Fijos AM Asset Management: Nos permite controlar el ciclo

de vida completo de nuestro inmovilizado, desde la inversión inicial

9

en activos fijos en curso, pasando por la contabilización de la manera

más conveniente, la puesta en explotación de dicho inmovilizado y la

enajenación del mismo. Existe otro pequeño submódulo denominado

gestión de inversiones (IM Investment Management) que esta muy

relacionado con AM.

Logística LO Logistics: Bajo este epígrafe se engloba la gestión de todo el

ciclo de vida de los productos de una empresa, desde la compra y

almacenaje de materia prima, pasando por la fabricación del producto hasta

su venta y distribución. Es el módulo más grande de todos ellos y el que más

componentes tiene. Describimos a continuación los más usados aunque

existen otros menos conocidos como la gestión del servicio al cliente, la

gestión de proyectos y la gestión de la calidad de productos.

o Gestión de materiales. MM Materials Management: Optimiza todos

los procesos de compra a través de varias funciones disponibles. Por

un lado permite automatizar las evaluaciones de proveedores

mediante la entrada de ofertas y el mantenimiento de registros info.

También podemos reducir los costes de aprovisionamiento y

almacenamiento, gracias a la precisión de la gestión de stocks y de

almacenes. Este es uno de los puntos donde mías claramente poder

apreciar el retorno de la inversión porque los costes de almacenaje

es una de las principales preocupaciones de las empresas en la

actualidad. Un completo sistema de verificación de facturas nos

proporciona la integración necesaria con los módulos contables FI,

CO y TR para tener la información actualizada en tiempo real.

o Planificación de la producción. PP Production Planning: Proporciona

procesos completos para todos los tipos de fabricación: fabricación

repetitiva, fabricación contra pedido, fabricación contra catalogo,

fabricación por procesos, fabricación por lotes y en serie, hasta la

10

gestión integrada de cadenas de suministro con funciones MRP. La

integración con MM puede provocar la solicitud de necesidades

automática al lanzar la planificación de requerimientos de material.

o Mantenimiento de Planta. PM Plant Manteinance: Para una empresa

industrial es fundamental el poder garantizar la disponibilidad de la

planta y sus herramientas de producción y de esto se encarga el

módulo de PM. Aplicaciones como la planificación de las revisiones,

la programación de órdenes de mantenimiento, la gestión de

notificaciones de aprobación nos aseguran un rendimiento óptimo de

nuestra fábrica. Integrando todo esto con PP (podemos modificar las

órdenes de producción en función de la disponibilidad de la cadena

de producción), con HR (calendarios laborales, turnos, etc) y con MM

(creando solicitudes de necesidad de repuestos, por ejemplo)

tenemos controlada una pieza vital de la empresa.

o Ventas y Distribución. SD Sales and Distribution: La cambiante

realidad de los mercados actuales es un reto para cualquier

programa de gestión de ventas. SD es lo suficientemente flexible

como para poder adecuarnos a precios, condiciones de entrega,

descuentos, comisiones y ofertas que a veces cambian a diario.

Informar adecuadamente a los módulos financieros del estado de

nuestras ventas es una labor imprescindible para poder conocer el

estado económico y financiero actualizado de la empresa.

Recursos Humanos. HR Human Resources: Tradicionalmente, la gestión de

recursos humanos se ha considerado una área aislada del resto de sistemas

de gestión de la empresa. SAP, sin embargo, ha llevado su máxima de

integración hasta el punto de incluir la gestión de turnos y plantillas, los

horarios de fábricas, y el absentismo laboral en los procesos de negocio de

la fabricación y el mantemiento de planta entre otros. Los dos submódulos

11

principales son PA y PD aunque también existen soluciones menos usadas

como la gestión de candidatos, el calendario de fábrica y la gestión de viajes

y gastos.

o Nómina. PA Payroll Accounting: Mantiene todos los datos de los

empleados en unas estructuras denominadas infotipos que nos

permiten calcular el pago de la nómina y contabilizarla tanto en FI

como CO de manera automática. Existen infotipos para todas las

características de un empleado, como datos personales, salario

bruto, datos familiares, turnos, retenes, retenciones fiscales. . . Este

submódulo es posiblemente el más específico de cada país debido a

que las leyes que rigen las relaciones laborales difieren mucho de

unos países a otros. Es por ello que SAP proporciona unos

programas diferentes para cada país y un servicio de actualización

para poder estar al día con los cambios que se producen en materia

de legislación laboral (aparición de nuevas modalidades de

contratación, cambios en la normativa fiscal, etc).

o Estructura Organizativa. PD Personnel Development: Este

submódulo se encarga de gestionar la estructura de la empresa

organizando la misma en departamentos, áreas, grupos de trabajo,

etc. Permite la definición de tareas de puestos de trabajo y la

reorganización de los mismos.

12

BASES TEÓRICAS

¿Qué son las autorizaciones? Una autorización es un artificio lógico que se usa para controlar acceso por

niveles a las diferentes funciones y/o transacciones del sistema SAP. En la versión

nueva de SAP el término rol es el centro del concepto de autorización. Iremos

aclarando paso a paso desde el diseño hasta la implementación del modelo de

autorizaciones.

¿Por qué se necesitan autorizaciones? Permiten proteger la información de la empresa, hay mejoras en la relación

costo-beneficio y se evita la obstrucción en procesos de la empresa.

Protección de datos sensibles

o Una empresa debe cumplir determinadas exigencias legales en función

del país en el que lleve a cabo las operaciones. Se deben tener en

cuenta las leyes específicas como la de protección de los empleados.

o Una empresa debe ser capaz de proteger y cumplir los acuerdos

establecidos con los socios y vendedores.

o Una empresa debe publicar y aplicar políticas sobre seguridad, al objeto

de establecer y mantener un entorno seguro.

Relación coste-beneficio

o Una empresa debería concentrar los costes de seguridad en áreas en las

que pueda obtenerse un beneficio claro. No es necesario invertir tiempo y

dinero en garantizar los activos de una empresa que puedan sustituirse

con facilidad a un menor coste en caso de siniestro.

13

o Es imposible garantizar una seguridad total ante todas las amenazas

potenciales. Por lo tanto, una empresa debe ser capaz de sopesar los

extraordinarios riesgos de una amenaza y los costes de un sistema de

seguridad.

Obstrucción del proceso comercial

o Un entorno seguro debería ser lo bastante transparente como para no

obstruir los procesos comerciales de una empresa.

La asignación de autorizaciones debe realizarse en forma estructurada,

usando un número mínimo de roles. Cuándo se diseña un modelo de seguridad

primero se debe determinar ¿qué? y ¿contra qué? se quiere proteger. Cuándo se

quiera proteger el sistema SAP la seguridad debe estar implementada en todos los

niveles, ya que la seguridad total depende del nivel más bajo. Para trabajar en el

sistema SAP, los usuarios necesitan un ID (login) que los haga único. Se debe crear

un registro maestro de usuario (RMU) en el sistema por cada usuario. Este RMU

contiene también la contraseña que debe introducir el usuario para poder acceder al

sistema.

Para proteger la información de la empresa y las funciones del sistema de

accesos desautorizados, SAP utiliza una técnica de chequeo de autorizaciones.

Entonces para que el usuario pueda visualizar alguna información o ejecutar alguna

función del sistema necesita la autorización apropiada. Las autorizaciones son

asignadas usando perfiles a través de roles, los cuáles están incorporados en el

RMU.

Un rol es un grupo de actividades realizadas en un área de la empresa. Un

usuario puede estar en varios roles. Un rol puede estar inmerso en varias áreas de

la empresa, así como también un área determinada puede necesitar varios roles.

Las áreas de trabajo son conjuntos de actividades realizadas por uno o más

empleados en sus respectivos puestos (ver figura 1).

14

ROL 1 ROL 2

Usuario 1 Usuario 3

Finanzas RRHH Ventas

ROL 3

Usuario 2

Figura 1. Papel de los roles.

Como se menciono antes, en la versión 6.0, existe la posibilidad de diseñar y

usar eficientemente roles simples, compuestos o derivados, depende de la situación

específica de la empresa.

Un rol simple está formado por los siguientes componentes:

Menú: Las transacciones, reportes, links, etc., de un rol están todas en un

menú, al cual los usuarios pertenecientes a dicho rol tienen acceso.

Autorizaciones: Éstas definen el acceso a las funciones e información de la

empresa.

Usuarios: Para garantizar el acceso de un usuario a un rol, primero debe

agregarse el usuario al rol.

15

Un rol compuesto se forma a partir de otros roles. Es decir, varios roles simples

forman uno compuesto (ver figura 2). Por lo tanto, los roles compuestos heredan

transacciones, menús y usuarios de los roles simples que lo forman.

ROL

SIMPLE 1

Rol compuesto 1

ROL

SIMPLE 2

ROL

SIMPLE 3

Rol compuesto 2

ROL

SIMPLE 1

ROL

SIMPLE 1

Rol compuesto 1

ROL

SIMPLE 2

ROL

SIMPLE 2

ROL

SIMPLE 3

ROL

SIMPLE 3

Rol compuesto 2

Figura 2. Roles compuestos

SAP entrega un gran número de roles predeterminados con el sistema. Los

administradores pueden usar esos roles como plantillas y moldearlos según los

requerimientos de la empresa. Cuándo se crea un rol, el administrador de sistema

especifica las funciones requeridas y sus descripciones. El texto descriptivo puede

ser cambiado, y es por lo tanto definible libremente. Una vez que un usuario esta

asignado a un rol particular (con menú) y entra al sistema se muestra en pantalla el

menú predeterminado por el rol. El menú esta basado en las actividades asignadas.

Además, los usuarios pueden elegir sus favoritos.

Desarrollando un modelo de autorizaciones El procedimiento usado se basa en los principios del método de

implementación de SAP. Muchas compañías consultoras usan un modelo similar,

usualmente con su nombre. Cuándo se combinan, los pasos individuales de este

método, se asegura una implementación rápida y eficiente del sistema SAP. Al crear

un modelo de autorización se debe planear e implementar paso a paso usando un

16

plan de trabajo. El método SAP consiste en separar el proyecto en cinco pasos o

fases:

1. Preparación del proyecto: Inclusión de todo el personal relevante para la

realización y la formación de los equipos de trabajo internos y externos.

2. Business blueprint: Los requerimientos de la empresa son determinados.

Todos los procesos son descritos y analizados aquí.

3. Implementación: Configuración y ajuste del sistema SAP. Los procesos

creados y descritos en el paso anterior son el punto de partida para la

implementación de los roles.

4. Preparación final: Prueba de todas las interfaces, entrenamiento de usuarios,

migración de la información al sistema SAP.

5. Go Live & Support: Inicio de la operación productiva de SAP. Especificación

de procedimientos y medidas para la comprobación de los beneficios de la

invertir en el sistema SAP.

Determinar usuarios y la estrategia para administrar las autorizaciones

Análisis y concepción

Implemen- tación

Pruebas de calidad Preparación Cutover

Figura 3. Pasos para administrar autorizaciones

• Un modelo de autorización puede ser implementado en 5 pasos.

o Cada paso compila diferentes actividades

o Hay una persona responsable por actividad.

Para satisfacer cierta actividad, el empleado responsable debe usar varias

aplicaciones. Las transacciones y reportes usados en una actividad de la empresa

pueden ser combinadas en los roles. Es importante que el usuario sólo pueda

17

procesar aquellas tareas que este autorizado a realizar, y que esté advertido de no

modificar la información en áreas del sistema que estén fuera de su competencia.

Dado que los componentes de SAP usan autorizaciones para controlar el acceso a

cada función, los administradores asignarán a un rol, solamente las autorizaciones

necesarias para llevar a cabo todas sus actividades.

1. Preparación: identificar las áreas de la empresa afectadas y sus requerimientos

especiales de seguridad, por ejemplo los mecanismos de control seleccionados,

que pueden variar de un área a otra. Normalmente los requerimientos del

departamento de Recursos Humanos es más demandante que otros

departamentos. Por lo tanto primero se debe determinar el nivel de seguridad

deseado.

2. Análisis y concepción: Se realizan las especificaciones del rol y del modelo de

autorización:

a. Identificar los roles requeridos. Determinar las tareas del perfil,

basándose en los resultados del proceso de análisis de la empresa.

Chequear si los roles plantilla pueden ser usados.

b. Especificar las funciones relevante de los roles (transacciones, reportes,

Web Links, etc.). Hacer cualquier ajuste requerido si los roles plantilla se

están usando.

c. Identificar los roles individuales y compuestos si se requieren, para la

implementación de los roles y el modelo de autorización.

Se pueden moldear los roles de forma individual, que contendrá todas las

funciones que requiera. También se pueden moldear roles compuestos, que

consiste en la unión de roles individuales y derivados. En este caso los roles

individuales y derivados representan bloques de actividades, esto es, grupos con

funciones relacionadas. La ventaja de esta técnica es que el acceso múltiple a

transacciones usadas en muchos roles individuales es evadido.

18

Usuario

Encargado de cuentas por

pagar

Análisis del balance Mantenimiento de documentos

Línea de artículos de vendedor

Mostrar balance del vendedor

Mantener documentos

Contable de cuentas por

pagar

Cambiar los documentos

Roles compuestos

Roles individuales

Actividades, reportes,

transacciones, etc.

Figura 4. Diseño de roles

3. Implementación: En este paso se crean los roles:

a. Crear los roles según las restricciones y funciones necesarias obtenidas

en el proceso de análisis.

b. Se crean los roles derivados tomando como base los roles individuales

creados.

c. Finalmente los roles compuestos son creados a partir de los roles

individuales y compuestos.

4. Pruebas de calidad: en esta parte se verifica cada una de las autorizaciones. se

hacen pruebas estándares para certificar el buen funcionamiento del modelo de

autorización creado, confirmando su consistencia con los resultados esperados.

5. Cutover: Antes de crear los usuarios productivos se deben generar los registros

maestros de usuario. Para simplificar la creación de los RMU individuales,

primero se crean registros modelos. Estos modelos son usados como plantillas

para los registros de los usuarios productivos. Luego se crean los usuarios,

19

tomando como base el RMU plantilla y se personaliza de acuerdo con las

necesidades del usuario.

Elementos y terminologías básicas del modelo de autorización de SAP

• Clase de objeto de autorización: Es un grupo lógico de objetos.

• Objeto de autorización: Grupos de uno a diez campos de autorización. Estos

campos son verificados simultáneamente.

• Campo de autorización: Es la unidad mas pequeña a la cual se le hace la

verificación.

• Autorización: Es una instancia de un objeto de autorización, que es, una

combinación de valores permitidos para cada campo de autorización.

• Perfil de autorización: Contiene instancias (autorizaciones) de diferentes

objetos de autorizaciones.

• Rol: Es generado usando el generador de perfiles (PFCG), y permite la

generación automática de un perfil de autorización. Un rol describe todas las

actividades de un usuario del sistema SAP.

• Registro maestro de usuario: Usado para registrarse en el sistema SAP y

garantizar acceso restringido a las funciones y objetos basado en perfiles de

autorización.

20

Usuarios

Figura 5. Elementos básicos de un modelo de autorización

Roles

Perfil de autorización

Autorización

Objeto de autorización

Clase de objeto de autorización

21

CAPITULO III

MARCO METODOLÓGICO

Para asegurar que el diseño del modelo de seguridad de Orinoco Iron y

Venprecar sea funcional, eficiente, óptimo y confiable, se siguieron varios pasos:

1. Revisión del modelo de seguridad anterior

Dado que ya existía un modelo de seguridad diseñado para la versión anterior

de SAP, este fue el punto de partida. Se usó como un esqueleto para el modelo

nuevo ya que contenía las autorizaciones que necesitaba cada usuario en los

diferentes cargos de los distintos módulos de ambas empresas. Pero cuándo se

encara la versión 6 desde el punto de vista de la seguridad, tomando como premisa

el modelo de seguridad de la versión 4.5b, se notan algunos detalles:

Algunas de las transacciones que estaban en la versión anterior no se

encuentran en la versión nueva, es decir, ya a no existen.

Algunas de las transacciones que estaban en la versión anterior no se

encuentran en el menú de transacciones de la versión nueva, pero aún

pueden ser ejecutables desde la línea de comandos, es decir, existen

pero no están en el nuevo menú.

Algunas de las transacciones que estaban en la versión anterior

cambiaron de nombre, independientemente de la razón, ahora en la

nueva versión la misma transacción se llama de otra manera.

22

Muchas de las transacciones de la versión anterior existen en la versión

nueva, pero algunas divergen en la verificación de objetos para su

ejecución, es decir, si una transacción en la versión anterior verificaba un

objeto de autorización, ahora puede que verifique dos o más, y no

necesariamente incluye el que verificaba antes.

Hay un número muy grande de roles simples, dado que la

implementación de roles compuestos no era posible en la versión

anterior.

Hay transacciones repetidas en muchos roles, esto se debe igualmente a

que no existía la posibilidad de diseñar roles compuestos.

Entonces hay que tomar en cuenta todos estos detalles, se hizo un estudio

de cada uno de los casos donde las transacciones varían y se documentó. Para de

esta manera tomar todo esto en cuenta a la hora de crear el modelo de seguridad.

Además, la herramienta para administrar las autorizaciones mejoró notablemente,

entonces, se puede mejorar el modelo de seguridad anterior y adaptarlo a la nueva

versión, aprovechando las nuevas características de la misma.

2. Selección de la disposición a utilizar para organizar la creación de roles

Para el diseño de los roles del modelo de seguridad se hace un enfoque en

los cargos que existen en cada módulo de la empresa, es decir se crearán roles

basándose en las necesidades de cada cargo específico. Para esto se uso

disposición vertical (por cargos). Esto permite agrupar todas las transacciones que

necesite el usuario de un cargo específico en un único rol. Esto acarrea un

problema. Es muy probable que varios cargos en la empresa compartan las mismas

transacciones, es decir, un usuario de “compras” puede verificar cuanta

disponibilidad hay en inventario de un material específico, pero un usuario de

23

“recursos humanos” también podría verificar lo mismo para saber cuando hacer un

pedido. Esto implicaría que una transacción se repitiera en muchos cargos.

Si se crearan los roles de esta manera sería eficiente, confiable, funcional

pero no óptimo.

Para evitar esto se unió la disposición vertical con la disposición horizontal,

que permite agrupar transacciones por procesos empresariales. Es decir si varios

cargos necesitan la misma transacción se colocan en un rol simple, y los roles

donde esta transacción existía originalmente serán roles compuestos que estarán

formados por las transacciones únicas de dicho cargo más los roles simples que

contienen las transacciones que comparte con uno o más roles.

De esta manera se obtiene un diseño óptimo, por cargos y por procesos,

minimizando al máximo el número de roles, obteniendo una mejor organización,

facilitando la labor del administrador de autorizaciones y sobre todo apegándose a

las normativas SAP.

3. Estudio de las necesidades de cada cargo en cada módulo de la empresa

A pesar de que en el modelo anterior ya se conocen las transacciones que se

necesitaban en cada puesto, como ya se mencionó, algunas de las transacciones

son nuevas, por lo tanto no estaban contempladas. Es necesario hacer un estudio

de cuáles son las transacciones nuevas que se necesitan en cada cargo en cada

módulo de la empresa y ubicarlas en el lugar correcto (en el cargo o proceso

empresarial donde deba estar).

También se requiere realizar el estudio de cuáles son las transacciones que

cambiaron de nombre, para eliminar las anteriores y colocar las nuevas. Se debe

conocer los objetos de autorización nuevos que verifican algunas transacciones ya

existentes o nuevas y saber que valores colocar en los campos de autorización

24

dependiendo del cargo que se este tratando. Debido a que algunos cargos han sido

modificados, y realizan actividades que antes no hacían o dejaron de hacer tareas

que antes hacían, el rol para ese cargo debe cambiar. Esto requiere una serie de

entrevistas, análisis del modelo de seguridad anterior, revisión del organigrama

vigente, etc.

4. Creación de los roles

Se crearon en un rol simple las transacciones específicas que son

necesarias en cada cargo. Pero cómo ya se dijo algunas transacciones se

repetían en muchos roles. Por esto se recurre a la simplificación de

transacciones por procesos, de esta manera se obtiene un diseño óptimo y se

obtiene un número mínimo de roles.

Debido a que una misma transacción puede tener valores diferentes en los

campos de autorización que inciden en los objetos de autorización que verifica

una transacción, aunque esta se repita en varios roles, seguirá siendo única

para ese rol (ver figura 6). Para poder simplificar los roles por procesos

(disposición horizontal), los roles dónde se repita una transacción debe verificar

los mismos campos de autorización que inciden en los objetos de autorización

que verifica para de esta manera no darle a un usuario más permisos de lo que

necesita.

Para hacer esta comparación existe una herramienta de consulta que viene

con el sistema SAP. Se pueden comparar roles para saber que objetos son

iguales, cuales difieren en los valores de sus campos, y cuales existen en un rol

y en otro no. Esta tarea no es tan sencilla como parece, dado que la

comparación se hace en base a los objetos y un objeto de autorización es

verificado por varias transacciones que pueden estar en el mismo rol. Entonces

si dos roles tienen el mismo objeto pero con diferente valor en sus campos no se

25

puede saber a ciencia cierta que transacción esta verificando ese objeto.

Entonces no podemos decir cuál es la transacción común en los roles.

Rol 1

Transacción

A

Transacción

B

Objeto 1 Objeto 2

Campo 1 = “10” Campo X= “20”

Rol 2

Transacción

A

Transacción

C

Objeto 1 Objeto 3

Campo 1 = “30” Campo Y= “50”

Rol 1Rol 1

Transacción

A

Transacción

A

Transacción

B

Transacción

B

Objeto 1Objeto 1 Objeto 2Objeto 2

Campo 1 = “10”Campo 1 = “10” Campo X= “20”Campo X= “20”

Rol 2Rol 2

Transacción

A

Transacción

A

Transacción

C

Transacción

C

Objeto 1Objeto 1 Objeto 3Objeto 3

Campo 1 = “30”Campo 1 = “30” Campo Y= “50”Campo Y= “50”

Figura 6. Transacciones repetidas en roles

Para saber específicamente cuál transacción es la que se esta repitiendo se

necesita saber que transacciones de las que están en los roles verifican dicho

objeto de autorización. Luego se debe hacer una revisión un poco más profunda

para saber cuáles son los valores actuales del objeto que esta siendo verificado

por las transacciones candidatas. Si estos valores actuales (valores de los

campos de autorización incidentes en el objeto de autorización) son iguales en

ambos roles significa que la transacción esta repetida exactamente igual y se

puede decir que es común para ambos roles, sino se dice que la transacción

esta repetida pero con valores diferentes, y no es común para ambos roles.

26

Esta verificación es un trabajo manual, ya que la herramienta no hace

comparaciones de roles a nivel de transacciones sino a nivel de objetos de

autorización. Por lo tanto, como un rol tiene muchas transacciones y una

transacción verifica muchos objetos, y a su vez, un objeto tiene de uno a diez

campos de autorización, hacer esta verificación manualmente es un trabajo muy

tedioso y muy largo. Luego de hacer un estudio de posibilidades se tomaron en

cuenta dos opciones: desarrollar un programa local dónde la comparación de

roles se hiciera a nivel de transacción, o crear una base de datos con roles,

transacciones, objetos que verifica cada transacción, y valores actuales de los

campos de cada objeto con el fin de crear una consulta que me pueda traer las

transacciones repetidas, y en que roles se repiten.

Se optó por la segunda opción, lo cual implica un trabajo grande al momento

de llenar la base de datos, pero luego se hace fácil a la hora de hacer la

consulta. De esta manera se pudo combinar las dos disposiciones para obtener

un modelo de seguridad óptimo.

5. Puesta a prueba de los roles creados

Luego de crear los roles se debe verificar que los resultados obtenidos hayan

sido los esperados. Comprobando de esta manera que el trabajo se haya hecho

correctamente. Se necesita que los usuarios de cada módulo hagan pruebas con su

nuevo perfil. Deberán realizar todas las actividades correspondientes al cargo que

ejecuta y de esta manera ajustar los roles si hace falta algún cambio, si falta algún

rol, alguna transacción o objeto de autorización, si un campo de autorización tiene

un valor erróneo, etc. Esto con el fin de darle al usuario sólo lo que necesita para

realizar sus actividades, ni más ni menos.

Luego que las pruebas están completas y que las correcciones están hechas. El

modelo de autorizaciones está terminado y puede ser implementado en producción.

Aunque esto no implica que deba dejarse de lado, se tiene que seguir un estudio

27

constante en dicho modelo ya que no es algo estático, más bien es dinámico y

siempre esta cambiando. Si se diseña siguiendo un procedimiento adecuado la

alteración o modificación del modelo de autorizaciones es sencilla.

28

CONCLUSIONES

El modelo de autorizaciones del sistema SAP es un pilar importante para su

correcta implementación. Sin esto el sistema no sería confiable ya que cualquier

usuario pudiera crear solicitudes de pedido, liberarlas, ver datos personales de

otros empleados, actualizar tablas maestras, borrar datos de estas tablas, en

resumen, un sin fin de actividades que harían que el sistema fuera muy poco

confiable. El modelo de seguridad debe abarcar toda la empresa en su totalidad, de otra

manera seguiría siendo un sistema poco confiable.

El modelo de seguridad debe poder ser entendido y alterable por un

administrador de autorizaciones cualquiera que este capacitado. El modelo de seguridad no debe ser diseñado sin la ayuda de los usuarios

funcionales de cada modulo. El modelo de seguridad es un factor cambiante en el sistema.

29

RECOMENDACIONES

Nunca debe instalarse el sistema SAP en una empresa sin tener un sistema de

seguridad adecuado, ya que afectaría la producción de la misma. La seguridad del sistema debe implementarse a todos los nivele, ya que la

seguridad total depende del nivel más bajo. Se debe documentar todo el proceso de inicio a fin, para facilitar su

entendimiento. Los usuarios funcionales de cada modulo deben conocer las transacciones del

sistema que deban usar para llevar a cabo sus tareas. Se debe mantener un estudio constante del modelo de seguridad ya que no es

algo estático sino dinámico, varía en el tiempo.

30

REFERENCIAS

Enlaces WEB

http://www.mundosap.com

Bibliografía

SAP authorization concept ADM940 (2003). SAP R/3 Enterprise. SAP introduction (2003). SAP R/3 Enterprise. SAP Advanced R/3 system administration BC305 (2003). SAP R/3

Enterprise.

31