reingeniería de perfiles de seguridad informática de sap
TRANSCRIPT
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
MANTENIMIENTOMANTENIMIENTO
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
MANTENIMIENTOMANTENIMIENTO
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
1.7 Metodologıa adaptada 9
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
1.7 Metodologıa adaptada 10
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
4.3 Modelo de equivalencias entre Roles 26
• 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.
4.3 Modelo de equivalencias entre Roles 27
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.
4.3 Modelo de equivalencias entre Roles 28
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
4.3 Modelo de equivalencias entre Roles 29
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.
4.3 Modelo de equivalencias entre Roles 30
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).
4.5 Modelado ”TO-BE” 33
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.
4.5 Modelado ”TO-BE” 34
Etapa de Diseño del Modelo To-BeTernium
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
Proceso: 12.02 Gestión de avisos y órdenes Subproceso: 12.02.08 Cierre de la orden
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.
4.5 Modelado ”TO-BE” 35
Etapa de Diseño del Modelo To-BeTernium
3
Proceso: 12.02 Gestión de avisos y órdenes Subproceso: 12.02.08 Cierre de la orden
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.
4.5 Modelado ”TO-BE” 36
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:
4.5 Modelado ”TO-BE” 37
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.
4.5 Modelado ”TO-BE” 38
• 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.
4.5 Modelado ”TO-BE” 39
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.
4.5 Modelado ”TO-BE” 40
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.
4.5 Modelado ”TO-BE” 41
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
4.5 Modelado ”TO-BE” 42
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.
4.5 Modelado ”TO-BE” 43
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.
4.5 Modelado ”TO-BE” 44
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
4.5 Modelado ”TO-BE” 45
– 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
Etapa de Diseño del Modelo To-BeTernium
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.