{"id":214,"date":"2024-10-14T16:00:00","date_gmt":"2024-10-14T16:00:00","guid":{"rendered":"https:\/\/xamai.com\/roles-y-perfiles-sap\/"},"modified":"2026-05-19T12:32:06","modified_gmt":"2026-05-19T18:32:06","slug":"roles-y-perfiles-sap","status":"publish","type":"post","link":"https:\/\/www.xamai.com\/es\/blog\/roles-y-perfiles-sap","title":{"rendered":"Roles y Perfiles SAP | \u00bfQu\u00e9 es un Rol y un Perfil?"},"content":{"rendered":"<p><em>Entendiendo c\u00f3mo funcionan los roles y perfiles dentro de SAP ERP<\/em><\/p>\n<p><!--more--><\/p>\n<p>En Xamai, queremos hablar acerca de los roles y perfiles en SAP que son t\u00e9rminos que se utilizan a menudo, de manera err\u00f3nea pues no son sin\u00f3nimos. Hoy vamos a explicar a detalle qu\u00e9 es un rol y un perfil y todos los elementos correspondientes a ellos para que tengas total conocimiento de su funci\u00f3n.<\/p>\n<h2>\u00bfCu\u00e1les son los roles y perfiles de SAP?<\/h2>\n<p>Para entender mejor qu\u00e9 son, debemos hablar un poco sobre las primeras versiones del sistema SAP, ya que en aquel entonces no exist\u00edan roles, solo perfiles.&nbsp;<\/p>\n<p>Los perfiles se refieren a los elementos que permiten asignar autorizaciones a los usuarios que utilizan el sistema SAP. A trav\u00e9s de ellos es posible habilitar a los usuarios para que utilicen el sistema.&nbsp;<\/p>\n<p>El concepto de rol ha sido introducido m\u00e1s recientemente que el de perfil o perfil de autorizaci\u00f3n.<br \/>Pero intentemos dar una definici\u00f3n y luego desarrollarla:<\/p>\n<p>Un perfil es un contenedor de autorizaciones y un rol es un contenedor que est\u00e1 conformado de tres partes: men\u00fa, autorizaciones y asignaci\u00f3n de usuarios. Quiz\u00e1s esto a\u00fan no est\u00e9 del todo claro.<\/p>\n<p>Dec\u00edamos que antes, para asignar autorizaciones a los usuarios, s\u00f3lo exist\u00edan los perfiles. Eso es cierto. Para que un usuario pudiera ejecutar, por ejemplo, una solicitud de compra o un pedido, era necesario identificar todos los objetos de autorizaci\u00f3n requeridos para que estos aspectos del proceso funcionaran.&nbsp;<\/p>\n<p>Todos estos objetos ten\u00edan que ser colocados con precisi\u00f3n en un perfil y ese perfil ten\u00eda que ser luego asignado al usuario o usuarios.<\/p>\n<p>Esto era muy laborioso y requer\u00eda mucho tiempo, sobre todo porque hay m\u00e1s de 3000 objetos de autorizaci\u00f3n definidos en un sistema SAP. El proceso se llev\u00f3 a cabo mediante ensayo y error.<\/p>\n<p>&nbsp;Los roles, entonces, tienen la capacidad de simplificar la gesti\u00f3n de autorizaciones de SAP, introduciendo as\u00ed el RBAC (Role Based Access Control) o Control de acceso basado en roles.<\/p>\n<h2>&nbsp;\u00bfC\u00f3mo se realiza este proceso?<\/h2>\n<p>Anteriormente a trav\u00e9s de perfiles, el responsable de seguridad ten\u00eda que conocer todos los objetos a habilitar, hoy, a trav\u00e9s de roles es posible asignar la transacci\u00f3n que una persona tendr\u00e1.<\/p>\n<p>Esto significa que el rol (a trav\u00e9s de la transacci\u00f3n PFCG &#8211; Generador de perfiles) permitir\u00e1 recuperar toda la informaci\u00f3n necesaria (desde el punto de vista de las autorizaciones) para que el usuario, una vez asignado el rol, pueda trabajar.<\/p>\n<p>Los perfiles y los roles no deben utilizarse juntos. Por lo tanto, los perfiles son un legado del pasado (a\u00fan activos en el sistema) pero &#8220;ocultos&#8221; a trav\u00e9s de la gesti\u00f3n de roles. Por lo tanto, no deben utilizarse. \u00a1Solo deben utilizarse los roles!<\/p>\n<p>&nbsp;<\/p>\n<h2><\/h2>\n<h2>\u00bfLos roles de SAP facilitan la gesti\u00f3n de autorizaciones?<\/h2>\n<p>S\u00ed. Aunque depende de c\u00f3mo las estructures. En el entorno de autorizaci\u00f3n de SAP, realmente es as\u00ed: cualquiera puede hacer que las cosas funcionen f\u00e1cilmente tratando de definir un concepto de autorizaci\u00f3n.<\/p>\n<p>Pero una cosa es hacer que funcionen y otra muy distinta es hacer que funcionen como deber\u00edan y, sobre todo, gestionarlos a lo largo del tiempo de forma adecuada.<\/p>\n<p>Es com\u00fan, de hecho, encontrar situaciones de modelos de autorizaci\u00f3n definidos al principio del proyecto y luego superpuestos, modificados sin mucha l\u00f3gica por varias manos a lo largo del tiempo, hasta el punto en que debes revisar todo.<\/p>\n<h2>\u00bfQu\u00e9 pasa cuando se tiene acceso a los roles y administrador de perfiles?<\/h2>\n<p>Los roles y autorizaciones permiten a los usuarios acceder a SAP Standard y a transacciones personalizadas de forma segura para la empresa.<\/p>\n<p>No hay opci\u00f3n a riesgos porque SAP proporciona un conjunto determinado de roles est\u00e1ndar gen\u00e9ricos para diferentes m\u00f3dulos y diferentes escenarios dependiendo de lo que pase en la empresa.<\/p>\n<p>Tambi\u00e9n podemos definir roles en funci\u00f3n del escenario del proyecto teniendo en cuenta lo siguiente:<\/p>\n<h3><span style=\"color: #ee7812;\">Existen dos tipos de roles:<\/span><\/h3>\n<p><span style=\"font-weight: bold;\">Roles maestros: <\/span>con transacciones, objetos de autorizaci\u00f3n y con toda la gesti\u00f3n a nivel organizacional.<\/p>\n<p><span style=\"font-weight: bold;\">Roles derivados:<\/span> con gesti\u00f3n a nivel organizacional y objetos de transacciones y autorizaci\u00f3n copiados del rol maestro.<\/p>\n<h2>Componentes que tiene un Rol<\/h2>\n<p>Un rol maestro o un rol derivado tiene los siguientes componentes en su interior:<\/p>\n<ul>\n<li>C\u00f3digos de transacci\u00f3n<\/li>\n<li>Perfil<\/li>\n<li>Objetos de autorizaci\u00f3n<\/li>\n<li>Nivel de organizaci\u00f3n<\/li>\n<\/ul>\n<h3><span style=\"color: #ee7812;\">C\u00f3digos de transacci\u00f3n<\/span><\/h3>\n<p>Los c\u00f3digos de transacci\u00f3n (T-Codes) son comandos que permiten acceder r\u00e1pidamente a diferentes funcionalidades dentro del sistema SAP. Un rol contiene los T-Codes que el usuario podr\u00e1 ejecutar, definiendo as\u00ed las transacciones que est\u00e1n autorizados a utilizar.<\/p>\n<h3><span style=\"color: #ee7812;\">Perfiles<\/span><\/h3>\n<p>El perfil es una estructura que agrupa las autorizaciones de un rol. Cada rol tiene un perfil asociado que recoge las definiciones de acceso del usuario. Estos perfiles se crean autom\u00e1ticamente cuando se generan roles, y son los que realmente se asignan a los usuarios para otorgar los permisos.<\/p>\n<h3><span style=\"color: #ee7812;\">Objetos de autorizaci\u00f3n<\/span><\/h3>\n<p>Los objetos de autorizaci\u00f3n son los elementos que definen qu\u00e9 datos espec\u00edficos puede acceder o modificar un usuario al realizar una transacci\u00f3n. Estos objetos permiten un control detallado sobre qu\u00e9 operaciones pueden ejecutarse dentro de una transacci\u00f3n, incluyendo restricciones por tipo de actividad o nivel de informaci\u00f3n que se puede ver.<\/p>\n<h3><span style=\"color: #ee7812;\">Nivel de organizaci\u00f3n<\/span><\/h3>\n<p>&nbsp;El nivel de organizaci\u00f3n se refiere a las estructuras organizacionales que limitan las autorizaciones dentro de un rol. Por ejemplo, un rol puede restringir las autorizaciones a una empresa espec\u00edfica, una planta, o una unidad organizativa. Esto asegura que el acceso a la informaci\u00f3n y las transacciones est\u00e9 limitado a ciertas partes de la organizaci\u00f3n.<\/p>\n<h2>Diferencias entre Roles Maestros y Roles Derivados<\/h2>\n<p><span style=\"font-weight: bold;\">Roles maestros:<\/span> mantiene todos los c\u00f3digos de transacci\u00f3n y los objetos de autorizaci\u00f3n relacionados. Un rol maestro es un rol que sirve como plantilla o rol base para crear roles derivados. Contiene un conjunto predefinido de autorizaciones y permisos que son comunes a un grupo particular de usuarios o procesos de negocios dentro de la organizaci\u00f3n.<\/p>\n<p><span style=\"font-weight: bold;\">Roles derivados<\/span>: estos roles se derivan b\u00e1sicamente del rol maestro, que contiene s\u00f3lo valores de la organizaci\u00f3n y se asigna al usuario. Hereda las autorizaciones y permisos del rol principal o principal y tambi\u00e9n puede tener autorizaciones adicionales espec\u00edficas de la unidad organizativa.<\/p>\n<p>Asignar todo el acceso organizacional al mismo usuario no es una pr\u00e1ctica de seguridad adecuada. A los usuarios solo se les permite tener acceso a un nivel organizacional espec\u00edfico seg\u00fan su ubicaci\u00f3n y responsabilidades.<\/p>\n<p>Por lo tanto, con el enfoque de roles Maestro y Derivado podemos brindar acceso a un nivel organizacional espec\u00edfico a los usuarios.<\/p>\n<h2>El papel del consultor funcional en la gesti\u00f3n de roles y autorizaciones<\/h2>\n<p>El equipo de BASIS tiene conocimientos sobre gesti\u00f3n de usuarios, creaci\u00f3n de roles, creaci\u00f3n de perfiles, asignaci\u00f3n de roles y perfiles, asignaciones de autorizaci\u00f3n, etc., pero la principal preocupaci\u00f3n en la mayor\u00eda de los casos surge cuando el equipo de BASIS no responde a las siguientes preguntas:<\/p>\n<ol>\n<li>\u00bfA qui\u00e9n asignar los roles o transacciones?<\/li>\n<li>\u00bfQu\u00e9 y a qui\u00e9n se debe restringir una transacci\u00f3n?<\/li>\n<li>\u00bfC\u00f3mo autorizar transacciones personalizadas?<\/li>\n<\/ol>\n<p>Este tipo de preguntas no pueden ser respondidas por el equipo de BASIS. En ese caso se hace presente el rol de un consultor funcional quien es la persona encargada de guiarlos en el organigrama exacto para que no haya lugar a dudas.<\/p>\n<p>Para que se entienda mejor, te pondremos un ejemplo peque\u00f1o: supongamos que tenemos un equipo de mantenimiento con el siguiente organigrama:<\/p>\n<ol>\n<li>Supervisor: Es el encargado de notificar las aver\u00edas o requerimientos de mantenimiento correctivo.<\/li>\n<li>Encargado de mantenimiento: es responsable de asignar las tareas anteriores a los ingenieros.<\/li>\n<li>Jefe del departamento: Es el responsable de aprobar las tareas de Mantenimiento.<\/li>\n<\/ol>\n<p>En este caso, el Consultor Funcional es muy consciente de que para el Supervisor solo se requerir\u00edan las transacciones relacionadas con Notificaciones (por ejemplo, IW21, IW22, IW28, IW29, etc.), el Encargado de Mantenimiento requerir\u00eda algunas de las transacciones relacionadas con notificaciones (por ejemplo, IW22, IW28, IW29) y tambi\u00e9n transacciones relacionadas con pedidos (IW31, IW32, IW38, IW39, etc.) y el Jefe del departamento requerir\u00eda notificaciones y transacciones de pedidos (por ejemplo, IW28, IW29, IW38, IW39) y tambi\u00e9n junto con esto requerir\u00eda permisos especiales como liberar pedidos, aprobar permisos, etc.<\/p>\n<p>Desde la perspectiva del equipo BASIS, no tienen claros estos requisitos y, por lo tanto, no pueden tomar la decisi\u00f3n al respecto y deben ser proporcionados por consultores funcionales.<\/p>\n<p>Pero, el problema principal en la mayor\u00eda de los casos surge cuando los consultores funcionales no conocen el concepto de roles y autorizaciones por eso es necesario que esta informaci\u00f3n sea totalmente dominada.<\/p>\n<h2>Xamai tu mejor aliado<\/h2>\n<p>En Xamai te ayudamos a tener una mayor comprensi\u00f3n y optimizaci\u00f3n de tus roles y perfiles SAP. Dado que los roles simplifican la gesti\u00f3n de accesos mediante el Control de Acceso Basado en Roles (RBAC), En Xamai te ayudamos en la correcta implementaci\u00f3n de estos roles y la organizaci\u00f3n de los accesos de los usuarios, asegurando que las operaciones fluyan de manera segura y eficiente.<\/p>\n<p>Adem\u00e1s, te podemos orientar en la creaci\u00f3n y administraci\u00f3n de roles maestros y derivados, permitiendo ayudarte a estructurar tus autorizaciones de acuerdo con tus niveles organizacionales y requerimientos espec\u00edficos.<\/p>\n<p>De esta forma, en Xamai no solo ayudamos a gestionar de manera eficiente los accesos, sino que tambi\u00e9n podemos colaborar en capacitar al equipo BASIS y a los consultores funcionales, para evitar errores y garantizar una administraci\u00f3n coherente y segura de las autorizaciones a largo plazo.<\/p><\/p>","protected":false},"excerpt":{"rendered":"<p><em>Entendiendo c\u00f3mo funcionan los roles y perfiles dentro de SAP ERP<\/em><\/p>","protected":false},"author":4,"featured_media":350037,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[23],"tags":[],"class_list":["post-214","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-inventarios"],"_links":{"self":[{"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/posts\/214","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/comments?post=214"}],"version-history":[{"count":1,"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/posts\/214\/revisions"}],"predecessor-version":[{"id":353734,"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/posts\/214\/revisions\/353734"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/media\/350037"}],"wp:attachment":[{"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/media?parent=214"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/categories?post=214"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xamai.com\/es\/wp-json\/wp\/v2\/tags?post=214"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}