Antes de implementar la aplicación, se debe definir un entorno para la implementación. Este entorno es necesario para separar los datos entre diferentes entornos posibles, como «Life System», «Integration System», «Test System», «Presentation System», etc., que podrían implementarse en el mismo hardware. Por lo tanto, debe definirse la «entidad propia» del banco. La administración se lleva a cabo mediante entradas en la base de datos y ajustes independientes que se gestionan a nivel de asistente.
Para organizar el trabajo en grupo, es posible definir grupos de usuarios que son responsables de determinados sectores de negocio o partes de ellos. Si no se ha definido ningún grupo de usuarios, la definición de la «entidad propia» es válida para todos los usuarios.
Además, información como direcciones de oficinas regionales y sucursales que deben aparecer en la correspondencia, impresoras, etc. se pueden almacenar por separado en la base de datos.
Por último, el usuario único debe introducirse en el sistema. La administración de usuarios facilita el acceso a elementos definidos de la aplicación, así como a la base de datos. La definición del usuario también refleja el perfil de usuario asociado al uso correspondiente, como los derechos de acceso, el derecho a autorizar transacciones, etc.
La estructura anterior puede adaptarse durante la implementación para satisfacer los requisitos y necesidades de todos los bancos.
Antes de poner en marcha la aplicación, recomendamos probar primero el sistema.
La siguiente lista de comprobación ofrece una visión general de los diversos pasos en los que se deben tomar decisiones y en los que el banco debe realizar los preparativos.
| N.o de artículo | Título académico | Observaciones |
|---|---|---|
| 1 | Entorno del sistema | Configuración del hardware, sistema operativo y sistema de base de datos |
| 2 | Sector de Negocios | Selección de sectores de negocio disponibles en la aplicación |
| 3 | Interfaces | Definición de interfaces (libro mayor, SWIFT, Telex, Trade Connect, etc.) que deben ser compatibles con la aplicación |
| 4 | Data Estática | Determinación de los datos estáticos que se almacenarán en la aplicación (teniendo en cuenta las actualizaciones automáticas de la base de datos con datos externos y la descripción de la interfaz para descargas). |
| 5 | Transacciones comerciales actuales | Dada la presencia de transacciones comerciales existentes, es necesario tomar decisiones sobre cómo proceder con ellas. |
| 6 | Impresión | Definición de cómo deben gestionarse las impresiones |
| 7 | Derechos de acceso de los usuarios | Definición de los diferentes perfiles de usuario, incluidos los perfiles de grupos de usuarios |
| 8 | Calendario | Definición de hitos para las pruebas y la implementación |
| 9 | Documentos | Preparando documentos para ser creados como correspondencia de resultados |
La planificación detallada y las decisiones sobre los diferentes pasos se toman en colaboración con su personal de apoyo.
Dado que el equipo de implementación debe ajustar partes importantes del sistema para cumplir con los requisitos del banco, los módulos se han desarrollado únicamente con fines de prueba e implementación. Esto ayuda a facilitar dicha personalización. Estos se describen en «Módulos para fines de pruebas e implementación» y solo se deben utilizar en el sistema de prueba. No están disponibles en el sistema de producción.
Se han almacenado las definiciones de datos y texto para ayudar en las pruebas. Los datos correspondientes, los módulos de texto y las definiciones de texto de garantía deben ajustarse para cumplir con los requisitos del banco y no deben transferirse al sistema de producción del banco sin una comprobación previa.
La naturaleza precisa de los datos almacenados puede consultarse en la documentación de MyModelbank.