Reingeniería de Perfiles de Seguridad Informática de SAP ...

Proyecto de Grado

Presentado ante la ilustre Universidad de Los Andes como requisito parcial para

obtener el Tıtulo de Ingeniero de Sistemas

Reingenierıa de Perfiles de Seguridad

Informatica para SAP Unificado para la empresa

Ternium

Por

Br. Juan Fuentes

Tutor: Prof. Dulce Milagro Rivero

Septiembre 2008

c©2007 Universidad de Los Andes Merida, Venezuela

Reingenierıa de Perfiles de Seguridad Informatica para SAP

Unificado para la empresa Ternium

Br. Juan Fuentes

Proyecto de Grado — Sistemas Computacionales, 59 paginas

Resumen: La empresa Ternium desea integrar sus sistemas para poder tener una

gestion unificada de estos, para el caso del sistema de planificacion de recursos em-

presariales que usa, SAP, se desarrolla el concepto de SAP Unificado, para integrar

todos los sistemas SAP de las siderurgicas que la componen, en las distintas regiones

donde tiene presencia, en uno solo que preste servicio a dichas regiones sin afectar de

forma negativa los Procesos de Negocio inherentes a esta industria. Para esto hace

falta hacer una reingenierıa enfocada a la unificacion de los procesos de negocio indi-

viduales actuales de cada una y esto pasa por definir las actividades especıficas de los

usuarios, acotando las actividades permitidas a estos de acuerdo a los perfiles que les

son asignados segun las polıticas de Seguridad Informatica.

Palabras clave: Procesos de Negocio, SAP, Sap Unificado, Seguridad Informatica,

Perfiles, Ternium

Este trabajo fue procesado en LATEX.

El Proyecto de Grado titulado “Reingenierıa de Perfiles de Seguridad Informatica para SAP

Unificado para la empresa Ternium”, realizado por Br. Juan Fuentes, C.I. N◦ 15.076.642, fue

presentado el dıa (fecha): 8 de Septiembre de 2008, en (lugar): Salon de Posgrado de Computacion de

la Universidad de Los Andes, ante el Jurado evaluador conformado por:

Tutor: Prof. Dulce Milagro Rivero

Jurado: Prof. Judith Barrios

Jurado: Prof. Victor Bravo

Este proyecto no tiene mencion especial.

A mi padre. Y a mi gran familita, mi madre, America,

Tiby, Dany, Tin and my beautiful Wichy Kaitlyn V.

Indice

Indice de Tablas viii

Indice de Figuras ix

Agradecimientos x

1 Introduccion 1

1.1 El problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1 Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.2 Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6 Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.7 Metodologıa adaptada . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Marco teorico 11

3 Analisis de dominio 16

3.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.2 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.3 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.4 Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v

4 Diseno 22

4.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Modelado Roles por usuario referente . . . . . . . . . . . . . . . . . . . 23

4.2.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Modelo de equivalencias entre Roles . . . . . . . . . . . . . . . . . . . . 25

4.3.1 Heurıstica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.2 Restricciones del algoritmo . . . . . . . . . . . . . . . . . . . . . 27

4.3.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Reingenierıa de Procesos de Negocios . . . . . . . . . . . . . . . . . . . 31

4.5 Modelado ”TO-BE” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5.1 Niveles de Impacto . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5.2 Relacion de Niveles de Impacto . . . . . . . . . . . . . . . . . . 39

4.5.3 Relacion ”Front End” - ”Back End” . . . . . . . . . . . . . . . 39

4.5.4 La Interfaz Middleware . . . . . . . . . . . . . . . . . . . . . . . 41

4.5.5 Configuracion de seguridad Estandar de SAP . . . . . . . . . . 41

4.5.6 Modelo de Aperturas y Especializacion . . . . . . . . . . . . . . 43

5 Construccion 46

5.1 Creacion de Perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Validacion de Perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3 Creacion de Lista de Operaciones de Perfiles . . . . . . . . . . . . . . . 50

5.3.1 Creacion de una Operacion . . . . . . . . . . . . . . . . . . . . . 51

5.3.2 Creacion de una Ruta . . . . . . . . . . . . . . . . . . . . . . . 51

5.4 Apertura de Perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.5 Creacion de Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.6 Ampliacion de Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.7 Apertura de Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.8 Asignacion de Roles a Perfiles . . . . . . . . . . . . . . . . . . . . . . . 52

6 Pruebas 53

7 Implementacion 55

8 Conclusiones 57

Bibliografıa 59

Indice de Tablas

4.1 Ejemplo de Roles evidentemente Equivalentes. Primera parte. . . . . . 28

4.2 Ejemplo de Roles evidentemente Equivalentes. Segunda parte. . . . . . 29

4.3 Ejemplo de Roles evidentemente Equivalentes. Tercera parte. . . . . . . 30

4.4 Relacion Roles Siderar - Ternium (PM). . . . . . . . . . . . . . . . . . 32

4.5 Relacion Roles Siderar - Ternium Otros Modulos (PM). . . . . . . . . . 36

4.6 Roles Ternium sin Equivalente en Siderar (PM). . . . . . . . . . . . . . 36

4.7 Niveles de Impacto de configuraciones de Perfiles. . . . . . . . . . . . . 36

4.8 Relacion de Niveles de Impacto de Perfiles. . . . . . . . . . . . . . . . . 39

4.9 Modelo de relacion ”Front End” - ”Back End”. . . . . . . . . . . . . . 40

4.10 Modelo Menu de Interfaz Middleware. . . . . . . . . . . . . . . . . . . 40

4.11 Modelo de configuracion de Seguridad SAP Estandar. . . . . . . . . . . 43

5.1 Fragmento - Perfiles identificados de los ”Workshop” (CO) . . . . . . . 47

5.2 Fragmento - Perfiles identificados de los ”Workshop” (MM) . . . . . . . 50

viii

Indice de Figuras

1.1 Mapa de areas de gestion Ternium. . . . . . . . . . . . . . . . . . . . . 2

1.2 Configuracion actual de los Modulos FICO/MM/PM de los sistemas

ERP en Ternium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Configuracion de Modulos de SAP Unificado en Ternium. . . . . . . . . 4

1.4 Configuracion del Middleware (”Front End”) en Ternium. . . . . . . . . 5

1.5 Diagrama de Procesos: fases de la Metodologıa. . . . . . . . . . . . . . 7

4.1 Diagrama de Actividades de Diseno del Modelo. . . . . . . . . . . . . . 22

4.2 Workshop - Modelo ”TO-BE” de Proceso de Negocio. Primera parte. . 33

4.3 Workshop - Modelo ”TO-BE” de Proceso de Negocio. Segunda parte. . 34

4.4 Workshop - Modelo ”TO-BE” de Proceso de Negocio. Tercera parte. . 35

4.5 Diagrama de Clases de Niveles de Impacto. . . . . . . . . . . . . . . . . 37

4.6 Diagrama de Clases de Relacion ”Front End” - ”Back End”. . . . . . . 41

4.7 Diagrama de Clases de la Interfaz Middleware. . . . . . . . . . . . . . . 42

4.8 Caso de Uso: Usar la Interfaz Middleware de SAP Unificado. . . . . . . 42

4.9 Diagrama de Clases de la configuracion de Seguridad SAP Estandar. . 43

5.1 Diagrama de Actividades del Desarrollo . . . . . . . . . . . . . . . . . . 46

5.2 Diagrama de Flujo de un subproceso de negocio en el modulo CO(FICO). 48

5.3 Diagrama de Flujo de un subproceso de negocio en el modulo CO(FICO). 49

ix

Agradecimientos

Agradezco especialmente a mis companeros, quienes me ayudaron, apoyaron e hicieron

llevadera esta experiencia: Jose H., Marie Big Sister, Marve ”Mi otra hermanita”,

Einar, Manu, Abel (y Wilson), Braddy, Ana Laura, Ricky, Hector, Jose Martın, Alicia,

Ariel, Emiliano, el clan Rod de San Nicolas (Maxi, Laporte y Silvestre), el equipo de

SINF (Ale y Enriqueta), Darıo, Jose Luis y Tere.

Esta va por todos.

x

Capıtulo 1

Introduccion

1.1 El problema

La empresa Ternium emprendio un proyecto de unificacion de sus sistemas SAP

FICO/MM/PM dispersos, en uno solo que integre las distintas Areas de gestion

empresarial en la geografıa latinoamericana. Para esto hizo una reingenierıa de sus

procesos de negocios a fin de homologarlos y tener procesos indistintos, comunes a

todas las areas. Dicha reingenierıa realizo cambios a estos procesos e inevitablemente

afectaron a los actores y usuarios de los mismos, creando una inconsistencia entre lo

que podıan hacer antes del cambio y lo que pueden hacer luego de este, por lo que

hubo que redefinir los roles que desempenan estos usuarios en el nuevo sistema de

gestion empresarial, que pese a que se trata del mismo proveedor, en este caso SAP,

se hace una nueva configuracion del mismo para atender las nuevas necesidades de

la empresa. Ademas de la integracion de estos sistemas SAP, se ha implementando

una interfaz unica para todos los sistemas de Ternium, proveıdas por una sistema

Middleware de tipo RPC propio de Ternium [4] y presentada a los usuarios a traves

de un cliente Web. Los sistemas SAP Unificado y Middleware corresponden al ”Back

End” y el ”Front End” respectivamente de la nueva estructura de sistemas de Ternium.

Al definir los nuevos roles se tuvo que establecer los mecanismos para que los usuarios

SAP indicados, y solo ellos, hagan uso de cada una de las operaciones SAP que el

nuevo sistema ofrece a traves del cliente Middleware, de una manera coherente, segura,

1.2 Antecedentes 2

confiable y estable.

TerniumInfografInfografííaa

Visión

Ser la empresa siderúrgica líderde América, comprometida con el desarrollo de sus clientes, a la vanguardia en parámetrosindustriales y destacada por la excelencia de sus recursoshumanos.

Misión

Creamos valor con nuestrosclientes, mejorando la competitividad y productividadconjunta, a través de una base industrial y tecnológica de altaeficiencia y una red comercialglobal.

Figura 1.1: Mapa de areas de gestion Ternium.

1.2 Antecedentes

En todo proyecto de implementacion de SAP se hace ingenierıa de Perfiles, ası como

eventualmente se hacen Reingenierıas de procesos y de perfiles asociados. Para el Caso

de Ternium, en cada area se habıan realizado reingenierıas de perfiles en distintas

epocas pero de manera disjunta, tanto para las implementaciones de SAP desde su

migracion inicial como para reconfiguraciones, pero nunca se habıa hecho en funcion

de unificar las distintas instancias en una comun.

De las experiencias Reingenierıa de Perfiles documentadas solo se hallo una

realizada en 2003-2004 para una de las areas de Ternium (SUR), pero solo se encontro

1.2 Antecedentes 3

una definicion de Roles muy pobre y que con el transcurso del tiempo no fue tomada

en cuenta, lo que revelo la gran debilidad de la polıtica de Seguridad Informatica

llevada hasta hoy en la empresa: Se asignaban y generaban Roles y Permisos

descontroladamente segun hubiese una necesidad o una solicitud. Incluso habıan

peticiones por necesidades circunstanciales, temporales o injustificadas, que pasaban

sin ningun control y sin llevar un registro historico de dichas evoluciones: cambios de

posicion en el organigrama de la empresa, nuevos procesos o procesos cambiantes no

documentados, son solo algunos de los casos en que Roles eran asignados para nunca

mas ser removidos de los usuarios a los que se les asignaban, ası no fuesen pertinentes

en el momento los permisos que poseıan. Esta situacion caotica se utiliza como

Nuevo Ciclo Pasivo

Siderar1

Sidor2

Hylsa3

IMSA4

ADMINISTRACIONADMINISTRACIONY FINANZASY FINANZAS

RR HHRR HH MANTENIMIENTOMANTENIMIENTO ABASTECIMIENTOABASTECIMIENTO

SAP HR

SAPPM

STRATIX Desarrollos .NET

SAP HR

STRATIX

Epic

STRATIX

Epic

Legacy

SAPMM

SAPPM

SAP -HR SAPMMLegacy

SAPPM

SAP -HR SAPMMLegacy

SAP STRATIX Microsoft

SAP FICO

SAP TR

SAP FICO

SAP TR

SAP FICO

SAP TR

SAP FICO

SAP TR

Siderar Sidor Hylsa IMSAADMINISTRACIONADMINISTRACION

Y FINANZASY FINANZAS

STRATIX

SAP FICO

SAP TR

SAP FICO

SAP TR

SAP FICO

SAP TR

SAP FICO

SAP TR

RR HHRR HH

SAP HR

Desarrollos .NET

SAP HR

Legacy

SAP -HR

Legacy

SAP -HR

Legacy

MANTENIMIENTOMANTENIMIENTO

SAPPM

STRATIX

Epic

SAPPM

SAPPM

ABASTECIMIENTOABASTECIMIENTO

STRATIX

Epic

SAPMM

SAPMM

SAPMM

Figura 1.2: Configuracion actual de los Modulos FICO/MM/PM de los sistemas ERP

en Ternium.

contraejemplo o antiejemplo de lo que se quiso en este nuevo emprendimiento. Vease

que no se resena esta situacion como ”el problema”, ya que al hacer una reingenierıa

1.3 Alcance 4

de todo el sistema, esta situacion quedarıa relegada al pasado, teniendose en cuenta lo

que no deberıa ocurrir en el futuro en cuanto a los Perfiles de Seguridad Informatica:

No se trataba de reparar los Perfiles antiguos, se trata de no cometer el mismo error

con los nuevos.

1.3 Alcance

Este proyecto de Reingenierıa de Perfiles de Seguridad Informatica se aplicaro a

los modulos y submodulos de FICO/MM/PM de SAP Unificado de Ternium y la

configuracion de usuarios del Middleware correspondientes a los usuarios de dicho nuevo

sistema SAP en todas las areas geograficas de impacto.

02 de Mayo de 2008

Nuevo Ciclo PasivoSiderar Sidor Hylsa IMSA

ADMINISTRACIONADMINISTRACIONY FINANZASY FINANZAS

STRATIX

SAP FICO

SAP TR

SAP FICO

SAP TR

SAP FICO

SAP TR

SAP FICO

SAP TR

RR HHRR HH

SAP HR

Desarrollos .NET

SAP HR

Legacy

SAP -HR

Legacy

SAP -HR

Legacy


SAPPM

STRATIX

Epic

SAPPM

SAPPM

ABASTECIMIENTOABASTECIMIENTO

STRATIX

Epic

SAPMM

SAPMM

SAPMM

RERCURSOS RERCURSOS HUMANOSHUMANOS

SAPHR

SISTEMAÚNICO

SAPFICO

SISTEMAÚNICO

ABASTECIMIENTOABASTECIMIENTOADMINISTRACIADMINISTRACIÓÓN Y N Y FINANZASFINANZAS


SAPMM

SISTEMAÚNICO

SAPPM

SAPPM

SAPPM

Procesos unificados

AM SUR AM CENTRO AM NORTE

Figura 1.3: Configuracion de Modulos de SAP Unificado en Ternium.

1.4 Justificacion 5

NCPTernium | Sistemas

16

Administración y Finanzas Abastecimientos MantenimientoRecursos Humanos

SAP Unificado Conceptual

MIDDLEWARE

RERCURSOS RERCURSOS HUMANOSHUMANOS

ADMINISTRACIADMINISTRACIÓÓN Y N Y FINANZASFINANZAS

BACKENDINFRAESTRUCTURA

Recursos Humanos Administración y Finanzas AbastecimientosAdministración de

PersonalGestión de la Organización

Selección y Reclutamiento

Desarrollo

Capacitación

Nómina

Contratistas

Gestión de Tiempos

Demandas

Almacenes

Normaliza-ción y

Compras

Cuentas a Cobrar Créditos

Contab. General

Cuentas a Pagar

Tesorería Costos

ImpuestosConsolidación Contable

Mantenimiento

Planificación

Estructura y Equipos

Prevención

FinanzasRestaura-

ción

Siderar Sidor Hylsa

Figura 1.4: Configuracion del Middleware (”Front End”) en Ternium.

1.4 Justificacion

Mas alla de la expansion, esta la intencion de integracion, unificacion, por eso SAP

Unificado busca integrar las Areas geograficas en una gran Area comun para tener no

simplemente un solo negocio, sino un unico concepto de este, objetivos comunes, una

misma gestion y pertenecer todos a un mismo equipo de trabajo. Esto no es tan simple

como imponer un modelo, sino eclectizar sobre los modelos anteriores para obtener

lo mejor de estos y en una vision sistemica obtener los beneficios de las propiedades

emergentes minimizando los impactos negativos de la unificacion. En este sentido,

la reingenierıa de perfiles de seguridad informatica busca brindar confidencialidad de

la informacion, integridad de los datos, tolerancia a errores y eventuales fallas, la

integridad fısica de los empleados, la inalterabilidad de la informacion financiera y

1.5 Objetivos 6

contable, la preservacion del patrimonio y bienes de consumo y servicio, la seguridad

jurıdica garantizando de esta forma la eficiencia en el desempeno empresarial y la

calidad de sus productos y servicios.

1.5 Objetivos

1.5.1 Objetivos generales

Configurar el sistema de accesos autorizados de usuarios a las actividades que provee

el nuevo sistema a partir de los sistemas actuales de autorizacion y los nuevos modelos

de procesos de negocio.

1.5.2 Objetivos especıficos

1. Definir e implementar los roles ”Back End” en SAP Unificado para los usuarios

de FICO/MM/PM con todas las transacciones disponibles para cada Rol y el

conjunto de accesos a tablas, objetos y documentos SAP.

• Normalizacion de nomenclatura de Roles Unificados.

• Normalizacion de apertura de Roles.

• Definir polıtica de asignacion y remocion de Roles por usuario.

2. Definir e implementar los Perfiles ”Front End” para los usuarios de Fico/MM/PM

con todas las operaciones que se despliegan en la interfaz Middleware.

• Normalizacion de nomenclatura de Perfiles.

• Normalizacion de apertura de Perfiles.

• Definir polıtica de asignacion y remocion de Perfiles por usuario.

3. Definir e implementar la relaciones entre Roles Back End de SAP Unificado y los

Perfiles Front End de Middleware que se requieran.

• Definir polıtica de asignacion y remocion de Roles Unificados por Perfiles.

1.6 Metodologıa 7

1.6 Metodologıa

La metodologıa que se utilizo es la propuesta por la empresa para este proyecto, la cual

comprende las fases de:Fases del proyecto

ConstrucciónPruebas

Integrales ImplementaciónDiseñoRequisitos

Metodología

Metodología propuestaFigura 1.5: Diagrama de Procesos: fases de la Metodologıa.

• Definicion de requisitos funcionales

• Modelado

• Desarrollo

• Pruebas

• Implementacion

Las consideraciones de las fases de esta metodologıa son:

• Ordinalidad: a excepcion de la primera, cada fase solo puede empezar luego de

haber concluido la anterior.

• Productos:

– Documento de definicion de requisitos funcionales

– Documento contentivo del Modelo de lo que se quiere desarrollar.

– El producto que se desea desarrollar en base a su modelo.

– La validacion funcional y tecnica del producto desarrollado.

– Implementacion del producto desarrollado en los sistemas productivos de la

empresa.

• Los productos de fases anteriores pueden sufrir modificaciones o correcciones

segun se necesite durante cualquiera de las fases del proyecto.

1.7 Metodologıa adaptada 8

• En caso de hacerse alguna modificacion, en alguno de los productos de las fases,

estas correcciones deben propagarse de ser necesario a los demas productos para

mantener la congruencia entre estos, este proceso implica revision de dichos

productos para detectar alguna inconsistencia y corregirla. Luego de hechos los

cambios estos deben documentarse.

• Los documentos generados deben utilizar las plantillas de documentos

predeterminadas, conservando los formatos de Letras y Colores Ternium. Estas

plantillas las provee la empresa.

1.7 Metodologıa adaptada

La adaptacion de la metodologıa propuesta para este proyecto se define a continuacion

en sus diferentes fases:

1. Definicion de Requisitos

La empresa entrega el documento de definicion de requisitos ya elaborado por el

equipo gerencial del proyecto SAP Unificado.

2. Modelado

En esta fase se hizo el modelado simultaneo de los Roles del sistema SAP

Unificado (”Back End”) y los Perfiles del sistema Middleware (”Front End”)

repartiendo las cuotas de dedicacion de recursos a cada uno convenientemente

para ir teniendo un desarrollo de modelos coherente apuntando de la integracion

de estos modelos en el modelo resultante final sintetizado.

(a) Modelado ”Back End”

• Modelado ”AS-IS” de asignacion de Roles SAP Actuales por usuarios

referentes.

• Modelo de equivalencias entre Roles SAP de los sistemas a unificar.

• Reingenierıa de Procesos de Negocios orientada a normalizar las

actividades de los usuarios de de las diferentes Areas. El resultado de


este proceso es utilizado por varios procesos dentro del Proyecto Macro

de SAP Unificado.

• Modelo ”TO-BE” de Roles SAP Unificado.

(b) Modelado ”Front End”.

• Modelado ”AS-IS” de los actores de los Procesos de Negocios y sus

actividades.

• Reingenierıa de Procesos de Negocios orientada a normalizar las

actividades de los usuarios de de las diferentes Areas. El resultado de

este proceso es utilizado por varios procesos dentro del Proyecto Macro

de SAP Unificado.

• Homologacion de Perfiles de Usuario en la empresa.

• Modelo ”TO-BE” de Perfiles de ”Front End” (Middleware)

(c) Modelo ”TO-BE” de relacion de Perfiles ”Front End” - Roles ”Back End”

de SAP Unificado.

3. Desarrollo

El desarrollo consiste en la creacion del conjunto de Roles Back End SAP

Unificado y el conjunto de Perfiles Front End, este desarrollo se hace en paralelo

siguiendo el modelo TO-BE respectivo, una vez construidos estos conjuntos y

siguiendo el Modelo TO-BE de la relacion entre Roles Back End y Perfiles Front

End se concreta el enlace de ambos extremos.

4. Pruebas

(a) Pruebas unitarias

En estas pruebas se verifica la funcionalidad GROSSO MODO de los

usuarios de prueba en SAP Unificado (Back End) mientras que por el lado

del Middleware (Front End) se verifican los caminos para cada una de las

operaciones de cada perfil.

(b) Pruebas integrales


Se hicieron en dos periodos definiendo las operacion crıticas prioritarias en

los frentes que se definan en los escenarios de prueba, dejando un intervalo

de tiempo para tratar y corregir las incidencias detectadas antes de la

implementacion reduciendo la probabilidad de incidencias luego de la misma.

5. Implementacion

Puesta en marcha del nuevo sistema SAP Unificado y la interfaz Middleware para

el Nuevo Ciclo Pasivo.

Capıtulo 2

Marco teorico

Se definen a continuacion los conceptos utilizados en esta monografıa:

• Ternium: la empresa cliente del proyecto SAP Unificado y del proyecto de

Reingenierıa de Perfiles para SAP Unificado.

• Area Manager: se refiere a un area geografica amplia donde la empresa tiene

impacto y engloba empresas filiales y sus dependencias, las cuales pueden incluir

en varios paıses. Se puede encontrar en la monografıa con el nombre de Area o

abreviada como AM.

• Sociedad: es una empresa filial, una persona jurıdica dentro de un paıs de un

Area Manager.

• Centro: se refiere a una planta fısica de una Sociedad, puede ser una Planta

de produccion, elaboracion de productos intermedios u oficinas comerciales o de

gestion.

• SAP: es un sistema de planificacion y manejo de recursos empresariales, estos

sistemas se conocen como sistemas ”ERP” por sus siglas en Ingles de ”Enterprise

Resource Planning”(Planificacion de Recursos Empresariales). El nombre SAP

es un acronimo ingles de ”Systems, Applications and Products”(Sistemas,

Aplicaciones y Productos) [2]. Es un software privativo de origen Aleman, que

se licencia para su uso empresarial y comercial. Orientado a grandes empresas,

2 Marco teorico 12

SAP ofrece modelos estandar de procesos de negocios, configurables al enfoque

particular de los clientes que lo implementan como solucion. Esta configuracion

es posible gracias a la modularidad de SAP y a que esta desarrollado en un

lenguaje de programacion, propio de SAP y de proposito especıfico que se conoce

como ABAP (Advanced Business Application Programming) acronimo ingles de

Programacion de Aplicaciones Avanzadas de Negocios. Es posible configurar

a placer todo SAP si es necesario, accediendo al codigo fuente del sistema y

modificando lo existente o programando nuevos desarrollos.

• SAP Unificado: se refiere al sistema SAP que unifica los distintos sistemas SAP

de cada una de las empresas de Ternium en uno solo. Para fines de este proyecto,

nos referiremos tambien a SAP Unificado como Back End o abreviado como BE

o SAPU.

• Modulo: es un conjunto de Programas y tablas de datos que definen un modelo de

negocios y sus actividades fundamentales segun el Modelo de Negocios de SAP.

Los Modulos que tratados en este proyecto son FICO o FI (finanzas y control),

MM (Gestion de materiales y abastecimiento), y PM (Mantenimiento de Planta).

Se desprenden tambien submodulos como lo son AA, AP, AR, CO, GL, IM y TR

de FICO y QM de MM. Estos submodulos son tratados como modulos en el

contexto de Perfiles.

• Procesos de Negocio: coleccion de tareas relacionadas, iniciadas en respuesta a

un evento y que brinda un resultado especıfico para el consumidor del proceso.

El resultado puede ser bienes o servicios [1].

• Landscape: El enfoque de implementacion a nivel de servidores y ambientes

de operacion recomendado por SAP, conocido en el ambito como Landscape

del sistema SAP, consiste en 3 instancias/servidores de SAP, el primero para

Desarrollos y Configuraciones con datos modificables sin riesgo potencial,

un segundo servidor preferiblemente con datos reales dedicado a Pruebas y

Aseguramiento de la Calidad, comunmente conocido como QAS o SQA. Y un

tercer servidor es el dedicado para el ambiente productivo, el sistema real en

2 Marco teorico 13

operaciones con datos y usuarios reales, garantizando que todo lo que este en este

ambiente funcione como deberıa de funcionar, libre de desarrollos incompletos

nocivos o inseguros. Este ultimo es el ambiente con el cual los usuarios finales

interactuan; los otros dos son transparentes y solo el equipo de desarrolladores y

SQA interactuarıan con ellos.

• Seguridad Informatica: departamento encargado de la gestion de las

configuraciones de permisologıas de acceso a los sistemas informaticos. Tambien

nos referiremos a este termino de forma abreviada como SINF.

• Perfil: configuracion de permisologıas de acceso a la Interfaz Middleware de

Ternium para acceder a los distintos sistemas distribuidos que se utilizan en

Ternium.

• Rol: se refiere a un Rol SAP, que define una configuracion de acceso a

Transacciones y datos. Tiene Transacciones asociadas ası como Objetos de

Autorizacion para definir valores de autorizacion de acceso a estas Transacciones

y a los datos del sistema. Estos Roles se pueden asignar a Usuarios para

definir menus de actividades y las Autorizaciones que posee mediante Objetos

de Autorizacion.

• Middleware: se refiere al sistema Middleware de Ternium, al cual se accede a

traves de una interfaz Web, que puede desplegarse en un navegador comun o un

cliente Web propio de Ternium, disenado exclusivamente para brindar acceso a

dicha interfaz. Tambien nos referiremos a este sistema como Desktop Integrado,

Front End o abreviado como FE o MDW.

• Transaccion: son vistas de programas a las que se accede invocando un codigo

llamado nombre codigo de transaccion o Transaccion simplemente, definen una

actividad de un Proceso de Negocio en SAP.Tambien nos referiremos a las

Transacciones de forma abreviada como Trx.

• Objeto de Autorizacion: combina hasta diez campos de valores de Autorizacion

que son verificados en una expresion logica de tipo Y (and). En el sistema se

2 Marco teorico 14

verifican las Autorizaciones de Usuarios frente a los Objetos de Autorizacion,

los cuales permiten verificaciones complejas vinculadas a una Autorizacion,

permitiendo al usuario realizar una accion. Para ejecutar una accion, el usuario

debe verificar positivamente cada valor contenido en los campos del objeto para

poder superarla y poder acceder a Transacciones o datos segun sea el caso de la

configuracion del Rol que lo usa [6].

• Autorizacion: proporciona uno o varios valores permitidos para los campos

reunidos en un Objeto de Autorizacion. El sistema verifica en base a dichos

valores si un usuario esta autorizado a una determinada accion. Los Usuarios

poseeran valores de Autorizacion en el sistema con los cuales se compararan los

de los Objetos de Autorizacion, los datos de las tablas tambien poseen en las

tuplas valores de campos que se verifican como Valores de Autorizacion [6].

• Sistema Lienzo: se refiere a un sistema que se usa como base para definir sobre

el el sistema nuevo resultante, todas las reconfiguraciones se haran sobre este

sistema Lienzo.

• Sistema Legacy: se refiere a uno de los sistemas que pasaran a la obsolescencia

luego de la implementacion del nuevo sistema.

• Modelo AS-IS: representacion actual de algo, muestra el como esta actualmente.

• Modelo TO-BE: representacion de algo que no ha sido realizado, muestra el como

deberıa ser o el deber ser.

• Workshop: es un documento en donde se define un modelo AS-IS o TO-BE de

Procesos de Negocio.

• Operacion: en la interfaz MDW, las operaciones representan a Trx’s de SAP.

• Ruta: Es la ruta de acceso en el menu de la interfaz MDW hacia una Operacion,

definida por el Perfil, Solapa, Item, Agrupador y la Operacion en sı.

• Solapa: representa en la interfaz MDW un Proceso de Negocio en el menu de un

Perfil.

2 Marco teorico 15

• Item: dentro de una Solapa, representa un Subproceso de Negocio.

• Agrupador: dentro de un item, representa un grupo de Operaciones Clave dentro

de un Subproceso de Negocio.

• Usuario: una persona que hace uso del sistema y que tiene un identificador de

Usuario o pseudonimo, una clave de acceso y una configuracion de Seguridad

Informatica que define las actividades que puede realizar y los datos que puede

tratar en el sistema.

Otros conceptos son definidos y explicados en los siguientes capıtulos.

Capıtulo 3

Analisis de dominio

En el marco del proyecto SAP Unificado de Ternium, se estan unificando las

aplicaciones que este sistema provee a los usuarios. Las actividades en las areas de

Ternium pueden ser disımiles en sus caracterısticas pero siguen estando basadas en

el modelo SAP de negocios, en principio cada area tiene un sistema SAP y procesos

personalizados. Se quiere aglutinar todas las variantes de funcionalidad de los sistemas

SAP de las areas en un solo sistema SAP Ternium Unificado, que contenga las

particularidades de cada area sin perder consistencia, cada usuario en su area solo

podra acceder a las actividades y datos que le concierne. Agregar los procesos al

nuevo sistema sistema es el objetivo del proyecto SAP Unificado, velar que los usuarios

realicen solo sus actividades es el objetivo del proyecto de Reingenierıa de Perfiles de

Seguridad Informatica.

Para lograr el objetivo y siguiendo la metodologıa propuesta, se recaudan

y definen los requisitos del proyecto. Estos se recaudan en reuniones presenciales,

video/tele-conferencias o peticiones via correo electronico.

Durante la obtencion de los requisitos se va realizando la negociacion de estos en

base a posibles inconsistencias entre estos y otros requisitos, la pertinencia, factibilidad

segun los recursos con que se cuenta, modificacion, eliminacion y combinaciones entre

ellos. Este procesos determino los requisitos listados abajo.

3.1 Requisitos 17

3.1 Requisitos

La obtencion de requisitos funcionales y no funcionales fue realizada mediante reuniones

con el equipo gerencial del proyecto Sap Unificado y demas personas involucradas

pertinentemente a juicio de dicho equipo, de donde se identificaron los documentos

que servirıan de base para el diseno, los Usuarios Referentes, Requisitos Funcionales,

Recursos disponibles y Restricciones.

3.1.1 Requisitos funcionales

Los requisitos funcionales especificados fueron los siguientes:

• Los Roles SAP de base a utilizar son los que estan actualmente en el SAP

Hylsa y los demas deben enriquecer y adaptar estos Roles para que satisfagan las

necesidades funcionales de los usuarios los demas sistemas que hagan falta.

• En caso de no haber en SAP Hylsa un Rol que satisfaga alguna necesidad

especıfica de otro SAP, se crea un nuevo Rol en SAP Hylsa para ese fin.

• Los Roles resultantes, ya sean nuevos o modificados, deben respetar el modelo

TO-BE de procesos de negocios de Ternium.

• En caso de ser necesario, se crean variantes de Roles, estas variantes se

identificaran con un sufijo que el equipo de Seguridad Informatica define en

la implementacion en el sistema, este sufijo debe ser auto explicativo y debe

significar siempre lo mismo por lo que se utiliza en otras ocasiones cuando sea

necesario, definiendo ası la nomenclatura de los mismos.

• La descripcion de los Roles debe ser comprensible y hacer mencion de la variante

que representa.

• Para los casos en que hayan actividades disımiles por area, sociedad, centro o

cualquier subdivision geografica, administrativa o de cualquier ındole en una

misma aplicacion, deben crearse Roles hijo segun las variantes correspondientes.

3.1 Requisitos 18

• Los Perfiles ”Front End” deben definir un puesto de trabajo y deben contener

los Roles necesarios que definan las actividades de dicho puesto de trabajo.

• Un Rol puede asociarse a tantos Perfiles como sea necesario.

• Las actividades por Perfil deben cumplir con las Normas Sox, el equipo de

compliance debe velar por esta condicion.

• Los Perfiles por puestos de trabajo de distintas areas, departamentos, etc, deben

tener una variante especıfica y a su vez contener los Roles correspondientes a

dicha variante.

3.1.2 Recursos

Humanos

• Ingeniero de Software Responsable: el Ingeniero de Software es el responsable de

llevar el proyecto de Reingenierıa de Perfiles a cabo utilizando los recursos con

que se cuenta para satisfacer los requisitos del mismo.

• Usuarios Referentes: los identificados por el equipo gerencial, estos usuarios son

usados como modelos de referencia.

• Usuarios involucrados en el proyecto: designados por el equipo gerencial para

tareas especificas de colaboracion en las distintas fases del proyecto, pueden ser

solicitados para estas tareas al equipo gerencial quien decide la pertinencia de la

asignacion de un usuario a la misma. Cualquier comunicacion con los usuarios

debe estar autorizada previamente y convalidada con el equipo gerencial, de

otro modo las informaciones obtenidas con los usuarios no serıan validas para

el proyecto. Las informaciones obtenidas deben constar en correo electronico con

copia a los lideres del proyecto.

• Equipo gerencial: los lideres del proyecto y los gerentes de la empresa involucrados

en el proyecto SAP Unificado identificados oportunamente.

3.1 Requisitos 19

Fısicos

• Sitio de trabajo: escritorio y silla con punto de suministro de energıa electrica,

telefono y red en los sitios indicados por los lideres del proyecto en cualquiera de

las areas Ternium. Gastos de hospedaje y traslado son cubiertos por la empresa.

Tecnicos Hardware

• Computador y perifericos: PC conexion a Intranet y un telefono cercano.

Software

• Cliente SAPGUI 640 de SAP R/3 instalado en todas las PC de la empresa

• Cliente Middleware instalado en todas las maquinas de la empresa.

• MS Office: Word, Excel, Powerpoint, Outlook. estos estan instalados

en todas las PC de la empresa.

• Mesa de ayuda: Las herramientas de software arriba mencionadas en caso de no

estar presente en alguna PC de la empresa, se pueden solicitar su instalacion y/o

configuracion directamente a Mesa de Ayuda del sitio donde se encuentre la PC.

• SO: herramientas propias del sistema, sin permisos de instalacion de software de

ningun tipo en ninguna PC de la empresa.

• Acceso a internet: correo electronico a traves del servicio de correo de la empresa,

otro tipo de conexion no esta permitida.

Documentacion e informacion

• Herramientas de software: la proveıda por la aplicacion en la ayuda.

• Documentos relacionados con los requisitos del proyecto: los modelos TO-

BE tambien llamados Workshop son proveıdos en archivos PowerPoint,

contentivos de modulo, nombre y descripcion escrita y grafica de los procesos

que representan. Cualquier informacion solicitada a Seguridad Informatica es

3.1 Requisitos 20

proveıda en formato de tabla Excel, previa autorizacion y validacion del propio

equipo de SINF. Los documentos elaborados con base a informacion proveıda por

SINF deben ser avalados por SINF.

• Informacion o documentacion adicional de los procesos de la empresa: la que el

equipo gerencial considere pertinente proveer, via correo electronico ya sea con

explicaciones puntuales escritas o documentos adjuntos. Pueden ser reforzadas

con reuniones o llamadas telefonicas explicativas de parte de miembros del equipo

gerencial o de usuarios que ellos designen para tal fin.

• Informacion: La informacion de trabajo de la empresa, incluida la de este proyecto

no debe salir de los recintos de la misma por ningun medio, ya sea electronico o

impreso sin la previa autorizacion de la empresa.

Tiempo

• Tiempos del proyecto: El tiempo para terminar las fases del proyecto son definidos

por el equipo gerencial lo cuales deben ser respetados y los productos entregados

en las fechas previstas.

3.1.3 Restricciones

• Roles verifican N ≤ 10 objetos de Autorizacion ( N = 0 seran Roles Padre con

solo Trx dentro del Modelo)

• Roles contienen N > 0 transacciones Asociadas

• Roles Padre no pueden ser asignados a Usuarios, solo sirven de interfaz para ser

referencia para aperturas, las aperturas tienen las mismas Trx que el padre pero

cambian los Objetos de autorizaciones y sus valores.

• Perfiles contienen N Roles Back End asociados

• Perfiles tienen N > 0 Solapas, con N ≥ 0 items (Item Vacıo es un item) con

0 < N ≤ 10 Agrupadores con N > 0 Operaciones, cada operacion asociada a una

Trx SAP

3.1 Requisitos 21

• Un usuario Middleware tiene N > 0 Perfiles Middleware y un usuario SAP que

agrupara todos los Roles contenidos en cada uno de los Perfiles que posee.

3.1.4 Limitaciones

Dentro del proyecto, la obtencion de recursos planificados tuvieron ciertas restricciones,

que se considera pertinente comentar ya que ejercieron incidencia directa sobre el

desarrollo del proyecto.

• Respecto de recursos Fısicos: dependiendo de la ciudad/paıs y centro escogidos

por el equipo gerencial en cualquier momento durante el transcurso del desarrollo

del proyecto el ingeniero debıa trasladarse y serıa responsable de obtener

dichos recursos. La ubicacion fısica en un escritorio con silla dependerıa de la

disponibilidad de los mismos en el sitio. El Ingeniero de Software debıa tomar

las precauciones del caso y respaldar sus informaciones en sitios compartidos de

la Intranet autorizados o en su buzon de correo, estaba prohibido extraer por

ningun medio, electronico o fısico, informacion de la empresa, incluso durante los

periodos de traslado de un lugar a otro de la misma.

• De recursos tecnicos de hardware: se obtenıan dependiendo de la disponibilidad

de PC en el sitio de trabajo, ası como de perifericos como teclado, mouse, cables

de energıa, red e implementos de trabajo como telefono fijo. En caso de requerir

por inexistencia alguno de estos elementos, podia pedirlos a Mesa de Ayuda del

sitio, sujeto a disponibilidad y tiempos de espera de adjudicacion por centro de

costo del proyecto y autorizacion de los lıderes. Eventualmente, estos mismos

recursos eran suprimidos por hurto dentro de la empresa por parte de los mismos

empleados, aproximadamente un hurto por semana, ocurrıan hurtos a diario ası

que se debıa cuidar elementos faciles de portar como cables, raton, marcar la

silla, guardar los numeros de inventario etc.

Capıtulo 4

Diseno

4.1 Introduccion

El modelado de Perfiles de Seguridad informatica esta guiado por los modelos ”TO-

BE” de procesos de negocios, aunque estos no especifican como se implementara la

configuracion de estos Perfiles. Es en esta fase donde se realiza esta labor.

La metodologıa utilizada para la fase de diseno de este proyecto es la siguiente:

ModeladoAS-IS BE

Definición RolesEquivalentes

Modelo AS-IS Procesos de Negocios

Reingeniería deProcesos de

Negocios

Modelado TO-BERoles BE

Modelado TO-BEPerfiles FE

IntegraciónModelo TO-BEPerfiles SAPU

Proyecto SAPU

Proyecto Perfiles

Figura 4.1: Diagrama de Actividades de Diseno del Modelo.

La figura 4.1 muestra el diagrama de las actividades dentro de la fase de

4.2 Modelado Roles por usuario referente 23

diseno, indicando cuales de estas actividades estan dentro del marco del Proyecto de

Reingenierıa de Perfiles y cuales en el del proyecto SAP Unificado, las cuales colaboran

entre sı.

1. Modelado ”Back End”

• Modelado ”AS-IS” de asignacion de Roles SAP Actuales por usuarios

referentes.

• Modelado de equivalencias entre Roles SAP de los sistemas a unificar.

• Reingenierıa de Procesos de Negocios con el fin de normalizar las actividades

de los usuarios de las diferentes Areas. El resultado de este proceso es

utilizado por varios procesos dentro del Proyecto Macro de SAP Unificado.

• Modelo ”TO-BE” de Roles SAP Unificado.

2. Modelado ”Front End”.

• Modelado ”AS-IS” de los actores de los Procesos de Negocios y sus

actividades.

• Reingenierıa de Procesos de Negocios con el fin de normalizar las actividades

de los usuarios de las diferentes Areas. El resultado de este proceso es

utilizado por varios procesos dentro del Proyecto Macro de SAP Unificado.

• Homologacion de Perfiles de Usuario en la empresa.

• Modelo ”TO-BE” de Perfiles de ”Front End” (Middleware)

3. Modelo ”TO-BE” de relacion de Perfiles ”Front End” - Roles ”Back End” de

SAP Unificado.

4.2 Modelado Roles por usuario referente

Siguiendo con la metodologıa se procedio a trabajar sobre los usuarios referentes para

determinar el conjunto de Roles que deberıa tener una persona con su perfil. En la

4.2 Modelado Roles por usuario referente 24

revision de los sistemas ”Legacy” se encontro un problema que harıa inviable este paso,

dicho problema se describe a continuacion:

Estudiando los Roles que poseen los usuarios referentes se encontro una

problematica en la asignacion de los mismos a los usuarios debido a que no se llevo

control de esta asignacion durante el periodo de funcionamiento del sistema. Esto

conllevo a que el conjunto de Roles que un usuario tenıa en el sistema no identificaba

sus funciones dentro de la empresa.

Los Roles fueron asignados usando la polıtica de Usuario Modelo, es decir,

se buscaba un usuario que estuviera en esa funcion y se copiaba su configuracion al

nuevo usuario. Cuando un usuario cambiaba de funciones se le asignaban nuevas

permisologıas pero no se le removıan las que tenıa previamente. Esta omision, en parte

originada por carencia de una polıtica de control de Seguridad Informatica y ausencia

total de documentacion de la configuracion, derivaron en un sistema de seguridad

ineficaz en el que los usuarios no realizaban acciones nocivas que en teorıa no les

correspondıan solo detenidos por desconocimiento o por su etica.

Para ejemplificar la situacion se describe un escenario representativo de la

misma.

Un usuario entraba a la empresa como tecnico de taller y era conocido o

popular, luego este servıa de modelo para los nuevos tecnicos de taller. Eventualmente

este usuario era promovido o cambiado a otras areas o tareas a iba adquiriendo

funcionalidades de seguridad para realizar su trabajo, pero seguıa siendo el referente

para tecnico de taller, por lo que todos los nuevos tecnicos de taller adquirirıan todas

las funcionalidades que hasta el momento de la asignacion tuviese el usuario referente.

Esto sucedıa con todos los puestos y empleados en toda la empresa.

Aparte de ineficaz, la configuracion de seguridad de este sistema no podıa

aportar informacion util para nuestro diseno, ya que no se correspondıa con las

configuraciones que los usuarios deberıan haber tenido en ese momento, razon por la

cual dicha configuracion no describıa la realidad y por ende no podıa servir de modelo.

Esta problematica fue informada a los lıderes del proyecto y en reunion se decidio

obviar este paso y continuar con los siguientes, esta decision no impidio el desarrollo

de los demas pasos ya que cada uno sirve para aportar informacion de temas conexos

4.3 Modelo de equivalencias entre Roles 25

pero no dependientes del modelo.

4.2.1 Resultados

Este paso se omite de la fase de Diseno debido a que los datos que serıan utilizados

para el mismo eran incorrectos.

4.3 Modelo de equivalencias entre Roles

Continuando con la metodologıa, se realiza el modelado ”AS-IS” de los Roles de los

sistemas ”Legacy” para ası poder buscar sus Roles equivalentes en el sistema Lienzo

(HYLSA) en los casos que sea posible, para facilitar el proceso de unificacion evitando

la redundancia funcional en la configuracion. Esto es, Roles distintos que tienen la

misma funcionalidad y proposito pueden fusionarse, aunque no necesariamente tengan

valores identicos, de hecho, es de esperar que no lo sean al tratarse de sistemas distintos.

El proceso de unificacion agrego los valores correspondientes del sistema ”Legacy” al

Rol lienzo para agregarle su informacion y ası el nuevo Rol pueda servir en el nuevo

sistema, tanto para las actividades actuales en el sistema Lienzo como para las que

existıan en los sistemas ”Legacy”, sin menoscabo de la funcionalidad representada en

el modelo de procesos de negocio correspondiente.

4.3.1 Heurıstica

Para ayudar a la toma de decision de designar Roles equivalentes se desarrolla un

algoritmo de comparacion de patrones lexicograficos y semanticos que se denomina

nivel de congruencia lexicografica y se determina segun el siguiente criterio:

• Cadena 1: C1

• Cadena 2: C2

• Numero de Palabras en Cadena 1: N

• Numero de Palabras en Cadena 2: M


• Numero de palabras de C1 contenidas como subcadenas de C2: NP1

• Numero de palabras de C2 contenidas como subcadenas de C1: NP2

• Nivel congruencia entre C1 en C2: NC

NC =2max (NP1, NP2)

(N + M)donde 0 ≤ NC ≤ e=1 (4.1)

El principio en el cual se basa este indicador (ecuacion 4.1) es el numero de

palabras en total a comparar en ambas cadenas y cuantas de estas aparecen, parcial o

totalmente en una y en la otra, previniendo abreviaciones, desviaciones regionales en

el habla de la lengua castellana, errores ortograficos, pluralizacion u otras causas de

variantes. No se toma en cuenta diferencia de mayusculas y minusculas ya que en este

caso no representan una diferenciacion semantica crıtica.

Hay que hacer referencia a la aparicion de palabras repetidas, las cuales contaran

como coincidencia hasta cubrir la totalidad de la menor cantidad de ocurrencias en

alguna de las dos cadenas a comparar, es decir, por ejemplo, si una palabra aparece

tres veces en una y dos veces como sub cadena en la otra, la cantidad de ocurrencias

contabilizadas es de dos. Igual si el caso hubiese sido dos palabras y tres subcadenas,

el resultado serıa de dos coincidencias. Esto es necesario para evitar contabilizar

coincidencias que no agregan valor semantico a las oraciones.

El valor resultante es un numero entre 0 y un poco mas de 1 que indica que

tan congruente son ambas cadenas lexicograficamente y por tanto la probabilidad de

que digan lo mismo dado que estan escritas en castellano y en un contexto semantico

relativamente similar.

Obtenidos estos valores de comparaciones entre las descripciones de los Roles

del sistema Lienzo y el sistema ”Legacy” se seleccionan el primer y segundo mejor

candidato a ser un Rol Equivalente visto desde cada uno de los sistemas, es decir

candidatos a Equivalente de los Roles ”Legacy” en el sistema Lienzo y viceversa. Para

agregar informacion, se listan las transacciones del Rol en cuestion indicando si existen

en el candidato o no.


Con esta informacion se procede a estudiar primero los Roles mas susceptibles de

tener un Rol Equivalente evidente segun los valores de NC y se corrobora comparando

las funciones de usuarios que posean dichos Roles en ambos sistemas.

Si la cantidad de transacciones coincidentes de los Roles, los nombres y

descripciones de los Roles y las actividades y posiciones de los usuarios con esos Roles

asignados dan evidencia suficiente para decir que un par de Roles son Equivalentes,

previa validacion de un Usuario Referente involucrado en el proyecto, se emite una

dupla de Roles Equivalentes y se procede a estudiar otros Roles.

En caso de que ningun candidato provea evidencia para decidir si es o no un

Rol Equivalente se deja de tratar, se deja pendiente y se pasa a tratar el siguiente Rol

susceptible de tener Equivalente evidente.

Se presenta en las tablas 4.1, 4.2 y 4.3 un ejemplo de Roles Equivalentes,

usando la herramienta de seleccion desarrollada:

4.3.2 Restricciones del algoritmo

• En algunos casos, las descripciones de Roles solo eran una copia del nombre del

Rol, practica que hacıa dificultosa la tarea de identificacion salvo que el nombre

del Rol fuese autoexplicativo. De cualquier manera tambien serıa dificultoso para

el criterio humano.

• El Orden de Complejidad de este algoritmo es O (n4), su ejecucion es interpretada,

la entrada menos voluminosa contiene cerca de mil tuplas contra mil quinientas

a comparar. Por las restricciones de recursos, se debio utilizar computadores de

doble nucleo, con un procesador dedicado haciendo las comparaciones en un solo

sentido entre sistemas SAP y luego de varias horas de ejecucion se reunieron los

resultados en un solo documento con el formato indicado.

La razon para el uso de este algoritmo de seleccion es establecer una heurıstica

para la exploracion de una abrumadora cantidad de Roles a comparar en los distintos

sistemas y sus Modulos, cantidades que en algunos casos superaban el centenar de

Roles por cada lado, y tomando en cuenta el revisar tambien las Transacciones de los

mismos las lıneas a revisar superarıan y por mucho el millar.


Rol Descripción Trx1er mejor Candidato Ternium - Siderar C

ongr

uenc

ia

Nombre Trx Coincide

2do mejor Candidato Ternium -Siderar C

ongr

uenc

ia

Nombre Trx Coincide

PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL01 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL02 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL04 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL20N PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL22 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL22N PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL24N PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL25 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL26 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL2A PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL2B PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL30 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL6A PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL6B PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL6C PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CL6D PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CO99 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CT01 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CT02 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CT04 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CT10 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- CT11 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- GS02 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- IP11 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- IP13 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- IW62 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI1 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI2 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI3 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI4 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI5 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI6 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI7 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCI8 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCIA PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCJB PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MCJC PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MIGO_GI PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- MIGO_GO PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ML81N PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- QS41 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- SO10 PM:ADMINIST 0,8 1 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZEMM0009 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZEMM0013 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZEMM0107 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZEMM0200 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZEMMCP0 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZETMM0012 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZETMM0013 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX- ZRMM0069 PM:ADMINIST 0,8 0 PM:PLAC_ADMI 0,727 0

Conjuntos Trx-Rol-Des para Ternium

Tabla 4.1: Ejemplo de Roles evidentemente Equivalentes. Primera parte.

4.3.3 Resultados

Se presenta un documento con resultados de la comparacion de Roles por descripcion

y Transacciones para definir Roles Equivalentes. Destacan los siguientes casos

• Roles ”Legacy” con Rol Equivalente Lienzo, se le agrega al Rol Lienzo las

funcionalidades que faltan para dar funcionalidad ampliada requerida

• Roles ”Legacy” sin Rol Equivalente Lienzo, cuyas funciones seran migradas y de

debe crear un Rol Nuevo.

• Roles ”Legacy” sin Rol Equivalente Lienzo, cuyas funciones se distribuiran en


PM:ADMINIST Administrador - Solo TRX - CA10 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CA77 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CA85 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CA87 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CF01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CF02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CJ13 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CJ74 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CKMB PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL01 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL02 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL20N PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL22 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL22N PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL24N PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL26 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL2A PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL2B PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL30 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL6A PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL6B PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL6C PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CL6D PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CM05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CM25 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CM30 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CM33 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CM34 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR07 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR08 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR10 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR11 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR12 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR13 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR21 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CR22 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CRAH PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CS01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CS02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CS05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CS14 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CS20 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CT01 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CT02 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CT04 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CV01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CV01N PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CV02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CV02N PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CV03 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CV04 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - CV04N PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA06 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA08 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA11 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA12 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IA16 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IB01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IB02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IB05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IB09 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IB11 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IB12 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IB15 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IBIP PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IE01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IE02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IE05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IE10 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IE25 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK04 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK08 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK11 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK12 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK16 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK18 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK21 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK22 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK31 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IK32 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IL01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IL02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IL04 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IL05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0

Conjuntos Trx-Rol-Des para Siderar

Tabla 4.2: Ejemplo de Roles evidentemente Equivalentes. Segunda parte.


PM:ADMINIST Administrador - Solo TRX - IL12 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IN07 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP04 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP10 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP11 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP13 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP15 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP17 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP25 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP30 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP41 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP42 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP43 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IP50 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IPM2 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IQ01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IQ02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IQS3 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IR01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IR02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW21 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 1PM:ADMINIST Administrador - Solo TRX - IW22 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 1PM:ADMINIST Administrador - Solo TRX - IW24 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW25 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW26 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW27 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW28 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW31 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW32 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW34 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW36 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW37 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW38 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW41 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW42 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW44 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW45 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW48 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW64 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW66 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW68 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW70 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - IW81 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC01 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC03 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC04 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC05 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC06 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC09 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC93 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC94 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MC95 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI1 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI2 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI3 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI4 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI5 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI6 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI7 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCI8 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCIS PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJ1 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJ2 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJ3 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJ4 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJ5 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJ6 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJ7 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJB PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCJC PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCKM PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCMK PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCML PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MCMM PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MM02 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - MMP1 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - OIEB PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - OIOB PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - QS41 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - QS42 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - SO10 PM:ADIC_ADM_SOCIE 0,8 1 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - ZABMZTYPOT PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - ZABMZTYPOTEMERPM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - ZABM_GPS PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - ZN006 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - ZN11 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - ZN13 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0PM:ADMINIST Administrador - Solo TRX - ZN19 PM:ADIC_ADM_SOCIE 0,8 0 PM:CLASE_AVISO 0,6 0

Tabla 4.3: Ejemplo de Roles evidentemente Equivalentes. Tercera parte.

4.4 Reingenierıa de Procesos de Negocios 31

otros Roles y este sera eliminado.

• Roles ”Legacy” sin Rol Equivalente Lienzo, cuyas funciones no aplican al nuevo

sistema y este por tanto sera eliminado.

• Roles Lienzo sin Rol Equivalente ”Legacy”, permanecen sin cambios.

Se presenta a continuacion los resultados para un sistema ”Legacy” 4.4, 4.5,

4.6 Algunos Roles de este sistema no fueron tomados en cuenta para las resultados

ya que no eran relevantes para el estudio, en muchos casos eran Roles antiguos, ya en

desuso, pero que permanecıan en la configuracion. Por estas razones se omiten.

4.4 Reingenierıa de Procesos de Negocios

Los modelos ”TO-BE” de Procesos de Negocios se presenta en documentos llamados

”Workshop” y son estos modelos la base para el modelado de Roles y Perfiles de

Seguridad Informatica. El modelado ”TO-BE” de Procesos de Negocios se realiza en el

marco del proyecto SAP Unificado y esta fuera del alcance del proyecto de Reingenierıa

de Perfiles de Seguridad Informatica.

En este proceso de Reingenierıa esta contemplado el Modelado AS-IS de Perfiles

Funcionales, y aunque estos sirven como Modelos ”AS-IS” de Perfiles para el proyecto

de Reingenierıa de Perfiles de SINF, se utiliza solo el producto final de esta fase (Los

”Workshop”) para continuar con el Proceso de Modelado ”TO-BE” de Perfiles.

En estos modelos se presentan los Procesos de Negocios y sus Actores, estos

actores son la referencia a utilizar para crear los Perfiles y Roles necesarios para que

los usuarios a los que representan puedan acceder a las actividades que el modelo de

Procesos de Negocios esta definiendo.

4.5 Modelado ”TO-BE”

Se converge en este punto en el modelado de Roles y Perfiles ya que de aquı en adelante

el diseno y posterior construccion de la configuracion de estos debe realizarse de forma

articulada.

4.5 Modelado ”TO-BE” 32

Siderar TerniumPM:ADMINIST_VAR Administrador - Variante PM:ADIC_ADM_SOCIE ADIC Administrador Sociedad -Solo TRX-PM:ANPREDICT_VAR Analista Predictivo - Variante PM:PREDICTIVO PM:PREDICTIVO - trxPM:FACILI_VAR Facilitador - Variante PM:ADM_PLANTA PM:ADM_PLANTA - trx

PM:GEST_AVISO_MANT_M1Gestión de Avisos de Mantenimiento - Solicitud Mantenimiento PM:SOLICITANTE_A_MTTO PM:SOLICITANTE_A_MTTO - trx

PM:GEST_AVISO_MANT_M2Gestión de Avisos de Mantenimiento - Aviso de avería PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISO_MANT_M3Gestión de Avisos de Mantenimiento - Avisos de Actividad PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISO_MANT_M4Gestión de Avisos de Mantenimiento - Aviso de Parada de Línea PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISO_MANT_M5Gestión de Avisos de Mantenimiento - Aviso de mejora continua PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISO_MANT_M8Gestión de Avisos de Mantenimiento - Aviso Predictivo PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISO_MANT_MIGestión de Avisos de Mant. - Avisos de Cal. de Instrumentos PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISO_MANT_MQGestión de Avisos de Mantenimiento - Avisos de Calidad PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISO_MANT_VAR Gestión de Avisos de Mantenimiento - Variante -PM:CLASE_AVISO Clase de Aviso -Solo TRX-PM:GEST_AVISOS_M2 PM Gestión de avisos - Aviso de Averia M2 PM:CLASE_AVISO Clase de Aviso -Solo TRX-

PM:GEST_AVISOS_M3 PM Gestión de avisos - Aviso de Actividad M3 PM:CLASE_AVISO Clase de Aviso -Solo TRX-PM:GEST_EQUIPOS_VAR Gestión de Equipos - Variante Para Eliminar "++++++++++++++"

PM:GEST_OT_MANT_PM14Gestión Ordenes de Trabajo de Mantenimiento -PM14 - Para Eliminar "++++++++++++++"

PM:GEST_OT_MANT_PM20Gestión Ordenes de Trabajo de Mantenimiento -PM20 - Por Asignar Pedidos de Insumos

PM:GEST_OT_MANT_VARGestión Ordenes de Trabajo de Mantenimiento -Variante - Para Eliminar "++++++++++++++"

PM:GUARDIA_OPER_VAR Guardia_Oper - Variante PM:GUARDIA PM:GUARDIA - trxPM:ING_IAME_VAR Ing. IAME - Serv.Cent. - Variante PM:ING_DE_MTTO PM:ING_DE_MTTO - trxPM:INSP_GMP_VAR Inspector GMP - Variante PM:INSPECTOR PM:INSPECTOR - trxPM:INST_MASI_VAR Instrumentista MASI - Variante PM:CALIBRACION PM:CALIBRACION - trxPM:LAB_SUP_VAR Laboratorio - Supervisor - Variante - PM:SUPERVISOR_PISO PM:SUPERVISOR_PISO - trxPM:LIB_OT Liberador OT- Solo TRX - Para Eliminar "++++++++++++++"

PM:LIB_OT_AH1_PEPLiberador OT - FAIs habilitados relining ALHO1 -Variante Para Eliminar "++++++++++++++"

PM:LIB_OT_GMP Liberador OT - Todos los CeCos Para Eliminar "++++++++++++++"

PM:LIB_OT_GTECLiberador OT - Todos los FAIs de Ingeniería - Variante - Para Eliminar "++++++++++++++"

PM:LIB_OT_GTEC_ESTLiberador OT - Todos los FAIs de Ingeniería - Variante - Para Eliminar "++++++++++++++"

PM:LIB_OT_IAMELiberador OT - Area IAME(Ing. Aplicada a las Mejoras) RyMM/MO Para Eliminar "++++++++++++++"

PM:LIB_OT_LC Liberador OT - Area de Laminación en Caliente Para Eliminar "++++++++++++++"

PM:LIB_OT_LC_OPER Liberador OT - Area de Laminación en Caliente Para Eliminar "++++++++++++++"

PM:LIB_OT_LC_REXLiberador OT - Area de Laminación en Caliente REX Para Eliminar "++++++++++++++"

PM:LIB_OT_LF Liberador OT - Area de Laminación en Caliente Para Eliminar "++++++++++++++"PM:LIB_OT_PM16 Libera ot pm16 Para Eliminar "++++++++++++++"PM:LIB_OT_PM19 Liberador OT - Todos los CeCos - PM19 Para Eliminar "++++++++++++++"PM:LIB_OT_PM20 Liberador OT PM20 - Todos los CeCos Para Eliminar "++++++++++++++"PM:LIB_OT_RE Liberador OT - Area de Reducción Para Eliminar "++++++++++++++"PM:LIB_OT_TAGE Liberador OT - Area TAGE (Taller General) Para Eliminar "++++++++++++++"PM:LIB_OT_TALLER Liberador OT - Todos los CeCos Para Eliminar "++++++++++++++"PM:LIB_OT_TCZ Liberador OT - Taller Central y Zonales SN - Para Eliminar "++++++++++++++"PM:LIB_OT_VAR Liberador OT - Todos los CeCos Para Eliminar "++++++++++++++"PM:LIBERA_OT_PM18 Liberador OT - Todos los CeCos - PM18 Para Eliminar "++++++++++++++"PM:OPER_MANT_VAR Operador Mantenedor- Variante PM:INSPECTOR PM:INSPECTOR - trx

PM:OPER_TEND_VAR Grupo Ensayos no Destructivos Por AsignarGrupo de personas contratadas fuera de planta

PM:PLAC_ADMI_VAR PLAC_Administrador - Variante PM:PROGRAMADOR PM:PROGRAMADOR - trxPM:PLAC_AN_VAR PLAC_Analista - Variante PM:PROGRAMADOR PM:PROGRAMADOR - trxPM:PLAC_PLANIF_VAR PLAC_Planificador - Variante PM:PROGRAMADOR PM:PROGRAMADOR - trxPM:PREST_INTE_VAR Prestador de Servicios Intendencia - Variante PM:INSPECTOR PM:INSPECTOR - trxPM:PROG_SERV Programador - Servicios PM:PROGRAMADOR PM:PROGRAMADOR - trxPM:PROG_TALLER_VAR Programador_Taller - Variante PM:PLANIF_TALLER_INT PM:PLANIF_TALLER_INT - trxPM:PROG_TALLER_VAR Programador_Taller - Variante PM:PLAN_TALLER_INT_EXT PM:PLAN_TALLER_INT_EXT - trxPM:PROG_VAR Programador - Variante PM:PROGRAMADOR PM:PROGRAMADOR - trx

PM:REP_TALLER_VAR Repuestista Taller - Variante Por Asignar Pide Repuestos, trabaja en taller y usa SAPPM:RESP_GMP_VAR Responsable GMP - Variante PM:LIDER_GPM PM:LIDER_GPM - trxPM:RESP_INTE_VAR Responsable Intendencia - Variante PM:LIDER_GPM PM:LIDER_GPM - trx

PM:SIDERNET_VAR Autorizaciones para SIDERNET - Variante - Por Asignar

Servicio mantenimiento Autos, lo hace Sidernet y lo piden por SAP se relaciona con MM

PM:SUP_GUARDIA_VAR Supervisor Guardia - Variante PM:SUP_GUARDIA PM:SUP_GUARDIA -Solo TRX-PM:SUP_SERV_VAR Supervisor Servicios Transporte - Variante PM:SUPERVISOR_PISO PM:SUPERVISOR_PISO - trxPM:SUP_TALLER_VAR Supervisor Taller - Variante PM:SUPERVISOR_PISO PM:SUPERVISOR_PISO - trxPM:TECN_IAME_VAR Técnico IAME - Serv. Cent. - Variante PM:INSPECTOR PM:INSPECTOR - trx

PM:TECN_TALLER_VAR Técnico Taller - Variante Por Asignar

Analista de proceso de reparación de equipos en taller, es un especialista que usa SAP asiste al programador

PM:TRATAR_DOCUMENTOS_VAR

TRATAMIENTOS DE DOCUMENTOS PARA EQUIPOS - VARIANTE PM:GEST_TARJETAS_TSG

Tarjetas de seguridad tsg, solo creación y modificación.

PM:USUARIO_GTEC_VAR Usuario GTEC - variante PM:ING_DE_PLANTA PM:ING_DE_PLANTA - trxPM:VISU_VAR Visualización PM - Variante PM:VISUALIZADOR_PM PM:VISUALIZADOR_PM - trx

Tabla 4.4: Relacion Roles Siderar - Ternium (PM).


Etapa de Diseño del Modelo To-BeTernium

1

Alcance

Definición

Este proceso se inicia luego de la reparación y notificación de horas, cuando una vez concluido el trabajo, el usuario quiere cerrar técnicamente la orden.

• Una vez que la orden haya sido completamente notificada y no queden operaciones pendientes de ejecución, se realiza el Cierre Técnico de la misma.• Si al intentar cerrar técnicamente la orden quedan reservas pendientes, no podrá realizarse el cierre de la orden, el usuario de mantenimiento deberá decidir que hacer con la reserva abierta.

• Si la misma es para un material de alta rotación, podrá él mismo fijar el tilde de salida final en la reserva para cancelarla. • Si el material reservado es de baja rotación, deberá negociar con el Planificador del material la toma o cancelación de la reserva. Sólo el Planificador estará autorizado a cancelar una reserva proveniente de una orden para un material de baja rotación, a través de una transacción Z que se creará para tal fin.

• Si al intentar cerrar técnicamente la orden, la misma tiene un aviso asociado sin el catálogo correspondiente cargado, no se permitirá el cierre técnico de la orden. Será obligatorio completar el catálogo del aviso e intentar nuevamente el cierre técnico. • El cierre técnico de la orden provoca también el cambio de status de usuario a CMTO (Cierre de la orden de Mantenimiento).• Cuando transcurren 45 días del cierre técnico, un programa aplica el Cierre Comercial en las órdenes.

Proceso: 12.02 Gestión de avisos y órdenes Subproceso: 12.02.08 Cierre de la orden

Figura 4.2: Workshop - Modelo ”TO-BE” de Proceso de Negocio. Primera parte.



2

Inicio

Planificador del material

12.02.07Impresión y notificación

Reservas pendientes

?

Mats alta rotación?

40 – Resuelve con Planificador

reservas pendientes

30 – Fija tilde salida final en reservas

100 – Cierre Técnico OT

120 – Cierre comercial

45 días desde Cierre

Técnico?

Fin

110 – Status de usuario CMTO

Si No

Si

No

Si


50 - Fija tilde de salida final en

OT desde Trx Z

60 - Salida de material

70 - Entrega material a Mtto

Catálogo del aviso

completo?

90 - Completa Catalogo en el

aviso

Usuario de Mantenimiento

10 - Intenta cierre técnico

Si

No

B

B

80 - Error: No se permite el cierre de

la orden

Almacenes

Permite cancelación

?

Si

No

20 – Error: No se permite el cierre

de la orden

Figura 4.3: Workshop - Modelo ”TO-BE” de Proceso de Negocio. Segunda parte.



3


Planificador del materialZZZZSi el Planificador acepta cancelar la reserva, fijará el tilde de salida final en la reserva, mediante una transacción Z creada para tal fin.

50

Si el catálogo del Aviso no está completo, entonces el sistema muestra automáticamente un “mensaje de Error”, no se permite el cierre de la orden.

80

Usuario de MantenimientoEl usuario deberá completar el Catálogo en el aviso.90

AlmacénMIGOSi el Planificador no acepta cancelar la reserva, el Almacén le dará salida al material.60

AlmacénLos materiales son entregados a Mantenimiento.70

Usuario de MantenimientoIW32Si los materiales pendientes no son de alta rotación, el usuario no podrá colocar el tilde de salida final directamente en la orden, y deberá resolver con el Planificador del material la cancelación / toma de las reservas pendientes

40

IW32Si existen reservas/solp abiertas, el sistema envia un mensaje de error no permitiendo el cierre técnico de la orden

20

Al realizar el Cierre Técnico, automáticamente cambia el Status de usuario de la OT a “CMTO”.110

Usuario de MantenimientoSi no existen reservas pendientes y el Catálogo del Aviso está completo, se realiza el Cierre técnico de la OT.

100

Usuario de MantenimientoIW32Si los materiales pendientes son de alta rotación, el usuario de mantenimiento tendrá permiso para fijar el tilde salida final en las reservas desde la orden.

30

Usuario de MantenimientoIW32El usuario de mantenimiento intenta realizar el Cierre técnico de la orden10

Al transcurrir 45 días del Cierre Técnico, automáticamente el sistema realiza el Cierre comercial.120

Trx RolDescripciónN°

Figura 4.4: Workshop - Modelo ”TO-BE” de Proceso de Negocio. Tercera parte.


Roles de otros MódulosFI:VIS_FICO_VAR Visualizar FICO - Variante PM:CO:VISU PM:CO:VISU - trxMM:VISU_CPRAS_VAR Visualizacion De Compras - Variante PM:MM:VISU PM:MM:VISU - trxMM:VISU_MAE_MAT_VAR Visualizar Maestro De Materiales - Variante PM:MM:VISU PM:MM:VISU - trxMM:VISU_PEDIDO_VAR Visualizar Pedidos - Variante PM:MM:VISU PM:MM:VISU - trxMM:VISU_SOLP_VAR Visualizar Solp - Variante PM:MM:VISU PM:MM:VISU - trxMM:VISU_STOCK_VAR Visualizar Stock - Variante PM:MM:VISU PM:MM:VISU - trx

Tabla 4.5: Relacion Roles Siderar - Ternium Otros Modulos (PM).

Roles Unicos TerniumPM:JEFE_OPERATIVO Jefe Operativo Mantenimiento -Solo TRX-PM:LIB_TARJETAS_TSG Tarjetas de seguridad tsg, solo liberaciónPM:LISTADO_PUEST_TRABAJOListado puestos de trabajoPM:GESTION_CAPACIDADES PM:GESTION_CAPACIDADES - trxPM:REPORTE_BITACORA Reporte bitacora

PM:START_UP_PMPM:START_UP_PM - trx USO EXCLUSIVO SETTING SISTEMAS

Tabla 4.6: Roles Ternium sin Equivalente en Siderar (PM).

Niveles de ImpactoOrganizacional Areas Man Sociedad Centro Actividades Especiales Mixto Personalizado

Savio Acerías Merlo

Canning ZINC Fernandez

Varela Pinturas Maiorano

,,, Sidernet ,,,

Impeco ,,, ,,, ,,,

,,, ,,, ,,,

,,, ,,, ,,,

,,, ,,, ,,,

,,, ,,, ,,,

Sur

Norte

Centro*

Técnico MTTO Savio Rosario

Supervisor Canning

Ensenada Varela

Despachador Almacen

Polietileno Pintura

*

Toda la empresa

,,,

* * *

Siderar

Hylsa

Imsa

Sidor*

Tabla 4.7: Niveles de Impacto de configuraciones de Perfiles.

4.5.1 Niveles de Impacto

Se establece una estructura jerarquica de Perfiles y Roles en cuanto a su impacto en la

organizacion. Como muestra la tabla 4.7 existen varios Niveles de Impacto sobre los

cuales los Perfiles y Roles pueden tener influencia:


NI_Padre

NI_Organizacional

NI_Area

NI_Sociedad

NI_Centro

NI_ActEspecial

NI_Simple

NI_Personalizado

NI_Mixto

NivelImpacto

XORXOR

2..N-1

XORInstancia de

Figura 4.5: Diagrama de Clases de Niveles de Impacto.


• Organizacional

Tienen un ambito amplio, pueden tratar informaciones de toda la empresa.

• Areas Manager

Tienen ambito regional en alguna de las Areas Manager de Ternium, ya sea Norte

(Mexico), Centro (Venezuela) o Sur (Argentina).

• Sociedad

Tienen ambito restringido a una persona jurıdica dentro de la Organizacion

Ternium, como lo son empresas como Sidor, Siderar, Hylsa, Imsa entre otros.

Es muy importante este ambito para los temas financieros y de gestion.

• Centro

Tienen ambito local y estan representados por centros logısticos fısicos, como lo

son las plantas de produccion y manufactura.

• Actividades especiales

Tienen ambito funcional, actividades que pueden realizarse en cualquiera de los

ambitos anteriores, este es el nivel de mayor detalle en la clasificacion.

• Mixto

Se trata de combinaciones de instancias distintas de configuraciones de un

mismo ambito, sin llegar a cubrirlas todas, ya que esto supondrıa un nivel de

impacto superior. Estan justificadas por situaciones especiales que ameritan estas

combinaciones de configuraciones ya preestablecidas.

• Personalizado

En ultima instancia se recurre a la creacion de configuraciones especıficas unicas,

para satisfacer necesidades puntuales de funcionalidad, como puede ser para una

persona importante que realiza actividades temporales o circunstanciales que

no pueden enmarcarse dentro de las actividades generales representadas por los

modelos de Procesos de Negocios.


Relación de Niveles

CentroContienen ↓

Actividades Especiales

SociedadAreas Manager

Organizacional

Mixto Personalizado

← Contienen

Tabla 4.8: Relacion de Niveles de Impacto de Perfiles.

4.5.2 Relacion de Niveles de Impacto

La relacion entre estos niveles de impacto desde el punto de vista de conjuntos se

describe en la tabla 4.8 donde se puede ver que, desde el nivel Organizacional, se

desprende el nivel de Areas Manager, del que a su vez se desprende el de Sociedades y

por ultimo el de Centros, cada uno hacia arriba contiene la totalidad de las instancias

que de sı se desprenden.

Las Actividades Especiales son, como su nombre lo dice, especializaciones de

Roles y Perfiles en alguno de los niveles descritos para una actividad en especıfico.

Una configuracion de impacto Mixta se refiere a combinaciones de cualquiera

de las configuraciones descritas anteriormente excepto la Organizacional, ya que esta

es una instancia unica universal dentro del enfoque de la empresa. Podemos ver en la

tabla 4.7 ejemplos de Perfiles Mixtos en donde un mismo Perfil impacta sobre varios

Centros, o varias actividades segun sea el caso.

Por ultimo una configuracion personal puede tener impacto aleatorio, no

hay restricciones para lo que una configuracion personalizada pueda impactar, son

excepciones mas no regla, por lo que este tipo de configuraciones no deben proliferarse

en el sistema ya que este perderıa robustez y orden, la finalidad de este tipo de

configuraciones es de cubrir vacıos funcionales crıticos. No obstante se debe tender

en el tiempo a reemplazar este tipo de configuraciones por una del tipo estructurada.

4.5.3 Relacion ”Front End” - ”Back End”

Como se explico en el Marco Teorico, existen dos extremos para la configuracion

de Perfiles, llamados ”Front End” y ”Back End”, representando respectivamente al

sistema Middleware y SAP Unificado. La relacion entre estos dos frentes s puede ver

en la tabla 4.9.


MDW SAPPerfil 1 ← → Rol 1Perfil 2 ← → Rol 2Perfil ,,, ← → Rol ,,,Perfil n ← → Rol m

MDW SAP→ Rol 1→ Rol 2→ Rol 3→ Rol …→ Rol n

MDW SAPOper 1 ↔ Trx 1Oper 2 ↔ Trx 2Oper 3 ↔ Trx 3Oper ,,, ↔ Trx …Oper n ↔ Trx n

Usuario FE Usuario BE↔

Perfil

Tabla 4.9: Modelo de relacion ”Front End” - ”Back End”.

En esta tabla se puede ver que un usuario en un sistema corresponde uno a uno

con un unico usuario en el otro, donde el conjunto de Perfiles ”FE” corresponde a un

conjunto equivalente de Roles ”BE” de dichos usuarios. Ademas existe una relacion

uno a muchos entre un Perfil ”FE” y un conjunto de Roles ”BE”.

Las Operaciones que ofrece el ”Desktop Integrado” se corresponden en una

relacion uno a uno con Transacciones SAPU.

Rutas de acceso a OperacionesOper 1 Ruta 1Oper 2 Ruta 2

Agrup 2 Oper ,,, Ruta 3Agrup ,,, Oper 14 Ruta 4

Oper 25 Ruta 5Oper 26 Ruta 6Oper 2 Ruta 7

Oper 40 Ruta 8Agrup 2 Oper 5 Ruta 9

Solapa ,,, Item ,,, Agrup ,,, Oper ,,, Ruta ,,,Solapa n > 0 Item m ≥ 0 Agrup 1 ≤ j ≤ 10 Oper k > 0 Ruta x > 0

Menú Interfaz Middleware Ternium

Perfil

Agrup 1

Item 1

Solapa 1

Contiene →

Agrup i ≤ 10

Item 2 Agrup 1

Tabla 4.10: Modelo Menu de Interfaz Middleware.


Figura 4.6: Diagrama de Clases de Relacion ”Front End” - ”Back End”.

4.5.4 La Interfaz Middleware

La interfaz Middleware es un servicio WEB al cual se accede desde un navegador WEB

comun o desde el Cliente Middleware desarrollado para tal fin, el cual tiene ventajas

de de rendimiento sobre su contraparte de proposito general. el Desktop Integrado

ofrece un sin fin de accesos a sistemas distribuidos en la empresa, uno de estos es

SAP Unificado y se accede a el desde el enlace al ”Nuevo Ciclo Pasivo”. En ese

enlace se encuentra el menu de operaciones ofrecidas segun los Perfiles asociados a ese

usuario Middleware. El diagrama de la figura 4.8 muestra el caso de uso de la interfaz

Middleware.

En la tabla 4.10 se desglosa la distribucion de dichas Operaciones segun Solapas,

Items y Agrupadores funcionales, estructurados y nombrados convenientemente para

poder ubicar las operaciones de forma facil y ordenada.

4.5.5 Configuracion de seguridad Estandar de SAP

Por ultimo tenemos el Estandar de configuracion de Autorizaciones de SAP. En la

tabla 4.11 se muestra la relacion entre Roles y Transacciones, por un lado, y Roles y


Usuario FE Perfil1..* 1..* Operación1..* 1..*

Solapa Item Agrupador

1

*

1* 11..10

1..*

1..*

Figura 4.7: Diagrama de Clases de la Interfaz Middleware.

Usuario Real

Acceder al Cliente Middleware

Verificar usuario FE

Acceder Menú Ciclo Pasivo NCP

<<include>>

Verificar usuario BE

<<extend>>Dispara

Escoger Perfil

<<extend>>

<<include>>

Escoger OperaciónUsar Operación

Salir del Cliente Middleware

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>><<extend>>

<<extend>>

Acceder al resto de funciones del Middleware No NCP

<<extend>>

Escoger SolapaEscoger ItemEscoger AgrupadorVerificar Autorizaciones

<<include>>

<<include>> <<include>>

<<include>><<include>>

Figura 4.8: Caso de Uso: Usar la Interfaz Middleware de SAP Unificado.

Objetos de Autorizacion. Un Rol tiene un conjunto de Transacciones que configuran su

Menu de Actividades. A los Roles tambien se les suele llamar Grupos de Actividades.


MenúAut 1 Trx 1Aut 2 Trx 2Aut 3 Trx 3Aut ,,, Trx 4

Aut m ≤ 10 Trx 5Aut 1 Trx 6Aut ,,, Trx 7

Aut k ≤ 10 Trx 8Aut ,,, ← Obj Aut ,,, ← Trx ,,,Aut ,,, ← Obj Aut n ≥ 0 ← Trx i ≥ 1

Se definen en el modelo

Ternium

Se usan Trxs Estandar, Modificadas y Nuevas

hechas en Ternium

←

PermisologíasConfiguración Roles en SAP (Estándar)

Se usan los del Modelo SAP R/3 y se configuran sus valores admitidos

Rol →

←

←

Obj Aut 1

Obj Aut 2

←

Tabla 4.11: Modelo de configuracion de Seguridad SAP Estandar.

Rol Transacción1..* 1..*Obj AutAutorización

1..*1..10 1..*1..*

Figura 4.9: Diagrama de Clases de la configuracion de Seguridad SAP Estandar.

Los objetos de Autorizacion contienen hasta diez distintos conjuntos de valores de

Autorizaciones con los cuales las Autorizaciones de los usuarios se verifican tanto para

hacer uso de una transaccion como para acceder a informaciones de tuplas en tablas

del sistema. Las transacciones proveen la funcionalidad y los Objetos de Autorizacion

con sus valores proveen la seguridad. Como el modelo del proveedor (SAP) es bastante

rico, se utiliza el conjunto de Autorizaciones / Objetos de Autorizacion que este ofrece,

dejando a la configuracion de Roles estructurarlos de forma conveniente.

4.5.6 Modelo de Aperturas y Especializacion

Como se menciono anteriormente, se establece una estructura jerarquica de impacto del

modelo de Perfiles de Seguridad Informatica, cada especializacion por Nivel de Impacto

se denomina Apertura. Las Aperturas se realizan segun se considere necesario.


Nomenclatura

Es responsabilidad del equipo de Seguridad Informatica decidir el nombre codigo de

Perfiles y Roles, respetando las siguientes normas:

• El Nombre codigo del Rol/Perfil debe ser representativo de su nombre completo

• La Descripcion del Rol/Perfil en el sistema contiene el nombre completo y

cualquier otra descripcion especifica considerada necesaria para distinguir dicho

Rol/Perfil de otros.

• El Prefijo del Nombre codigo del Rol debe ser de dos caracteres indicando el

Modulo al cual pertenece funcionalmente dicho Rol, seguido inmediatamente del

simbolo ’:’ (dos puntos) y el restante nombre del Rol.

• En Aperturas:

El Sufijo del nombre del Rol/Perfil especializado identifica el Nivel de Impacto

de este.

– Si un Rol no lo llevase se le considera un Rol Padre y no debe ser asignado

a Perfil o Usuario alguno. Estos Roles en su descripcion deben indicar que

se trata de un Rol Padre. Estos Roles no son asignables a Usuarios ya que

carecen de informacion de permisologıa de acceso a datos, solo contienen

el menu de Transacciones sin Objetos de Autorizacion. Son los Objetos de

Autorizacion los que contendran los Valores de Autorizacion con los cuales

verificar el derecho de acceso y tratamiento por parte de los Usuarios, la

asignacion de un Rol Padre a un Usuario devendra en un error en el sistema

cuando este intente operarlo.

– Para denotar un Rol de Impacto Organizacional asignable a usuario debe

definirse un sufijo de Variante para dicho Rol.

– Para Roles de Impacto Combinado debe especificarse este en el/los Sufijos

– Para Roles de Actividades Especiales, el Sufijo de esta especializacion

secunda al del Nivel de Impacto de Rol


– En caso de que un Perfil no lo llevase se le considera un Perfil de Impacto

Organizacional.

• Toda definicion de Nombres, Prefijos y Sufijos debe documentarse.

• Toda definicion de Nombres, Prefijos y Sufijos es reutilizable.

• No debe haber mas de una definicion de Nombres, Prefijos o Sufijos para un

mismo significado.

Valores de Autorizacion en Aperturas

Por cada Apertura de Roles se deben especificar los valores de Autorizacion para los

Objetos de Autorizacion de los Roles aperturados.

Capıtulo 5

Construccion

Una vez obtenido el modelo se procede a la construccion del conjunto de Perfiles y Roles,

determinando los Perfiles funcionales a partir de los ”Workshops” y generando los Roles

a partir de los existentes en en Lienzo y los que necesitan ser agregados a la nueva

configuracion, respetando las normas establecidas en el modelo. La figura 5.1 muestra

el diagrama de actividades de la fase de Desarrollo, indicando las correspondientes

actividades de construccion ”Front End” y ”Back End”.

CreaciónPerfiles

ValidaciónLista dePerfiles

Creación Listade

Operaciones

AperturaPerfiles

Creación RolesLienzo y Nuevos

según NuevaNomenclatura

AmpliaciónRoles

Equivalentes

AperturaRoles

Creación Rutasde Acceso aOperaciones

Asignación deRoles a Perfiles

Desarrollo FE

Desarrollo BE

Figura 5.1: Diagrama de Actividades del Desarrollo

5.1 Creacion de Perfiles 47

5.1 Creacion de Perfiles

La creacion de los Perfiles se realiza creando un Perfil por cada Actor identificado en los

”Workshop”, luego se debe realizar las especializaciones requeridas segun el Nivel de

Impacto de las actividades que el Actor realiza dentro de la empresa. Se debe homologar

los puestos de trabajo en las Areas Manager de la empresa y las denominaciones de

Perfiles tanto como sea posible, para eliminar la redundancia de estas configuraciones.

En primer lugar se obtiene el listado con todos los Perfiles que requiere crearse,

revisarlos y contrastarlos con los puestos de trabajo actuales en cada una de las ”AM”,

Sociedades, Centros y sus dependencias. Para esta labor se contara con la ayuda de

Usuarios involucrados en el proyecto con el conocimiento necesario para validar la

informacion y consolidar la definicion de los Perfiles necesarios para la configuracion

del ”Desktop Integrado”.

La figura 5.2 muestra un diagrama de flujo de un subproceso de negocio donde

se puede identificar dos Perfiles de los que se hablara mas adelante. Otros actores

identificados, tales como personas, ambientes, empresas o cualquier otra instancia que

no usen SAP dentro del proceso no son tomadas en cuenta.

Modulo - COPerfil Fronted

Administrador de Datos MaestrosAnalista de Contabilidad IndustrialAnalista de Costos Jefe de Costos y Contabilidad IndustrialProyectos Sistemas CostosVisualización de Costos

La tabla de la izquierda muestra un

fragmento de los perfiles identificados

en los ”Workshop”, en este caso

el del subproceso de Revaluo de

Material. En este diagrama se

identifican dos Perfiles(resaltados en

amarillo) el Analista de Contabilidad

Industrial (ACI) y el Jefe de Costos y

Contabilidad Industrial.

Tabla 5.1: Fragmento - Perfiles identificados de los ”Workshop” (CO)

La tabla 5.1 muestra un fragmento de los perfiles identificados en los

”Workshop”, en este caso el del subproceso de Revaluo de Material. En este diagrama

se identifican dos Perfiles(resaltados en amarillo) el Analista de Contabilidad Industrial

(ACI) y el Jefe de Costos y Contabilidad Industrial, Perfil complementado en su nombre

5.1 Creacion de Perfiles 48


14

Entregable: SubProcesoSubproceso: 02.02.02 Revalúo de Materiales

Analista de Contabilidad Industrial (ACI)Exiros Jefe de Costos (JC)

Inicio

10-Verifica la necesidad de modificar el precio

estandar de un material.

20-Solicita al ACI que analice el impacto del

cambio de precios

30-Recibe la solicitud del Usuario y procede a

evaluar el impacto en el cambio de precios

40-Realiza simulación del cambio de precios.

50-Se cumplen

las normas requeridas por SOX?

Si

No 70-Se notifica que no se realizara los

cambios

60-Se envía solicitud de autorización al JC

80-Recibe la notificación del rechazo de la solicitud

por no cumplir con las normas SOX

90-Verifica y aprueba. Envia al ACI.

100-Recibe la autorización

100-Ejecuta programa de revalúo de materiales

110-Actualiza los nuevos precios

120-Se libera los precios futuros

130-Se contabiliza el importe calculado

en la revaluación

140-Se analiza los precios actualizados en el sistema. Fin

A

A

BB

Figura 5.2: Diagrama de Flujo de un subproceso de negocio en el modulo CO(FICO).

para adaptarse al puesto de trabajo real, cambio realizado al vuelo en el mismo proceso

de identificacion preliminar. La validacion se realiza en la siguiente etapa del desarrollo.

En algunos casos los ”Workshop” estaban aun en discusion, para lo que el

estudio de los Perfiles sirvio de apoyo para la toma de decisiones sobre la definicion

de los modelos. La figura 5.3 muestra un ejemplo de un subproceso aun no definido

de los Modulos MM y QM, el proceso de definicion preliminar de Perfiles continua en

estos casos, la validacion confirma la correctitud de la misma, al igual que en el ejemplo

anterior, la tabla 5.2 muestra los Perfiles identificados en el diagrama de flujo. En

estos casos se continua con el proceso de desarrollo colaborando con el documento de

diseno, dejando abierta la posibilidad de cambios tal como la polıtica de manejo del

cambio indica hacer en estos casos.

Las listas de Perfiles generadas fueron luego validadas con el equipo gerencial y

usuarios involucrados en el proyecto con criterio suficiente para identificar la correctitud

5.2 Validacion de Perfiles 49

9

Borrador para Discusión

Workshops del Modelo To-Be – Salidas AlmacénTernium

Flujograma

70 - Efectuar inspección de calidad de acuerdo al Plan

(opcional con lote Skip)

90 - Recibir muestra de material

110 - Realizar ensayos (análisis)

09.03.02. Procesamiento de

Resultados

09.03.02. Procesamiento de

Resultados

60 - Chequea pool de inspección

10 - Generación automática de lote de

inspección

No

40 – Asignar/Crear Plan de Inspección

50 - Asignar Plan de Inspección al Lote de

Inspección

80 - Envío muestra al laboratorio

Adjunta Lote Inspección

100 - Chequea pool de inspección

SiNo

30 - Mail automático para asignar plan de

inspección

Inspector calidadAdministrador Calidad LaboratorioRecepcionista Almacenes

09.01.02. Entrada de Material con Pedido con QM

¿Material c/vista QM

s/Plan Insp.?¿Inspección

en laboratorio?

20 – Bloqueo automático de factura

Si

Figura 5.3: Diagrama de Flujo de un subproceso de negocio en el modulo CO(FICO).

de los mismos.

5.2 Validacion de Perfiles

Una vez obtenida una lista preliminar de Perfiles por Modulos, se procede a validar

estos Perfiles con el Equipo Gerencial y Usuarios involucrados en el proyecto con criterio

suficiente para realizar esta validacion. El proposito de esta actividad es preparar los

Perfiles para las siguientes actividades del desarrollo. En esta actividad se busca:

• Verificar que los nombres de Perfiles representen los puestos de trabajo y su

actividad.

5.3 Creacion de Lista de Operaciones de Perfiles 50

Modulo - MMPerfil Fronted

Administrador Datos MaestrosInspectorJefe AlmacénPorteríaRecepcionista AlmacénSupervisor DespachoSupervisor CalidadSupervisor Recepción

La tabla de la izquierda muestra

algunos perfiles identificados en

”Workshop” que faltan por definir.

En estos casos se continua con el

proceso de desarrollo colaborando

con el documento de diseno, dejando

abierta la posibilidad de cambios tal

como la polıtica de manejo del cambio

indica hacer en estos casos.

Tabla 5.2: Fragmento - Perfiles identificados de los ”Workshop” (MM)

• Verificar que no queden puestos de trabajo involucrados con actividades SAP sin

definicion de Perfil (Perfiles no definidos por omision).

• Descartar Perfiles que en el nuevo modelo de Negocios no esten relacionados con

actividades SAP (Perfiles definidos por error).

• Dividir o Combinar Perfiles en los casos en que sea necesario.

Esta actividad consiste en reunirse con estos usuarios para corroborar, uno a

uno, los Perfiles definidos en el modulo correspondiente al dominio de conocimiento

de estos usuarios. En este proceso se pueden hacer modificaciones a los Perfiles segun

sea necesario, como ocurrio en el ejemplo de la tabla 5.1, con el objetivo de que

el conjunto de Perfiles sea una fiel representacion funcional del sistema en cuanto a

puestos de trabajo se refiere.

El resultado de esta actividad es un conjunto de Perfiles validados, listo para

empezar la actividad de definicion de operaciones de cada Perfil.

5.3 Creacion de Lista de Operaciones de Perfiles

En esta actividad se definen las actividades funcionales de un perfil, se les da un nombre

representativo a las operaciones Middleware y se relacionan a Transacciones SAP, luego

se les crean las rutas dentro de los Perfiles a las cuales correspondan.

5.4 Apertura de Perfiles 51

5.3.1 Creacion de una Operacion

Por cada actividad que realice un puesto de Trabajo o Perfil, se definen sus operaciones,

estas operaciones se nombran representativamente, para que sea facilmente identificable

por el usuario al momento de verla en su menu. Las Operaciones corresponden a

Transacciones en SAP Unificado que el usuario podra utilizar a traves de la interfaz

Middleware.

5.3.2 Creacion de una Ruta

El menu se estructura por Perfil y consta de Solapas de clasificacion de actividades por

Procesos de Negocio, las cuales desplegaran en la pantalla una serie de Items de acceso a

subprocesos mas detalladas. Los Items dan acceso a agrupadores de actividades clave

los cuales, como su nombre lo dice, agrupan operaciones que se relacionan entre sı.

Esta estructura se mostro en la tabla 4.10 y describe la relacion entre estos niveles de

detalle para la clasificacion de operaciones segun los Procesos de Negocios a los cuales

se refieren.

5.4 Apertura de Perfiles

El impacto de cada perfil se define en la apertura de los mismos, lo cual implica darle

una nomenclatura y un conjunto de valor de autorizacion acorde al nivel de impacto

que tiene dicho Perfil. El nombre de cada Perfil Aperturado cumplira con las normas

de nomenclatura definidas en el modelo. Los usuarios involucrados en el proyecto

manifiestan la necesidad y validan la pertinencia de cada apertura.

5.5 Creacion de Roles

Los Roles del sistema Unificado se crean a partir de los Roles del sistema Lienzo,

respetando la nueva polıtica de nomenclatura. Los Roles ”Legacy” que no tuvieron

Roles Equivalentes en el sistema Lienzo y son necesarios para el nuevo sistema se usan

para crear nuevos Roles en el Sistema Unificado respetando tambien la polıtica de

5.6 Ampliacion de Roles 52

nomenclatura definida.

5.6 Ampliacion de Roles

Los Roles Equivalentes Lienzo son complementados con las informaciones y

configuraciones de cuyos Roles ”Legacy” Equivalentes requieren para dar funcionalidad

a los usuarios en el sistema.

5.7 Apertura de Roles

Segun los niveles de impacto requeridos para cada Rol, se define un nuevo Rol indicando

su Nivel de Impacto con los respectivos sufijos tal como lo define la polıtica de

nomenclatura.

5.8 Asignacion de Roles a Perfiles

Una vez definido el conjunto de Roles y Perfiles, se procede a relacionar estos dos

conjuntos. El relacionamiento consiste en, por cada Perfil que describe un puesto de

trabajo, se le asignan los Roles SAPU que requiere para operar el sistema.

Este documento, donde se plasma la relacion Perfiles - Roles y las informaciones

de configuracion de cada uno de ellos, constituye el Documento de Definicion de

Perfiles de Seguridad Informatica, documento que se utilizara el equipo de Seguridad

Informatica de Ternium para asignar estos Perfiles a Usuarios basados en la Polıtica

de Seguridad Informatica.

Capıtulo 6

Pruebas

El proyecto SAP Unificado, elabora una estrategia de pruebas de integracion llamadas

Pruebas Integrales, el desarrollo de estas no forman parte del alcance este proyecto

pero se utilizan para probar la correctitud del mismo.

El proyecto SAP Unificado define dos periodos de pruebas, llamandolos Fase

de Pruebas Integrales I y II. En cada fase se prueban cada una da las actividades

del sistema SAP Unificado, con usuarios de prueba que usaran las configuraciones de

Seguridad Informatica construidas en este proyecto.

La configuracion de servidores SAP en el proyecto SAP Unificado consta de

un ”Landscape” de cuatro servidores, uno de desarrollo, dos de aseguramiento de la

calidad y uno productivo, donde reposara el sistema validado e implementado.

En uno de los servidores de aseguramiento de la calidad se utiliza la

configuracion de seguridad informatica construida en este proyecto y conjuntamente

con las aplicaciones desarrolladas por el proyecto SAPU se prueba el sistema en su

conjunto.

Las incidencias o errores en la implementacion de prueba son tratadas por el

equipo a que corresponda, siendo las incidencias relacionadas con seguridad informatica

las correspondientes al proyecto de Reingenierıa de Perfiles.

Los tipos de incidencias pueden ser:

• Falla de autorizacion para transaccion: la operacion aparece pero no puede ser

invocada por falta de autorizacion para llamar a la transaccion.

6 Pruebas 54

• Falla de autorizacion para modificar o visualizar datos: faltan las autorizaciones

necesarias para tratar datos en el Nivel de Impacto respectivo.

• Falta la operacion: la operacion falta en el Perfil (no aparece).

Todas estas incidencias se tratan, se corrigen y se llevan a prueba nuevamente

para su validacion y cierre.

Luego de concluidos los periodos de prueba y se hayan probado todos los

Procesos de Negocio del Sistema y se hayan validado, se procede a la fase de

implementacion.

Capıtulo 7

Implementacion

Una vez definidos, construidos, probados y validados los conjuntos de configuraciones

de Seguridad Informatica para SAP Unificado, se procede a implementar el sistema,

siguiendo la polıtica de asignacion de Perfiles a Usuarios la cual se describe a

continuacion.

Basados en los siguientes predicados:

• Todo Perfil define un puesto de trabajo

• Todo Usuario tendra uno o varios puestos de trabajo

• Las actividades de un usuario tienen un Nivel de Impacto.

Se define la siguiente polıtica de asignacion de Perfiles a Usuarios:

• Para cada Usuario se asignan los perfiles correspondientes a sus puestos de trabajo

con los Niveles Impacto pertinentes.

• En caso de modificaciones, estas se realizaran a nivel de Perfiles, removiendo el

previo en su totalidad y asignando el nuevo y sus configuraciones.

• Se deben verificar los Roles correspondientes a los Perfiles que el Usuario posee

con la configuracion documentada luego de cada modificacion.

7 Implementacion 56

• En caso de haber modificaciones internas a Perfiles, estas se propagaran a todos

los Usuarios que los posean y deberan ser documentadas en el Documento de

Definicion de Perfiles de Seguridad Informatica.

• Se elimina la asignacion de Perfiles por Usuario Modelo o Referente.

Siguiendo la polıtica de Seguridad Informatica descrita arriba, se procede a

asignar a cada Usuario los perfiles que les corresponden, comenzando con los puestos

de mayor jerarquıa a la menor jerarquıa, siendo los Usuarios designados por el equipo

gerencial en cada nodo del organigrama los responsables por la asignacion de Perfiles

a los Usuarios subalternos inmediatos, continuando con el mismo proceder hacia abajo

en dicho organigrama, hasta cubrir la totalidad de los empleados Usuarios del nuevo

sistema SAP Unificado.

Se transporta desde el servidor de pruebas el conjunto de los Roles Probados y

validados hacia el servidor SAP Unificado. De igual manera se copia la configuracion

de Perfiles y Rutas de operaciones desde el ”Front End” de pruebas al ”Front End”

que prestara servicio al sistema SAP Unificado Productivo, al cual los Usuarios reales

accederan para realizar sus actividades rutinarias.

Capıtulo 8

Conclusiones

En base a los resultados obtenidos en este proyecto, los objetivos del mismo fueron

alcanzados satisfactoriamente, teniendo un nuevo conjunto de Roles para el sistema

SAP Unificado, mas de nueve mil Roles fueron validados y transportados desde el

servidor de pruebas al servidor de Productivo, el conjunto de Perfiles de la Interfaz

Middleware, que daran acceso a los usuarios del nuevo sistema a sus actividades

cotidianas en el mismo, centenares de Perfiles que se copian del ”Front End” de pruebas

al ”Front End” Productivo, miles de Usuarios poseen una nueva configuracion, segura,

confiable, estable y robusta en el tiempo gracias a la nueva Polıtica de Seguridad

Informatica.

A la culminacion de este proyecto se tiene, aparte de los productos definidos

en los objetivos, una metodologıa exitosa para afrontar este tipo de configuraciones de

sistemas de gestion empresarial de gran escala, un documento de referencia para futuros

proyectos similares en el que se afrontaron una gran cantidad de problemas comunes

a este tipo de sistemas y configuraciones, un conjunto de experiencias y herramientas

utiles, aplicando conocimientos de Sistemas Computacionales durante su desarrollo

para dar un producto. El producto de nuestro ingenio humano y la razon de ser de los

Ingenieros en cualquier rama: una solucion ingeniosa y correcta.

Mi experiencia personal y profesional fue muy enriquecedora, logre formarme

como Ingeniero al afrontar los problemas planteados aplicando todos los conocimientos

y tecnicas adquiridas durante mi formacion academica, junto con nuevos conocimientos

8 Conclusiones 58

adquiridos al calor del trabajo cotidiano en este proyecto, experiencia que no solo tuvo

que ver con temas especıficos de sistemas, sino que me forzaron a ser un profesional

integral, comunicativo, eficiente, eficaz, responsable, tolerante y comprensivo ante la

diversidad cultural de las personas, irıa mas alla al decir fascinado por la misma.

Recomiendo este tipo tipo de experiencias a todos los aspirantes a profesionales, de

cualquier ambito, establecer contacto con el ambiente real de aplicacion y trascender

en el entender de que hay una diferencia entre conocer el camino y recorrerlo. ”Hemos

cumplido”.

Bibliografıa

[1] Roger S. Pressman. Ingenierıa del Software - Un enfoque practico. 2006.

[2] Portougal Victor - Sundaram David. Business Processes: Operational Solutions for

SAP Implementation. 2006.

[3] Torres Torres Francisco. Presentacion SAP Unificado. Octubre 2007 v3.

[4] http://es.wikipedia.org/wiki/Middleware/

[5] http://www.uml.org/

[6] SAP R/3 Ayuda del sistema SAP R/3. SAP R/3 SAPGUI 640.

Reingeniería de Perfiles de Seguridad Informática de SAP ...

Documents

Transcript of Reingeniería de Perfiles de Seguridad Informática de SAP ...