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
 Finanzas RRHH Ventas

ROL 1 ROL 2 ROL 3

Usuario 1 Usuario 2 Usuario 3

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 ROL ROL

SIMPLE 1 SIMPLE 2 SIMPLE 3

Rol compuesto 1 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 Implemen- Pruebas Cutover

Preparación tación de calidad
concepción

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 Contable de
Roles compuestos cuentas por cuentas por
pagar pagar

Roles individuales Análisis del balance Mantenimiento de documentos

Actividades, Línea de Mostrar Mantener Cambiar los

reportes, artículos de balance del documentos documentos
transacciones, etc. vendedor vendedor

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

Roles

Perfil de
autorización

Autorización

Objeto de
autorización

Clase de objeto
de autorización

Figura 5. Elementos básicos de un modelo 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 Rol 2

Transacción Transacción Transacción Transacción

A B A C

Objeto 1 Objeto 2 Objeto 1 Objeto 3

Campo 1 = “10” Campo X= “20” Campo 1 = “30” 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