Anteriormente hablamos sobre
qué es IdM, por qué es necesario ,
cómo corroborar financieramente su implementación , etc. Hoy hablaremos sobre las dificultades que pueden surgir durante la implementación del sistema, y cómo sortearlas y no obtener muchos conos. Supongamos que sabemos que en nuestra empresa hay algunos problemas que podríamos y nos gustaría resolver con IdM. La solución a estos problemas en nuestra empresa está económicamente justificada, ya que aliviará seriamente al departamento de TI, aumentará los indicadores de rendimiento de la empresa en su conjunto al ahorrar tiempo y recursos necesarios para preparar el espacio de trabajo para los nuevos empleados y coordinar y administrar los poderes de los antiguos. Y los empleados de IS después de la introducción de IdM estarán en el séptimo cielo, generando una tonelada de diversos informes sobre el botón, lo que simplificará enormemente sus vidas al realizar auditorías de seguridad, para el deleite de ellos y la administración. Y se tomó la decisión: "¡Toma!".
Formulamos requisitos funcionales
Lo primero que debe hacer es redactar un documento llamado "Requisitos funcionales". Creo que la importancia de la disponibilidad y alfabetización de los contenidos de este documento está fuera de toda duda. Idealmente, debería estar listo antes de elegir una solución específica. Está claro que durante las pruebas piloto y durante los eventos de preventa muchas veces, se discutió a diferentes personas y se les explicó lo que había que hacer. Sin embargo, el alcance del proyecto debe estar claramente definido y fijado en papel. Los requisitos funcionales son una especie de punto de partida desde el cual se construirá un entendimiento mutuo entre todos los participantes en el proceso, tanto por parte del cliente como del contratista.
La funcionalidad del sistema requerida debe justificarse lógica y financieramente, implementarse y ser coherente con sus capacidades. Esta es esencialmente una descripción de nivel superior de los procesos comerciales que necesitan ser automatizados mediante la implementación de IdM.
Considere un ejemplo simple para mayor claridad.
Imagine que necesita automatizar los siguientes procesos de personal:
- Admisión de un nuevo empleado (creación de cuentas con derechos primarios, según el puesto y la unidad).
- Solicitud de nuevas credenciales para empleados (coordinación, ejecución automática y semiautomática de aplicaciones).
- Transferencia de un empleado a un puesto (emisión de poderes correspondientes a un nuevo puesto, confirmación o revocación de antiguos poderes).
- Despido de un empleado (bloqueando todas sus cuentas con el retiro de todos los roles).
En los requisitos funcionales para el proceso de
aceptación de nuevos empleados , vale la pena escribir lo siguiente: el
sistema lee información sobre el nuevo empleado del sistema de personal, crea una cuenta en Active Directory (AD), asigna los grupos necesarios por posición, crea una cuenta en CRM, asigna un perfil y roles de acuerdo con los deberes oficiales.No es necesario ingresar allí el requisito de preparar café al CEO cuando ingrese a la oficina. Esta no es una función IdM, aunque con una API, la cafetera también es realizable :)
Dibujamos un diagrama de la interacción de los componentes del sistema.
En esta etapa, además de los procesos realmente automatizados, se identifican los principales sistemas integrables, se identifican los departamentos interesados y se estima el lugar de IdM global en el entorno de información interna de la empresa. También se determinan los recursos necesarios para soportar IdM, se hace visible el alcance del proyecto, se determinan aproximadamente las etapas y las fechas de implementación.
Entonces, nos dimos cuenta de que para la implementación de estos procesos automatizados en la primera etapa, debe integrarse con solo tres sistemas:
- con el sistema de personal 1C: ZUP,
- con Microsoft Active Directory como el proveedor principal de privilegios de usuario en la infraestructura empresarial,
- con el sistema comercial principal de CRM escrito y mantenido por un proveedor externo bajo el pedido.
Debe imaginar de inmediato el esquema de interacción de los componentes del sistema futuro.
Como puede ver, IdM está en el centro, y esto no es una coincidencia. Después de la implementación, IdM será el "alfa y omega" que contiene toda la información relevante sobre los empleados de la compañía, todas sus cuentas en sistemas integrados IdM y qué roles, grupos y autoridades deben tener los empleados en estos sistemas. Es gracias a los "tentáculos" de IdM que penetran en todos los sistemas conectados con él que la transferencia de Ivanov Sergey Petrovich del departamento de contabilidad al departamento legal de la compañía registrada automáticamente en el sistema de información del personal cambiará automáticamente los grupos y atributos de su cuenta en AD y cambiará sus roles y perfiles en otros sistemas de la compañía, con el lanzamiento automático de todos los procesos necesarios de aprobación y notificación. Pero todo esto funcionará solo cuando todos los componentes del sistema estén bien y correctamente integrados entre sí. Y para que esto suceda, repito, debe pensar detenidamente y diseñar todo.
Con este equipaje salimos a comprar.
Entonces, se selecciona la solución IdM, se define el contratista de implementación, se compran las licencias, se paga el trabajo, es hora de implementarlo. Hablaremos más sobre cómo asegurarnos de que todas las buenas empresas no mueran, sin haber nacido realmente.
Creamos un equipo de proyecto y hacemos una encuesta previa al proyecto.
Lo primero que debe hacer inmediatamente después de comprar IdM (sin contar el aumento solemne del cristal para el acuerdo) es crear un equipo de proyecto. Sí, el
equipo del
proyecto por parte del cliente debe serlo. El éxito de todo el evento depende de su composición. Debe incluir representantes de todos los departamentos interesados que
tengan los poderes necesarios y suficientes para resolver rápidamente varios problemas de naturaleza predominantemente técnica que surgen durante la implementación.
Luego viene el momento de la encuesta previa al diseño , la etapa más importante, que requiere una gran inmersión en las actividades de diseño principalmente del cliente.
Aquí, los poderes muy necesarios y suficientes de los participantes del equipo de proyecto del cliente deberán recopilar y proporcionar al contratista toda la información necesaria sobre la estructura interna de los procesos de la empresa. ¡Se trata de la estructura interna de los procesos de la empresa! Cada proceso automatizado descrito en los Requisitos funcionales debe investigarse a fondo de principio a fin. ¿Quién lleva a cabo la recopilación inicial de información, su composición y formato, en qué sistema se ingresa la información, en qué se transmite, cómo, por qué protocolos, con qué software? Quién necesita esta información para otras actividades y en qué forma la necesita, dónde debe haber rastros de las operaciones realizadas ... En una palabra, todo, todo, todo lo que concierne a cada proceso investigado.
Escribimos TK
En el resultado de la encuesta previa al proyecto, se debe obtener un documento más importante desde el punto de vista de la implementación (incluso más importante que los requisitos funcionales): los
Términos de Referencia (TOR). ¿Qué debería haber en él? Es importante no perderse nada y pensar detenidamente en todo. Porque la omisión de matices pequeños y aparentemente insignificantes puede dar lugar a grandes problemas durante la implementación.
En este sentido, al diseñar una solución de implementación en TK, lo primero que debe hacer es resolver a fondo los procesos automatizados. Casi lo mismo que en los requisitos funcionales, pero con más detalle, con detalles específicos, que cubren todo el ciclo de vida de la información que ingresa a la entrada de cada proceso hasta que sale.
Por ejemplo, el proceso de personal. La
admisión de un nuevo empleado en los Términos de Referencia se verá así:
- Un empleado de recursos humanos ingresa información sobre un nuevo empleado en el sistema 1C: ZUP HR. Los rellenos obligatorios en los siguientes campos: ... (se enumeran cuáles).
- IdM recibe datos sobre un nuevo empleado del sistema de personal 1C: ZUP, determina el puesto y la unidad del nuevo empleado. Crea un nuevo perfil de empleado en IdM. El inicio de sesión se forma de acuerdo con tales y tales reglas, la contraseña de acuerdo con tal y tal. La información de inicio de sesión para la contraseña del nuevo empleado se envía allí y a través de dichos canales de comunicación (indique de dónde obtiene IdM la dirección).
- IdM crea automáticamente una cuenta en AD con los atributos (lista) en el directorio (OU - Unidad de organización) correspondiente a la unidad del nuevo empleado. El inicio de sesión se forma de acuerdo con tales y tales reglas, la contraseña de acuerdo con tal y tal. Los datos sobre el inicio de sesión y la contraseña del nuevo empleado se envían allí y allá a través de dichos canales de comunicación (indique de dónde obtiene IdM el destinatario y los parámetros del canal de comunicación).
- La cuenta de AD creada se coloca en grupos (enumeramos o indicamos "según el modelo a seguir"). El modelo a seguir también deberá ser pensado y descrito en un ToR en un capítulo separado. El nombramiento de dichos grupos se lleva a cabo de acuerdo con esas personas (enumeramos). El sistema genera notificaciones sobre la asignación de autoridad a un nuevo empleado (especifique el algoritmo de identificación del destinatario; describa por separado las rutas de aprobación), así como recordatorios al coordinador sobre la necesidad de coordinar la aplicación (especifique los algoritmos de identificación del destinatario, inicio, finalización y frecuencia de los recordatorios).
- Después de crear una cuenta en AD, IdM inicia la creación de un buzón de Exchange para el nuevo empleado. La información sobre el nuevo buzón se almacena en IdM y se muestra en la tarjeta del empleado.
Aproximadamente en la misma línea, describimos la interacción del sistema con CRM ...
Por lo tanto, durante la consideración de los procesos automatizados de esta manera, el modelo de objetos de cada sistema, la composición de los atributos de cada tipo de objetos se vuelve clara, se forma una imagen del movimiento y la transformación de datos entre los atributos de varios objetos. Además, las conexiones entre los objetos se hacen visibles, se revelan procesos adicionales, como mantener la consistencia de los datos en todos los sistemas.
Un ejemplo simple: al cambiar el nombre del empleado en el sistema de personal, su nombre debe cambiar en los perfiles de todos los demás sistemas conectados a IdM. Pero puede que no cambie, porque en algunos sistemas el nombre simplemente no se almacena.
Un ejemplo es más complicado: el requisito es que la cuenta AD de un nuevo empleado debe crearse en la unidad organizativa correspondiente a su unidad. Surge la pregunta, ¿qué hacer si se establece una nueva unidad en el sistema de personal, pero aún no se ha creado en AD? Por lo tanto, se revela un proceso separado de reproducción de la estructura organizacional almacenada en el sistema de personal en AD, que también vale la pena describir en los TdR.Se integra con los sistemas.
Como puede ver, la formación de TK es un proceso iterativo. Después de identificar los objetos y las acciones que deben realizarse con ellos, queda claro el conjunto de funciones que deben implementarse en el conector del sistema integrado. Y aquí nos acercamos sin problemas a otra etapa importante de la implementación de IdM: la
integración real
con los sistemas . En verdad, esta etapa puede ser muy dolorosa tanto para el integrador IdM como para la compañía en cuya infraestructura se está implementando IdM.
Para que no pase nada malo, debe comprender algunos principios generales que se aplican al integrar varios productos de software. Primero, debe comprender la importancia de tener una API en un sistema integrado para integrarse con IdM. El conector y la API son dos cosas diferentes. Si el integrador dice que tiene conectores para varios sistemas o está listo para escribir un conector en cualquier sistema, esto no significa que el problema de integración esté completamente resuelto y que la compañía del cliente no necesite hacer nada al respecto.
Lo explicaré con un ejemplo. Para conectar una planta de energía con una plancha con el fin de calentarla con el fin de realizar sus funciones conocidas, es necesario que la estación de energía tenga un enchufe y la plancha tenga un enchufe. Enchufe y enchufe. 2 cosas No uno Usando una toma de corriente en el lado de la estación de energía y un enchufe en el lado de la plancha, la plancha se integra con el sistema de energía. En el caso de la integración de IdM con cualquier otro sistema, también se necesitan 2 cosas: un conector en el lado de IdM y una API en el lado del sistema. Esto es importante! De lo contrario, pueden ocurrir varios incidentes desagradables. El propósito del conector es solo recibir los datos necesarios del sistema en la forma en que los envía, y transferirlos a IdM en la forma en que IdM puede recibirlos. El mismo conector lo hace en la dirección opuesta: recibe un comando y un conjunto de datos de IdM en la forma en que IdM los emite, y transfiere todo esto al sistema en la forma en que el sistema comprende lo que debe hacer. PERO! El sistema debería, en principio, ser capaz de producir los datos necesarios para IdM y ejecutar los comandos necesarios para trabajar en conjunto con IdM. Este es el objetivo principal de la API: proporcionar una interfaz en la que IdM pueda actuar con un conector para realizar diversas operaciones en el sistema.
Por lo general, incluso antes de la venta de IdM, un integrador concienzudo se centra en la
necesidad de que el cliente proporcione una API para todos los sistemas conectados a IdM e informa los requisitos para la implementación de estas API. Esto es esencialmente una enumeración de funciones con parámetros de entrada y salida. Por ejemplo:
- Busca todas las cuentas del sistema. No hay parámetros de entrada. El resultado es una lista de todas las cuentas con todos sus atributos.
- Busque una cuenta por ID. El parámetro de entrada es el identificador del ultrasonido. Cerrar sesión: una cuenta que cumple con los criterios de búsqueda, con todos los atributos.
- Crea una cuenta. Parámetros de entrada: inicio de sesión, contraseña, nombre completo ... Salida: identificador del nuevo ultrasonido.
- Bloqueo de cuenta. Parámetros de entrada: identificador de ultrasonido. No hay parámetros de salida.
- Y así sucesivamente ...
Es decir, una API es un conjunto de funciones necesarias para interactuar con IdM. El problema es que parte de estas funciones en el sistema pueden no implementarse en la forma correcta. Solo porque esto aún no era necesario. Parte puede implementarse, pero como un proceso complejo, de varios niveles, paso a paso.
Por ejemplo, en un sistema automatizado de banca nacional, la creación de una cuenta de usuario está precedida por completar tres directorios diferentes con un conjunto de atributos y banderas auxiliares. O bien, algunas funciones pueden implementarse de forma simple, pero no publicadas, es decir, las funciones no pueden usarse desde el exterior. Entonces, la API está diseñada para resolver todos estos problemas. Las API son funciones que realizan las operaciones necesarias para la integración de un sistema integrado con IdM, en la forma correcta y correcta, publicada para su llamada externa. Para que cualquier ingeniero de software que no conozca la cocina interna del sistema mismo pueda usarlos y hacer fácilmente lo que necesita.
Entonces, como regla, surge la pregunta para los clientes, lo que causa un dolor de muelas persistente para un ingeniero de implementación de IdM: ¿por qué un integrador de IdM no puede implementar un integrador de API por sí solo?
Imagine un complejo sistema de gestión empresarial en el que la gestión de derechos de usuario ahora debe implementarse utilizando IdM. El vendedor escribió este sistema desde los años 90. Durante una larga vida, su arquitectura ha cambiado cuatro veces. El subsistema de gestión de derechos de usuario no pudo mantenerse al día con el rápido desarrollo del funcionamiento del sistema en sí mismo y fue implementado por varias generaciones de programadores de acuerdo con su comprensión no siempre lógica y razonable de acuerdo con el principio de "cómo lo descubrí yo mismo", es decir, de manera muleta. No hay necesidad de hablar sobre documentar toda esta acción. Por el momento, todo está funcionando de alguna manera. Los empleados del vendedor se suben al antiguo código de su sistema con reticencia y aprensión solo en caso de necesidad urgente de corregir algún error terrible, bautizando tres veces y rociando el monitor con agua bendita, cubierto con panderetas, por lo que Dios prohíbe no romper ninguna muleta, para que no se caiga todo .
Y ahora, la compañía del cliente que usa este producto mágico ha llegado el momento de oro para implementar IdM. Requisitos de API proporcionados, sin API. Al cliente no le importa quién escribirá la API. Golpeó el puño sobre la mesa con las palabras "Estoy llorando a millones, hazlo" y salió de la reunión, cerrando la puerta deliberadamente. Al vendedor de software mágico tampoco le importa. No va a hacer nada gratis, pero se olvidaron de poner dinero en el presupuesto para la implementación de la API para vívidos sueños de arcoíris sobre cómo todo será genial después de la introducción de IdM. Al mismo tiempo, se firma el contrato, "se ha pagado el dinero", y comienza el salto salvaje.
El pobre programador Pasha, empleado del integrador de IdM, está tratando de comprender de manera convulsiva qué se deben hacer sentadillas para obtener reacciones normales del sistema. Estudia fuentes públicas, documentación tacaña y desactualizada, comprende el código fuente de un sistema desconocido y rompe los teléfonos del proveedor. , , , , , … , -, - . , . - , . , – , «» . , «» . «» «???», « !», «, …» , -. , - -, IdM .
? ? , , , , , ? IdM'? , , ? , ? , ; , , API. . - – , ( , , IT- ) , . . , . - :D. . !
. , «» – , . , , , , , , . … , . , AD , . . SAP'? .
, . .
IdM, , , , IdM. . . , .
:
, , . , : , , . : – 50% . , , , . IdM, .
. .
, Solar inRights