INDICE
REQUERIMIENTOS ESPECIFICOS ... 3
1. ITIL (Information Technology Infrastructure Library) ... 3
1.1 LICENCIAMIENTO ... 3 1.2 USUARIOS ... 4 2. CARACTERÍSTICAS DE LA SOLUCION... 4 2.1 INCIDENTES... 5 2.2 CAMBIOS ... 6 2.3 SOPORTE REMOTO ... 7
2.4 INVENTARIOS DE SOFTWARE Y HARDWARE ... 8
2.5 ADMINISTRACIÓN DE SOFTWARE ... 10
2.6 ALERTAS ... 11
2.7 REPORTES ... 12
2.8 INTEGRACIÓN ... 12
2.9 PORTAL PARA USUARIOS FINALES ... 13
2.10 CARACTERISTICAS GENERALES ... 13
3. REQUERIMIENTOS TECNICOS ... 14
3.1 DEFINICIÓN DE CONCEPTOS Y TÉRMINOS DE LA SOLUCIÓN OFRECIDA14 3.2 PLATAFORMA TECNOLÓGICA QUE SOPORTARÁ LA SOLUCIÓN ... 14
3.2.1 HARDWARE ... 14
3.2.2 ARQUITECTURA TECNOLOGÍCA ... 15
3.3 SOPORTE DEL SERVICIO A LA SOLUCION OFRECIDA ... 15
3.3.1 MANTENIMIENTO A LA SOLUCIÓN OFRECIDA ... 15
3.3.2 SOPORTE TÉCNICO ... 16
3.3.3 CAPACITACIÓN QUE BRINDARÁ A LA SOLUCIÓN OFRECIDA... 16
3.3.4 VALOR AGREGADO QUE APORTARÁ A LA SOLUCIÓN OFRECIDA ... 16
3.4 IMPLEMENTACIÓN ... 16
3.4.1 CONSULTORÍA PARA LA IMPLEMENTACIÓN ... 16
3.4.2 HORAS DE CONSULTORÍA ADICIONAL ... 18
4. ENTREGA Y PUESTA EN MARCHA DE LA SOLUCIÓN OFRECIDA ... 18
4.2 DOCUMENTACIÓN TÉCNICA Y DE USUARIO ... 18
4.3 RECIBO Y ENTREGA DEFINITIVA ... 18
4.4 GARANTÍA ... 19
REQUERIMIENTOS ESPECIFICOS
1. ITIL (Information Technology Infrastructure Library)
El Banco requiere adquirir una herramienta donde se puedan implementar los procesos de TI alineados sobreuna metodología ITIL, para lo cual el proponente deberá especificar en su propuesta cuáles de los siguientes procesos tiene certificados a través de Pink Elephant en versión 3.1 o 2011:
1. Estrategia del servicio Siglas
Gestión del portafolio SPM
Gestión Financiera FM
2. Diseño del servicio
Gestión del Catálogo de Servicio SCM
Gestión de niveles de servicio SLM
Gestión de la Capacidad CAP
Gestión de la Disponibilidad AVM
Gestión de la continuidad del servicio de TI ITSCM 3. Transición del servicio
Gestión del cambio CHG
Gestión de la configuración y activos del servicio SACM Gestión de entregas y despliegues REL
Gestión del conocimiento KM
4. Operación del servicio
Gestión de eventos EV
Gestión de incidentes IM
Gestión de problemas PM
Gestión de Requerimientos RF
El proponente deberá estar en la capacidad de mostrar la implementación de los procesos que soporta la herramienta funcionando al Banco.
1.1 LICENCIAMIENTO
El proponente deberá detallar en su propuesta el tipo de licenciamiento que maneja, se debe especificar si con la compra de una licencia se puede tener acceso a todos los procesos o si se debe adquirir una licencia para cada proceso que se desea implementar.
En el caso que la herramienta se licencie por proceso o paquetes de procesos se debe realizar la cotización para que el Banco pueda hacer uso de los siguientes procesos los cuales ya se vienen trabajando en una consultoría para implementar:
2. Diseño del servicio Siglas
Gestión del Catálogo de Servicio SCM
3. Transición del servicio
Gestión del cambio CHG
Gestión de la configuración y activos del servicio SACM
Gestión del conocimiento KM
4. Operación del servicio
Gestión de incidentes IM
Gestión de Requerimientos RF
El proponente deberá explicar en su propuesta como se hará el cobro cuando el Banco requiera hacer la implementación de los siguientes procesos, los cuales no se encuentran contemplados en la fase inicial del proyecto que ya se viene trabajando:
2. Diseño del servicio
Gestión de niveles de servicio SLM
4. Operación del servicio
Gestión de problemas PM
1.2 USUARIOS
El Banco actualmente tiene 70 solucionadores que trabajan sobre la actual herramienta de mesa de ayuda. Si la herramienta se licencia por usuario, se deben cotizar 30 licencias. En el caso que se maneje el concepto de usuario nombrado o concurrente las 30 licencias se deberán distribuir de la siguiente manera:
Cinco licencias nombradas para los agentes que actualmente trabajan todo el día con la herramienta.
Veinticinco licencias concurrentes para el resto de usuarios que ingresan a la herramienta a documentar y cerrar los casos.
2. CARACTERÍSTICAS DE LA SOLUCION
El Banco requiere que la herramienta a implementar cumpla con las siguientes funcionalidades; las cuales el proponente deberá indicar si el sistema las tiene incorporadas nativamente o requiere de componentes adicionales que generen nuevos
costos para el Banco. El proponente deberá realizar descripción resumida de cómo se implementa la funcionalidad pedida en la herramienta. También debe especificar las funcionalidades adicionales que tenga la herramienta y que considere que generan un valor agregado al Banco.
2.1 INCIDENTES
1. Árbol de Tipologías: La herramienta debe permitir la creación de incidentes manejando un árbol de tipología de mínimo 10 subniveles.
2. Prioridad: La herramienta debe permitir la configuración de diferentes tipos de prioridades dependiendo de las necesidades del Banco.
3. Estados: La herramienta debe permitir la configuración de diferentes estados en los casos. Los estados se deben poder parametrizar para que permita el cambio de un estado a otro cuando éste se encuentre parametrizado. Cuando se hagan cambios de estados el sistema debe solicitar documentación justificando por qué se realizó el cambio.
4. Descripción: La herramienta debe permitir asociar una descripción al caso cuando éste se está creando.
5. Suspensión: La herramienta debe permitir la suspensión de los casos, se debe poder configurar una autorización para poder suspender los casos o generar una alerta. Cuando un caso esté en estado suspendido se debe poder para el tiempo del SLA.
6. Work – Flow: La herramienta debe poder crear work flows de trabajo para la solución de incidentes de acuerdo al nivel de escalamiento que maneja el Banco. 7. Documentación de casos: La herramienta debe permitir la documentación de los
incidentes a través de comentarios y archivos adjuntos.
8. Campos personalizados: La herramienta debe permitir la creación de nuevos campos configurables de acuerdo a la necesidad del Banco y asociados a los incidentes.
9. Plantillas: El sistema debe permitir la configuración de plantillas para la creación de casos de forma automática.
10. Manejo de cargas de trabajo: Al sistema se le podrá configurar una asignación automática de casos de acuerdo a las características de éste y deberá basarse en la carga de trabajo que tengan los solucionadores para su asignación.
11. Búsqueda de casos relacionados: El sistema deberá permitir buscar casos, documentación de ayuda que se encuentre relacionada con las características del
caso, como por ejemplo poder buscar los casos relacionados al usuario que está creando el caso, o a la categoría, entre otros.
12. Horarios: El sistema debe permitir la configuración de los horarios de los solucionadores donde se pueden establecer las horas de trabajo, días laborables y días festivos. Estos se deben tener en cuenta en el cálculo de los acuerdos de servicio.
13. Log: El sistema debe guardar todas las acciones que se realicen sobre los casos desde su creación, en un log donde se pueda consultar la hora, fecha, acción realizada y usuario que la realizó.
14. Configuración de SLA: La herramienta debe permitir la configuración de acuerdos de servicios a los incidentes basados en la categoría, prioridad, persona, área y clasificación del caso.
15. Creación de casos relacionados: La herramienta debe poder crear casos relacionados, por ejemplo si un caso requiere de varias actividades que son atendidas por varios solucionadores se pueden crear otros casos y se debe manejar una relación para identificarlos rápidamente.
16. Clasificación de usuarios: El sistema debe permitir la clasificación de usuarios VIP, con el fin de manejar otros SLA donde se permita dar una atención inmediata a este tipo de usuarios.
17. Asociar CI a los casos: Cuando un usuario reporte un incidente la herramienta debe poder relacionar éste con un CI que esté asignado al usuario.
18. Manejo de tipos de caso: La herramienta debe permitir cambiar la tipología de los casos abiertos entre sí. Los tipos de casos que se desean manejar son: incidentes, cambios, requerimientos y problemas.
19. Eventos Masivos: La herramienta debe permitir el registro de eventos masivos bajo un solo caso.
20. Incidentes de Seguridad: Manejar casos clasificados como incidentes de seguridad de acuerdo con un estándar internacional.
2.2 CAMBIOS
Adicional a las funcionalidades mencionadas en el módulo de incidentes la herramienta debe cumplir con las siguientes funcionalidades en su módulo de cambios:
1. Formato de RFC: Permitir configurar el formato de cambios dentro de la herramienta de acuerdo a las necesidades del Banco.
2. Aprobaciones: Permitir que un cambio pueda ser aprobado por uno o varias personas.
2.3 SOPORTE REMOTO
El Banco requiere que la herramienta a implementar permita prestar a los agentes de mesa de ayuda un soporte eficaz, sobre los computadores que tiene el Banco; para esto la herramienta deberá contar con la funcionalidad de administración remota de los equipos con el fin de que los agentes no se tengan que desplazar físicamente al lugar donde se está presentando la solicitud y de esta manera poder prestar un servicio más ágil.
1. Control remoto: La herramienta debe permitir el control remoto de todas las estaciones de los usuarios del Banco ubicados en la LAN y en la WAN.
2. Sesiones: La herramienta debe permitir el control remoto de varias estaciones de trabajo al mismo tiempo.
3. Opciones de Encendido de Equipos: La herramienta debe permitir el encendido, apagado, reinicio, cierre de sesión de los usuarios y encendido de equipos ubicados en la red WAN del Banco. Estas funciones se deben poder ejecutar masivamente. Ejemplo, poder encender y apagar todos los equipos al mismo tiempo.
4. Administración Remota: La herramienta debe permitir la visualización y administración del sistema de archivos remotamente, visualización del registro, ejecución de comandos, procesos del sistema, envío de archivos, envío de mensajes y verificación si el computador está en línea.
5. Solicitud de permiso: La herramienta debe permitir la configuración de notificación al usuario cuando se va a tomar control remoto de la máquina y este debe estar en la capacidad de aceptar o no la conexión.
6. Log: El sistema debe tener un mecanismo de log donde se pueda evidenciar quien tomó el control remoto de una máquina, la fecha y hora en que lo hizo y las acciones que se realizaron sobre la estación.
7. Visualización del control remoto: La visualización del control remoto debe ser como si el solucionador estuviera físicamente en la estación, ésta no debe tener retrasos en la visualización que afecten la calidad del soporte.
2.4 INVENTARIOS DE SOFTWARE Y HARDWARE
El Banco requiere que la herramienta permita manejar de forma automática los inventarios de software y hardware del Banco. Adicionalmente se necesita tener la información en línea de 750 equipos dentro de los cuales se encuentran estaciones de trabajo, portátiles y servidores.
1. Compatibilidad Sistemas Operativos: Dentro de la plataforma tecnológica que actualmente tiene el Banco, se encuentran los siguientes sistemas operativos sobre los cuales debe correr el agente, el proponente debe indicar si es compatible con los siguientes sistemas operativos:
a. Windows XP o superior b. Mac OS
c. Windows 2003 Server o superior d. Linux Red Hat 5 o superior e. AIX
2. Distribución de agentes: La herramienta debe permitir la instalación masiva de agentes e instalación remota de agentes de forma individual.
3. Inventarios en línea: El agente debe hacer el envío de toda la información del software y hardware que tiene el equipo, cuando este se instala por primera vez. Luego éste debe hacer envíos de inventarios diferenciales en tiempo real con la información de software y hardware que cambio en el equipo. Esta ejecución automática se debe poder parametrizar.
4. Inventarios manuales: El sistema debe poder hacer el cargue de inventarios de forma manual de los equipos que no se encuentran conectados a la red.
5. Almacenamiento de Inventarios: Cuando el equipo no se tenga conexión los inventarios se deben almacenar localmente con el fin de no perder la información, una vez el equipo restablezca la conexión, se debe hacer el envío de éstos.
6. Solicitud de inventarios: El sistema debe permitir la opción de solicitar inventarios en tiempo real del equipo que se desee o programarlo para que se haga en una hora específica.
7. Asignación Equipos: El sistema debe permitir la asignación de los equipos a las personas que se encuentran creadas en la herramienta.
8. Monitoreo de dispositivos móviles: La herramienta debe estar en la capacidad de hacer monitoreo de dispositivos móviles como por ejemplo tabletas, samartphones, etc.
9. Inventarios de Hardware: La herramienta debe estar en la capacidad de obtener como mínimo la siguiente información relacionada con el hardware de los equipos del Banco:
a. Equipo: serial del equipo, marca, modelo, nombre y dominio en donde se encuentra.
b. Pantalla: se debe obtener la marca, modelo y serial. c. Mouse: se debe obtener la marca y serial.
d. Disco Duro: número de discos que tiene el equipo, capacidad de los discos, espacio ocupado, espacio disponible, marca y serial.
e. Memoria: cantidad de memoria que tiene el equipo. f. Teclado: marca y serial.
g. Procesador: nombre del procesador y frecuencia.
h. Dispositivos conectados: información de los dispositivos conectados a los equipos.
i. Direcciones: dirección IP y MAC adress de las tarjetas de red.
j. Ubicación física: permitir obtener la ubicación física del hardware ya sea a través de una parametrización manual o automática.
10. Inventarios de Software: La herramienta debe estar en la capacidad de obtener como mínimo la siguiente información relacionada con software instalado en los equipos del Banco:
a. Software instalado: Información de todo el software que se visualiza en el panel de control o el que se encuentra en el registro de Windows. Se debe traer la información del nombre, versión y fabricante.
b. Ejecutables: Información de todo el software portable que se encuentra en los equipos, se debe especificar la ubicación de éste.
c. Sistema Operativo: Información del nombre del sistema operativo que se tiene instalado en el equipo.
d. Inventario de archivos por extensión: poder tener la información de todos los archivos con extensiones específicas que el Banco pueda configurar con su ubicación dentro del equipo.
e. Uso Software: Obtener información del uso del software que se encuentra instalado en un equipo.
2.5 ADMINISTRACIÓN DE SOFTWARE
La herramienta debe tener un módulo o una funcionalidad mediante la cual el Banco pueda realizar toda la administración del software que se encuentra instalado en los equipos con el fin de cumplir todo lo relacionado con derechos de autor.
1. Clasificación de Software: El sistema debe permitir la clasificación del todo el software por categorías o grupos, con el fin de realizar una agrupación dependiendo las características del software instalado en el equipo y poder hacer una adecuada administración de éste. Indicar si está clasificación ya viene prestablecida o personalizable.
2. Cantidad de licencias instaladas: El sistema debe brindar la información de cuantas instalaciones de un producto hay en la totalidad de los equipos que se encuentran monitoreados por el agente.
3. Ingreso de licencias compradas: El sistema debe poder ingresar el número de licencias que el Banco tiene compradas de un producto de software. Se debe poder ingresar como mínimo la información referente al número de licencias que tiene el Banco, información del proveedor con sus datos de contacto, fecha de compra de la licencia, fecha de finalización, el tipo de licencia y descripción de la licencia.
4. Calculo del diferencial de licencias: El sistema debe calcular de forma automática la cantidad de licencias remanentes o faltantes de acuerdo con la información de licencias instaladas menos licencias compradas.
5. Campos Personalizados: Se debe poder crear campos personalizados de acuerdo a la necesidad del Banco relacionados con información de las licencias. 6. Clasificación automática de software que no requiere licenciamiento:
Especificar si el sistema está en la capacidad de identificar el software como actualizaciones, drivers, complementos, plugins, y parches para clasificarlo automáticamente.
7. Administración de licencias que no se instalan: El sistema debe tener la posibilidad de poder ingresar licencias que no quedan instaladas en los equipos con el fin de poder hacer una administración igual a la que se hace con el software que queda instalado en los equipos.
8. Archivos adjuntos: La herramienta debe permitir el cargue de archivos adjuntos relacionados con la información de licenciamiento como por ejemplo la factura, el contrato, etc.
9. Distribución de Software: Funcionalidad que permita hacer distribución de software remotamente. Esta distribución se debe poder hacer para grupos de equipos o un equipo específico.
10. Desinstalación de Software: Funcionalidad que permita la desinstalación de software de manera remota de las estaciones de trabajo.
2.6 ALERTAS
La herramienta debe permitir la configuración de alertas donde el Banco pueda realizar toda la creación y parametrización de éstas de acuerdo a sus necesidades, se requiere que el sistema permita crear como mínimo las siguientes alertas:
1. Creación y cierre de casos: Envío de una alerta donde se informa al usuario y a la persona que soluciona la apertura y cierre de un incidente. Esta alerta debe permitir el envío de un comentario de cierre escrito por el solucionador.
2. Alertas de vencimiento de SLA: Envío de una alerta al solucionador cuando el caso se encuentre en el 50%, 80% y 100% del tiempo destinado para la atención del incidente. Cuando el Banco lo desee podrá cambiar la parametrización de éstos porcentajes.
3. Alertas de escalamiento: Permitir el envío de alertas a determinadas personas parametrizadas en el sistema cuando un caso se encuentra vencido.
4. Alertas por compañía: Las alertas se deben poder parametrizar por compañía, permitiendo el envío de ésta desde diferentes orígenes de correo.
5. Cambio de Hardware: El sistema debe permitir el envío de una alerta cuando se detecta un cambio en el hardware del equipo.
6. Instalación de Software: El sistema debe permitir el envío de una alerta cuando se detecte la instalación de un software en los equipos del Banco.
7. Alertas Sublicenciamiento: El sistema debe permitir la configuración de un tipo de alerta que me permita identificar cuando hay instaladas más licencias de las que tengo compradas.
8. Alertas Sobre licenciamiento: El sistema debe permitir la configuración de un tipo de alerta que me permita identificar cuando hay instaladas menos licencias de las que tengo compradas.
9. Cambios de solucionador: El sistema debe permitir el envío de una alerta cuando el caso cambia de solucionador, ésta alerta se le debe poder enviar al usuario que abrió el caso y al nuevo solucionador que lo atenderá.
2.7 REPORTES
La herramienta debe estar en capacidad de generar reportes de toda la gestión que se realice sobre la misma. El Banco requiere las siguientes funcionalidades en el módulo de reportes:
1. Reportes generales: El sistema debe poder generar diferentes reportes donde se pueda extraer la información que se encuentra en la bases de datos haciendo relaciones entre tablas para permitir el cruce de información.
2. Generación de gráficos: La herramienta debe estar en la capacidad de generar gráficas con la información que se encuentra en la base de datos de acuerdo las necesidades del Banco.
3. Cálculo de indicadores de gestión: La herramienta debe mostrar y calcular en tiempo real los indicadores de gestión definidos por el Banco e información relacionada con la mesa de ayuda de forma gráfica con el fin de hacer un monitoreo en tiempo real de éstos.
4. Almacenamiento de reportes: El sistema debe poder guardar los reportes que se diseñen agrupándolos por categorías y estableciendo los permisos de los usuarios que los pueden consultar.
5. Envío de reportes: Especificar si la herramienta está en la capacidad de enviar reportes de forma automática a través de correo electrónico de acuerdo a una programación que establezca el Banco.
6. Exportación de información: El sistema debe permitir exportar la información de los reportes a formatos Excel, archivos planos, Word, PDF y HTML, para las imágenes se debe poder exportar a formatos jpg y png.
7. Columnas personalizadas: El sistema debe estar en la capacidad de agregar columnas parametrizables, donde se pueda calcular información en tiempo real haciendo operaciones matemáticas, texto con base en la información que se encuentra en la base de datos.
8. Condiciones: El sistema debe permitir la inclusión de condiciones similares a una consulta SQL cuando se estén generando los reportes.
2.8 INTEGRACIÓN
La herramienta debe permitir la integración con diferentes sistemas del Banco.
1. Directorio Activo: La herramienta debe permitir la integración con el directorio activo para realizar el cargue y actualización de los usuarios que utilizan el sistema y para el manejo del single sign-on de ingreso a la herramienta.
2. Herramienta de Monitoreo: La herramienta se debe integrar con el sistema de monitoreo del Banco para la creación de casos automáticos. Una vez ésta genere alertas por los diferentes eventos que se tienen configurados.
2.9 PORTAL PARA USUARIOS FINALES
La herramienta debe tener un portal donde los usuarios finales puedan consultar, solicitar y gestionar los servicios de TI que tiene el Banco, el proponente debe especificar si éste requiere la compra de licenciamiento adicional. Se espera que el portal como mínimo cumpla con las siguientes características:
1. Registro de incidentes o servicios: Funcionalidad que permita a los usuarios finales registrar nuevas solicitudes de servicios.
2. Seguimiento de incidentes abiertos: Funcionalidad que permita a los usuarios hacer seguimiento del avance de sus casos abiertos pudiendo verificar la documentación que ha relacionado el solucionador.
3. Consulta de casos: Funcionalidad que permita al usuario consultar sus casos abiertos, cerrados, etc.
2.10 CARACTERISTICAS GENERALES
La herramienta debe incorporar el uso de las siguientes características, el proponente deberá especificar si la herramienta cuenta con estas funcionalidades de forma nativa o si se requiere de soluciones adicionales.
1. Chat: El proponente debe especificar si la herramienta cuenta con la funcionalidad de chat.
2. Encuestas: La herramienta debe tener un módulo o funcionalidad donde se puedan crear encuestas, de acuerdo a la necesidad del Banco con el fin de hacer la medición de la satisfacción del servicio y obtener información de los usuarios. 3. Base de datos de conocimiento: Funcionalidad que le permita a los
solucionadores y usuarios finales poder buscar información relacionada con temas específicos para la atención de solicitudes.
4. Importar información: Funcionalidad que permita importar datos desde archivos para realizar el cargue masivo de información en la herramienta cuando se hagan parametrizaciones o se necesite hacer documentación de casos.
6. Identificación de tipos de casos: La herramienta debe permitir diferenciar entre casos correspondientes a incidentes, requerimientos, cambios y problemas.
3. REQUERIMIENTOS TECNICOS
3.1 DEFINICIÓN DE CONCEPTOS Y TÉRMINOS DE LA SOLUCIÓN OFRECIDA El proponente deberá detallar los conceptos y términos que son particulares de su propuesta, con el fin de tener un mejor entendimiento por parte del Banco para fines de calificación de la propuesta.
3.2 PLATAFORMA TECNOLÓGICA QUE SOPORTARÁ LA SOLUCIÓN
El proponente deberá hacer una especificación detallada de los requerimientos de software, hardware y comunicaciones que necesita la herramienta para su funcionamiento. Especificar requerimientos mínimos y requerimientos óptimos.
En los puntos detallados dentro de este numeral, el proponente dará respuesta a la plataforma tecnológica que soporta el sistema ofrecido. Particularmente, se debe aclarar el modo de operación general de la aplicación, entre otros: localización y distribución de lo pertinente a la capa de presentación, lógica y de datos, manejo de comunicaciones, modo de procesamiento, interfaces, requerimientos, operación sobre dispositivos móviles y otros.
La propuesta deberá tener especificados cada uno de los elementos y componentes que hacen parte de la solución, los cuales sean prerrequisito para la implementación y funcionamiento de ésta. De no ser explicito, se asume que estas serán presentadas por el proponente como parte integral de su propuesta.
La solución que se proponga, deberá garantizar por los próximos 3 años que las herramientas sobre las que se soporta, estarán vigentes en el mercado con su debido nivel de soporte y de presentarse alguna novedad en este sentido, deberá dejar explícito en la propuesta e indicar el plan de trabajo para la migración a la siguiente versión anunciada por los fabricantes.
3.2.1 HARDWARE
Se deberán explicar las características de hardware a nivel de servidores y clientes requeridos por la herramienta para su correcto funcionamiento.
3.2.1.1 BASES DE DATOS
La herramienta debe tener compatibilidad para trabajar con Base de Datos ORACLE o SQL Server.
3.2.1.2 SERVIDORES
Los servidores Web para la publicación de los portales Web, el servidor donde se manejan o se reciben todos los inventarios generados por las agentes deben ser sistemas Windows o Linux.
3.2.2 ARQUITECTURA TECNOLOGÍCA
El proponente deberá especificar cómo está constituida la arquitectura técnica del sistema, dentro de ésta arquitectura se debe especificar si el sistema cumple con los siguientes requerimientos:
1. Cliente Servidor: El proponente deberá especificar si la herramienta cuenta con un cliente grueso que se tenga que instalar. Si se cuenta con éste cliente, se deberá especificar en términos generales la diferencia entre el cliente web y éste. 2. Cliente Web: Se requiere de una interfaz Web donde los solucionadores puedan
realizar toda la gestión de sus incidentes.
3. Cliente Móvil: Se requiere de una interfaz móvil, la cual puede ser una aplicación nativa o un sitio web diseñado para dispositivos móviles donde se los usuarios puedan registrar sus casos y los solucionadores hacer toda la gestión de sus casos.
4. Multicompañía: Característica del sistema que permite el uso de la herramienta por varias compañías o varios departamentos dentro del Banco con parametrizaciones, reportes, alertas, etc., totalmente diferentes. La información entre una compañía y otra debe ser totalmente independiente.
3.3 SOPORTE DEL SERVICIO A LA SOLUCION OFRECIDA 3.3.1 MANTENIMIENTO A LA SOLUCIÓN OFRECIDA
Adjuntar por separado la propuesta de mantenimiento y soporte. Se pide detallar el esquema de atención, los costos y los acuerdos de servicio que el proponente tenga establecido con sus clientes. En esta propuesta se deberán especificar como mínimo los siguientes puntos:
Esquema de las diferentes líneas de soporte (teléfono, mail, online, presencial, entre otros).
Acuerdos de servicio (SLA). Acuerdos de Operación (OLA).
Proponer penalizaciones por el incumplimiento en los acuerdos de servicios o acuerdos de operación.
Configuraciones (aplicación, base de datos, servidores). Horario de soporte.
Adicionalmente, se requiere que el proponente adjunte para atención de controles de cambio que no estén cubiertos por el contrato, el valor por hora, día y mes y la metodología que se tenga para su gestión.
Esquema definido para nuevos requerimientos, costos relacionados con los diferentes tipos adicionales de contratación: capacitación, consultoría, desarrollo, así como de la disponibilidad para contar con dichos servicios.
3.3.2 SOPORTE TÉCNICO
El proponente debe describir cómo va a prestar el soporte técnico para los componentes que presente en su propuesta (hardware, software de base, aplicaciones, servicios). Este soporte debe estar disponible en cualquier momento y a cargo de profesionales capacitados. El tiempo máximo de atención de la solicitud no deberá exceder de 4 horas y su solución dependiendo la gravedad no deberá exceder de 72 horas.
3.3.3 CAPACITACIÓN QUE BRINDARÁ A LA SOLUCIÓN OFRECIDA
El proponente deberá presentar en una propuesta separada las condiciones bajo las cuales brindará la capacitación respectiva en todos los componentes de su propuesta: tipo de capacitación (técnica, operación, administración y usuario), contenido de cada curso; duración, intensidad horaria, grupo objetivo del curso, requisitos de grupo, recursos necesarios u otras condiciones necesarias, así como de las herramientas con las cuales cuenta el proveedor para garantizar una adecuada capacitación y evaluación de la misma.
3.3.4 VALOR AGREGADO QUE APORTARÁ A LA SOLUCIÓN OFRECIDA
Si el proponente lo considera, puede especificar el valor agregado que usará como complemento a la propuesta.
3.4 IMPLEMENTACIÓN
La implementación de la solución debe ser realizada por ingenieros certificados por el fabricante para el desarrollo de ésta actividad. El proponente deberá anexar las certificaciones de los ingenieros que realizarán la labor de implementación y configuración.
3.4.1 CONSULTORÍA PARA LA IMPLEMENTACIÓN
El proponente deberá especificar por separado los costos y cantidades de horas para los servicios de consultoría requeridos en la implementación y parametrización de la herramienta, se deben tener en cuenta como mínimo la ejecución de las siguientes actividades:
Instalación
1. Verificación de prerrequisitos para la instalación de la herramienta.
2. Implementación de las bases de datos de la herramienta el Banco entregará el motor de base de datos funcionando.
3. Implementación del portal para usuarios finales donde puedan hacer solicitudes en modo self service.
4. Implementación del portal para solucionadores.
5. Configuración de la conexión con el directorio Activo si es compatible. 6. Configuración con el servidor de correo.
7. Configuración de roles de los usuarios que utilizarán la herramienta de acuerdo a la definición del Banco.
8. El proveedor entregará la herramienta totalmente operativo al Banco. 9. Instalación de consolas.
10. Parametrización de dos compañías o multiproyecto. Parametrización módulo Incidentes
1. Definición de mínimo 3 prioridades.
2. Parametrización de las categorías para el registro de incidentes. 3. Creación de 3 plantillas para la creación de casos recurrentes.
4. Parametrización del calendario con días festivos para Colombia y horas de trabajo. 5. Parametrización de acuerdos de servicios.
6. Parametrización de notificaciones para apertura, escalamiento y cierre de casos. 7. Parametrización de notificaciones para alertas de cambio de software y hardware. 8. Parametrización de los tipos de incidentes.
9. Reportes que permitan verificar la gestión de incidentes. Inventarios de software y hardware
1. Distribución de agentes en los equipos del Banco.
2. Creación de reportes donde se pueda controlar el licenciamiento que tiene el Banco.
3. Parametrización de software que no se instala en los equipos y que se debe controlar en los inventarios de software.
4. Alertas de licenciamiento donde se pueda verificar cuando el Banco se encuentra sub/sobre licenciado en algún producto de software.
El proveedor deberá garantizar la transferencia de conocimiento al Banco documentando y entregando las actividades realizadas en la instalación y parametrización de la herramienta.
El proponente podrá incluir actividades adicionales que considere necesarias, para la instalación y parametrización de la herramienta. Estas actividades deben quedar definidas por parte del proveedor al Banco.
3.4.2 HORAS DE CONSULTORÍA ADICIONAL
El proponente deberá especificar el costo de la hora adicional de consultoría para servicios de parametrizaciones e instalaciones adicionales que requiera el Banco.
4. ENTREGA Y PUESTA EN MARCHA DE LA SOLUCIÓN OFRECIDA 4.1 ESQUEMA DE IMPLANTACIÓN Y ADECUACIÓN
El proponente deberá describir la metodología que será utilizada durante la adecuación e implantación de la solución ofrecida. Así mismo deberán especificarse los tiempos, recursos del Banco requeridos y recursos del proveedor ofrecidos para la implantación exitosa de su solución de acuerdo con el cronograma de actividades propuesto. De igual manera, el proponente podrá comprometerse a realizar las adecuaciones o extensiones necesarias para que la solución ofrecida cumpla totalmente con los requerimientos definidos en esta nota técnica.
El proponente deberá detallar la metodología de implantación del servicio que incluya como mínimo:
Planeación detallada del proceso de instalación y prueba.
Tiempo de desarrollo y adecuación para los requerimientos funcionales que se comprometen a realizar.
Pruebas: Técnicas y de usuario. Esquema de funcionamiento. Capacitación técnica.
Capacitación funcional. Implantación.
Equipo de trabajo (Banco y proveedor). Resultados/productos de cada fase. Cronograma de trabajo del proyecto.
4.2 DOCUMENTACIÓN TÉCNICA Y DE USUARIO
El proponente deberá entregar la documentación técnica y de usuario en español incluyendo los siguientes elementos: Documentación del proyecto o servicio ofrecido, documentación de usuario, documentación técnica, manual de instalación, manual para el mantenimiento técnico.
4.3 RECIBO Y ENTREGA DEFINITIVA
El recibo definitivo de la solución estará sujeto a que se realicen las respectivas pruebas funcionales y revisiones técnicas de la arquitectura de TI propuesta y que las mismas
hayan finalizado con resultados a satisfacción del Banco. BANCÓLDEX considerará implementada la solución cuando se hayan cumplido los siguientes eventos:
Recibo del software contratado funcionando correctamente en producción. Las pruebas hayan finalizado con resultados a satisfacción del Banco.
Se hayan realizado todos los cursos de capacitación para el personal definido por el Banco.
Se hayan entregado y aprobado los manuales y documentos solicitados por el Banco.
Se haya firmado un acta de terminación y aceptación por parte de los responsables autorizados por el Banco, de aceptar la solución ofrecida, y por el proveedor, el representante autorizado.
4.4 GARANTÍA
El proponente deberá entregar una garantía sobre la solución una vez ésta quede implementada por un período mínimo de 6 meses, contados a partir de la fecha de la firma del acta de entrega a satisfacción del producto. Esta garantía cubre defectos en el software instalado en el Banco y defectos en las personalizaciones realizadas por el proveedor.
4.5 SEGURIDAD DE LA SOLUCIÓN OFRECIDA
Se debe tener presente al menos los siguientes mecanismos de seguridad que debe tener la herramienta los cuales se deben describir en la propuesta:
Autenticación: Proceso de confirmación de la identidad del usuario. Antes de que una aplicación pueda autorizar el acceso a un recurso, debe confirmar su identidad. Esta es la primera capa de control de seguridad. Especificar si la solución permite una autenticación con el Directorio Activo de Microsoft.
Autorización: Proceso que consiste en verificar si un usuario autenticado tiene permiso para obtener acceso a un recurso determinado. Siguiente capa de seguridad tras la autenticación.
Protección de datos: Proceso que consiste en proporcionar confidencialidad, integridad y no repudio a los datos.
Nivel de auditabilidad del sistema: Proceso que consiste en registrar y supervisar los eventos que se producen en un sistema y que son importantes para la seguridad.
