miércoles, 21 de enero de 2009

Nuevo dominio para el Blog

El blog continuará en funcionamiento en una nueva dirección www.seguridadsap.com donde comenzará una nueva etapa con artículos periódicamente actualizados.

Muchas gracias.

Siganos en www.seguridadsap.com

Agregar a Del.icio.us - Meneame - Google Reader

viernes, 15 de junio de 2007

¿Qué es SAP Solution Manager?


Muchas veces también conocido con nombre de superheroe, SolMan ;-), es una nueva herramienta que está comenzando a ser adoptada por varias compañías que ya disponen de alguna instalación de SAP, de forma de plasmar sus procesos de negocios y la documentación respaldatoria de los mismos en ella. Actualmente se encuentra en la versión 4.0

En las nuevas implementaciones de SAP ECC, se está utilizando la herramienta como "puerta de acceso a la parametrización de SAP".

¿Qué quiero decir con esto?

Solution Manager nos permite vincular "pasos de nuestros procesos" con "pasos de configuración". De esta manera en una implementación, un usuario define el modelo de negocio, y luego se vinculan los puntos de customizing y transacciones afectadas por este proceso, de manera de que "la teoría concuerde con al práctica".

Este es uno de los usos más típicos que se le da a Solution Manager, además de repositorio de la documentación vinculada con los pasos de configuración que mostramos más arriba. La herramienta apunta a ser una solución mucho más amplia, incluyendo manejo de BCSets, Administración de Transportes, Material de Capacitación, Administración de helpdesk (tiene incluidas funciones del CRM de SAP), Evaluación del proyecto, y Herramientas de Testing entre otras funciones avanzadas, desarrolladas por ahora con distinto grado de madurez.

SAP está intentando imponerlo como un estándar en todas sus implementaciones, y busca que sea un estándar de facto para todos sus clientes, y futuros clientes, de manera de ir ordenando un poco los ambientes de desarrollo caóticos que suelen ser una constante en muchas implementaciones.

Ojalá esté en el camino indicado...
Más info:

Agregar a Del.icio.us - Meneame - Google Reader

martes, 29 de mayo de 2007

¿Como funciona SAP? Logon y Mandantes

En la anterior entrada de este blog, explicamos como era un landscape típico de SAP, pero nos quedaron pendientes un par de cuestiones necesarias para entender como funciona SAP.

Una de ellas es la respuesta a ¿Qué es un mandante?

Ya vimos que básicamente pueden existir tres ambientes (Desarrollo, Calidad, y Producción) y para que servían cada uno de los mismos. Ahora podemos ahondar un poco más...

Los ambientes dijimos que normalmente están ubicados en equipos (computadoras/servidores) distintos, cada ambiente en su respectivo servidor (generalizo para simplificar), el hecho es que cada ambiente, o sistema puede a su vez contener otras divisiones dentro de si mismo.

A modo de ejemplo, un ambiente de desarrollo, puede contener una subdivisión que sea la que va a poseer las parametrizaciones propiamente dichas, otra que haga las veces de ambiente de pruebas unitarias (para que los mismos desarrolladores o parametrizadores prueben el funcionamiento de lo que definen), etc

Estas subdivisiones se llaman Mandantes en SAP

Los mandantes poseen nombres numéricos, siendo a modo de ejemplo un ambiente de SAP de nombre DEV (por Development), y mandante 200, otro mandante en el mismo equipo puede ser UNI (por Pruebas Unitarias) y mandante 210. Otro ambiente puede ser QAS y el número de mandante el 300, y el ambiente productivo PRD y mandante 400.

Los mandantes poseen maestros de usuario distintos, esto quiere decir que en un mismo sistema (DEV) un usuario puede tener acceso al mandante 200 pero no al 210, o puede acceder a los dos pero con distintos permisos.

La información operativa que se cargue en un mandante no es compartida con el otro, a pesar de que la información por pertenecer a un mismo sistema, se aloja en una misma base de datos. Las tablas con las que trabaja SAP poseen normalmente un indicador de mandante, por lo que SAP siempre lee este campo primero y solo muestra la información del mandante en el cual el usuario se autenticó. Estas tablas se llaman tablas DEPENDIENTES de mandante.

Existen otras tablas especiales, con datos de configuración del sistema en su mayoría que son llamadas INDEPENDIENTES de mandante, y que son compartidas por todos los mandantes de un mismo sistema. Espero en una próxima entrada poder ejemplificar esta información con un paso a paso en SAP, para que puede quedar más claro. Mientras tanto no duden en preguntar en los comentarios del post que cualquier cosa les voy a contestar.

Pero ahora, cuando les digan: "Entrá a DEV al mandante 210 y fijate un poco que hay por ahí..." por lo menos van a tener una idea de les están hablando...

En una próxima entrada vamos a ver un ejemplo práctico de ingreso a SAP y seguiremos viendo algunos conceptos básicos como ser las Transacciones.

Agregar a Del.icio.us - Meneame - Google Reader

martes, 15 de mayo de 2007

¿Cómo funciona SAP? Landscape y Ambientes

En la primera parte de este post vimos una breve introducción al landscape típico de SAP ERP, y algunos conceptos de software en 3 capas y cliente/servidor.

Ahora vamos a continuar extendiendo la definición de landscape que vimos antes, incorporando un par de conceptos adicionales a los que ya vimos.

Hasta ahora vimos como es un landscape de SAP ERP con un único sistema, pero la realidad es que esto no cubre las necesidades de una organización promedio. ¿Por qué? Porque este sistema es solo un ambiente productivo.

¿Qué es un ambiente productivo?
Es el ambiente donde la empresa opera, y sobre el cual se realizan todas las operaciones diarias de la organización, contiene toda la información sobre compras, pagos, cobranzas, contabilidad, etc y al mismo acceden los usuarios de las áreas específicas (Depto de Contabilidad, Tesorería, RRHH, etc)

¿Qué otros ambientes necesitamos?
Una empresa promedio se encuentra constantemente realizando mejoras sobre su software, reparando errores, o en pos de implementar nuevas funcionalidades. Nos puede parecer correcto o incorrecto, pero esto es así cuando se trabaja con grandes ERPs.

Para conseguir esto un landscape típico sería:

- Un ambiente de desarrollo donde acceden los parametrizadores (consultores de producto) y desarrolladores (programadores ABAP o JAVA) que no posee información del trabajo diario de la organización.
- Un ambiente de Calidad al que acceden los consultores de producto, consultores funcionales, y usuarios para probar el correcto funcionamiento del programa o funcionalidad configurada en el ambiente de desarrollo pero sin alterar los datos del día a día de la organización, con datos de prueba no críticos o censurados.
- Un ambiente de Producción donde los consultores y desarrolladores no acceden, salvo en casos particulares y solo como visualización, y es en donde la organización posee sus datos operativos y al que acceden todos los usuarios finales del sistema.

Este landscape es propio de un sistema SAP en producción (cuando ya opera para la empresa) en el caso de las implementaciones en las que participan habitualmente los consultores el ambiente puede solo contener el Ambiente de Desarrollo en una primera etapa, y posteriormente para la llegada de las pruebas integrales suele incorporarse el Ambiente de Calidad, y finalmente cerca de la fecha de implementación el Ambiente Productivo.

Más adelante vamos a escribir un poco sobre como es la estructura de un proyecto de implementación de SAP, pero en los próximos post pueden esperar encontrar respuestas a temas como:

¿Qué es un mandante?
¿Entorno de trabajo y Transacciones?
¿Qué es el sistema de transporte de SAP?

Agregar a Del.icio.us - Meneame - Google Reader