Se ha pedido un software que haga lo siguiente. Quiero proponer y quisiéra saber cuáles herramientas de software libre existen para estos fines. Gracias por su ayuda.

1. Perfil del proveedor

• Ser una empresa certificada en los productos ofertados.

• Ser distribuidor autorizado de los productos ofertados.

• Disponer del personal técnico calificado para la instalación, configuración y capacitación. Presentar la certificación en la herramienta y en Itil de al menos una persona que vaya a realizar estas tareas. Presentar las hojas de vida de las personas que van a trabajar en el proyecto.

• El oferente deberá mantener una infraestructura de soporte para el servicio ofertado.

• Experiencia en proyectos en instituciones del sector público o privado. Presentar certificados de al menos 2 instalaciones anteriores.

2. Generalidades

• La herramienta debe estar certificada como ITIL Compliance por Pink Elephant, para al menos 6 procesos ITIL entre los cuales deben estar: Incident Management, Change Management, Problem Management, Configuration Management.., con el objetivo de garantizar que la solución presentada  cumple con los requerimientos establecidos por la organización para la implementaciones de los procesos según ITIL.

• Las pantallas de la herramienta (GUI y Web) deben permitir su personalización con herramientas gráficas, modificando tanto su presentación como su funcionalidad sin la dependencia del proveedor (agregando nuevos botones/opciones de menú)

• La herramienta debe poder personalizarse a las necesidades de la institución, lo que se llevará a cabo durante el proceso de implementación. Deberá poder cambiarse su estructura, interfaces y contar con un módulo de diseño de pantallas y formularios integrado en el mismo producto ofertado.

• Todas las personalizaciones realizadas a la herramienta, no se deben ver afectadas por migraciones a nuevas versiones.

• La herramienta debe ser capaz de proveer acceso en línea de múltiples registros de incidente/ problemas.

• La herramienta debe tener la capacidad de poder adjuntar documentos de otras fuentes (p.e. documentos en procesador de palabras, tablas del hojas de calculo, diagramas en visio, etc.) en los incidentes y problemas.

• Debe permitir que cada persona del área TI registre las actividades realizadas para tareas que no tienen relación con los incidente y problemas (por ejemplo tareas de operación y mantenimiento).

• El software debe entregarse en su última versión liberada.

• La herramienta ofertada debe contar con por lo menos 2 liberaciones de versiones anteriores a la que actualmente propone el oferente.

3. Especificaciones Técnicas

• Plataforma Tecnológica

• Base de datos

  • La base de datos que soporte la herramienta debe ser Oracle 10G R2

• Servidor de aplicaciones

  • El servidor de aplicaciones (capa media, de componentes) debe correr sobre Linux Red Hat 3 o superior.

  • La herramienta debe soportar Web Services para integración con aplicaciones remotas.

• Clientes

  • La herramienta debe basar su uso totalmente a través de un ambiente WEB, vía browser para el usuario final.

• Como browser de acceso el sistema debe soportar Internet Explorer 5.5, 6.0 o superior y/o Firefox 1.5 o superior

• El browser de acceso al sistema debe ejecutarse en:

Windows 95 ,98, 2000, XP, Vista y/o Linux

• Interfaz Gráfica

  • La herramienta debe ofrecer interfaces GUI y/o Web para técnicos de soporte completamente funcionales.

• Características Técnicas

• Auditoria

  • La herramienta debe permitir generar registros de auditoria para hacer seguimiento de la modificación de la información.

  • Debe registrar al menos los siguientes campos:

    • Usuario

    • Fecha

    • Evento

    • Campos Afectados

  • La herramienta debe tener una opción para consulta de los registros de auditoria

• Interfaces de usuarios.

  • Debe proveer una aplicación donde publique información, vía Web a algunos o todos los usuarios de la organización, respecto a situaciones preventivas o boletines que prevengan llamadas masivas situaciones conocidas, al mantener informada a las personas.

  • La herramienta debe usar el lenguaje español en las pantallas (incluyendo las pantallas de ayuda)

• Seguridad

  • La herramienta debe permitir integrarse a directorios LDAP, de tal forma que permita verificar la identidad de un usuario y controlar su acceso.

  • Debe contar con herramientas de seguridad y control de la información; es decir que los usuarios finales solo puedan ver sus requerimientos y que el personal técnico cuente con diferentes accesos dependiendo de los perfiles predefinidos.

  • El sistema debe permitir la asignación de mas de un rol o perfil a una persona, fusionando los privilegios de cada rol o perfil. Por ejemplo una persona puede tener el rol o perfil para abrir incidentes y también puede tener un rol o perfil para resolverlos.

• Interfaces Técnicas

  • Las pantallas de registro, deben tener menú desplegable y opciones para profundizar en la información (drill-down) en los campos.

  • La herramienta debe permitir escalabilidad en sus componentes, con arquitecturas que permitan:

    • Varios servidores de aplicaciones conectados a una base de datos. Según la carga se podrán añadir más servidores de aplicaciones

• Varios servidores Web conectados a un servidor de la herramienta.

• La herramienta debe permitir la administración de: Problemas, Incidentes y Cambios de manera integrada.

• Las herramienta debe generar notificaciones automáticas a:

  • Email.

  • Alertas visuales graficas.

  • Mensaje de notificación.

• La herramienta debe contar con un servicio de encuestas, el cual puede ser automatizado según las necesidades de la institución.

• La herramienta debe permitir que los técnicos de soporte del sistema puedan abrir varias ventanas como referencia durante el registro de llamadas.

• La herramienta debe ser capaz de comunicarse con herramientas para la gestión de infraestructura (System management tools) con el objetivo de recibir automáticamente los eventos. En base a estos eventos la herramienta podrá emitir alarmas o abrir incidentes automáticamente.

• Debe integrarse con herramientas de verificación de HW y SW como sms y de otras casas comerciales Como HP Open View, Maxima, Tivoli, Computer Associates.

• Workflow

  • La herramienta debe contar con flujos de trabajo (Workflow) definibles y modificables por el usuario autorizado con herramientas estándar del sistema.

  • La herramienta debe permitir la modificación de los flujos de trabajo en una herramienta gráfica, sin la dependencia del proveedor, mientras el sistema está en operación.

  • Manejo de flujos de trabajo para Ordenes de Trabajo (work flow).

  • La herramienta debe permitir notificar a las personas involucradas en el incidente/ problema vía e-mail acerca de las tareas que les han sido asignadas.

  • Definición de tiempo de ejecución de cada asignación, en caso de sobrepasar este tiempo poder realizar escalamiento (notificaciones) a niveles superiores (jefaturas).Los valores utilizados para las condiciones de flujo deben ser tomados de la base de datos.

  • Debe manejar asignación y reasignación de actividades del workflow a través de una opción de la herramienta.

• Reportes

  • Todos los reportes deben poder mostrarse en pantalla y enviarse a una impresora.

  • Los reportes generados por la herramienta, deben ser de tipo listado y gráficos. Todos los reportes deben exportarse a PDF, hoja de cálculo, o procesador de palabras sin programación adicional.

  • La herramienta debe permitir la construcción de encuestas según las necesidades de la institución. Los resultados de las encuestas deben almacenarse en la base de datos para generar reportes.

4. Interfaces Técnicas de la herramienta

 

4.1 Gestión de incidente y problemas

• La herramienta debe permitir el registro, modificación y cierre rápido de incidente/problemas.

• Los registros de Incidente/problemas se deben crear fácil y rápidamente con una digitación mínima,

• La herramienta debe permitir la asignación automática de requerimientos basados en cargas de trabajo, horarios y capacidades del analista.

• La herramienta debe permitir clasificar los requerimientos por prioridad, impacto, urgencia y severidad sin hacer desarrollos adicionales.

• La herramienta debe permitir el escalamiento y notificación de aquellas llamadas no resueltas en el primer nivel, asignándolas a los Grupos de Soporte y Analistas disponibles relevantes, ya sea vía el sistema en línea, e-mail

• La herramienta debe proporcionar un rastreo rápido y simple de todas las llamadas. La herramienta debe permitir usar cualquier campo de la pantalla como llave consulta.

• La herramienta debe generar reportes definidos por usuarios del sistema, para proveer múltiples vistas sobre tendencias de Incidente/problemas y rendimiento del soporte.

• En la herramienta debe ser posible cambiar valores clave de registros durante su tiempo de vida – por ejemplo, prioridad, categoría, componente.

• La herramienta debe permitir asociar las nuevas ocurrencias de un mismo incidente/problema cuando se establezca que el incidente/problema esta afectando una gran población

• La herramienta debe soportar la posibilidad de relacionar los nuevos incidente/problemas con el registro de Error Conocido, para prevenir investigaciones innecesarias

• En la herramienta debe ser posible enlazar prioridades de llamada a equipo, contacto, grupo de usuario y tipo de incidente/problema.

• Una vez que un incidente/problema es registrado, debe ser claro a partir de los detalles del componente o software, qué grupo de soporte o individuos son responsables de la herramienta – esto debe incluir contactos primarios y secundarios.

• La herramienta debe permitir notificar a personas ajenas a la mesa de servicio (por ejemplo a quien pidió la solicitud) del estado o avance de su solicitud.

• Debe manejar registro de tiempos entre estados e identificación del usuario que lo ejecutó.

• Debe permitir manejar niveles de escalamiento, vale decir que el sistema genere alertas visibles en la aplicación y vía correo electrónico, además de acciones automáticamente, en base a parámetros relacionado con cambios de estados, prioridades y tiempos definibles por la empresa.

• La herramienta debe manejar alertas y/o envío de mensajes a grupos de responsables en las situaciones donde un incidente/problema este alcanzando los tiempos máximos (UMBRAL) de soporte con el fin de tomar las determinaciones respecto del escalamiento funcional o jerárquico que se requiera

• La herramienta debe producir reportes a partir de criterios de búsqueda

• Los reportes generados por la herramienta, deben poder mostrar cuando se exceden los umbrales como reportes de excepción – por ejemplo:

  • Mostrar todos los casos de un usuario que reporta más de dos Incidente/problemas en cada mes.

  • Mostrar todos los casos de un componente para el cual se comunica más de un Incidente/problema al mes.

• En la herramienta se deben crear reportes que muestren análisis de tendencias de datos de Incidente/Problemas – por ejemplo, números mensuales de Incidente/problemas por categoría, departamento, etc.

• Los usuarios de la herramienta, deben poder consultar sobre el estado de su Incidente /Problema vía formas de e-mail o vía el web.

• Debe manejar registro de tiempos entre estados e identificación del usuario que lo ejecutó.

• La herramienta debe tener la capacidad de establecer la correspondencia del nuevo Incidente/problema con Registros de Incidente previos, Registros de Errores Conocidos, Registros de Problemas, dentro del registro de la llamada con el fin de identificar soluciones

• La herramienta debe ser capaz de acceder a la CMDB para correlacionar el registro del Incidente/problema con los CI´s involucrados, uno o muchos.

• Debe proveer fácil acceso a la información relacionada al incidente/problema, respecto a soluciones que aplican, historial del usuario o personas relacionadas, historial de los activos relacionados, con el fin de una rápida revisión.

• La herramienta debe permitir contar con una bitácora electrónica de todas las actividades de cada incidente/problema, almacenando Fecha, Hora y Usuario que documento cada una de las actividades para solucionar un incidente/problema.

• El sistema debe almacenar la Fecha y Hora, así como el número de incidente/problema creado de manera automática.

• La herramienta debe considerar horarios de trabajo y días de asueto de las diferentes áreas para el proceso de escalamiento.

• La herramienta debe permitir clasificar los incidente/problemas por servicio afectado.

• La herramienta dentro del concepto de "Autoservicio" deberá permitir al usuario final realizar consultas y seguimiento de los incidente/problemas.

• La aplicación debe permitir el manejo de bases de datos de conocimiento propias, las cuales puedan ser alimentadas durante el proceso de Administración de Problemas

• La herramienta debe permitir búsquedas sobre la base de datos de conocimiento.

• La herramienta debe permitir a los usuarios finales consultar la Base de Conocimientos a través de la misma interfaz web de autoservicio.

4.2 Gestión de cambios

• La herramienta debe permitir controlar cambios dentro de la infraestructura de la Institutción.

• La herramienta debe permitir llevar aprobación de cambios.

• La herramienta debe permitir el manejo automatizado de los procesos relacionados al la Administración de cambios.

• La herramienta debe manejar flujos de procesos para la administración de cambios.

• La herramienta debe permitir controlar cambios dentro de la infraestructura de la Institutción.

• La herramienta debe permitir llevar aprobación de cambios

4.3 Base de datos de configuraciones

• La herramienta debe permitir la construcción de una base de datos de registros de los clientes, a la cual se puedan agregar detalles del hardware y software asociados.

• La herramienta se integrará con MS System Management Server y/o con herramientas de otras casas comerciales, como Hp Open View, Maxima, Tivoli, Computer Associates.

• La integración es para el descubrimiento y actualización de hardware y software.

• Herramientas con una clara CMDB donde permita contener y relacionar todos los CI's de la empresa

• La herramienta debe ofrecer la posibilidad de trabajar con Plantillas para CI´s (p.e. configuración estándar de una PC), sobre la cual se puedan realizar pequeños ajustes. Debe permitir el crear nuevas plantillas de CI´s, cambiar el estado de los CI´s.

• La herramienta debe diferenciar CI's críticos para el negocio que le permita al personal de soporte clasificar los registros de problemas

• La herramienta debe ser capaz de entregar la información detallada de todo el ciclo de vida del activo, esto quiere decir desde que ingresa en el inventario hasta que se da de baja

• La herramienta debe tener la capacidad de registrar un repositorio de administración de Activos Autorizados, los que son ingresados por procedimientos contables tradicionales de adquisición o recepción desde proveedores, y por separado proveer de un repositorio de activos descubiertos tecnológicamente a través de herramientas de descubrimiento que informen la configuración actual

• Debe entregar funcionalidades de reconciliación entre los Activos TI que están autorizados contablemente en la organización, versus los que son descubiertos por herramientas de autodescubrimiento.

• Debe poder manejar la condición de cada CI, considerando estado en reparación, dado de baja, en bodega, reemplazo, siempre asociado a su ubicación o rol funcional.

• Debe permitir asociar a cada CI' un responsable, un custodio y los diversos usuarios de la organización relacionados con el.

• La base de datos de conocimientos debe poder consultar documentos externos como (pdf, html, doc)

• La herramienta debe permitir diferenciar CI's críticos para el negocio que le permita al personal de soporte clasificar registros de problemas

• La herramienta debe permitir el manejo automatizado de los procesos relacionados al Change Control Management (CAB).

5. Implementación

• La propuesta debe incluir la instalación, configuración y puesta en marcha de la solución adquirida, según las necesidades de la institución y las mejores prácticas recomendadas por Itil v 3.0.

• La propuesta debe incluir una etapa de toma de requerimientos para validar las necesidades de la empresa.

• La propuesta debe incluir la adaptación de la herramienta en base a los requerimientos definidos en el punto anterior.

• La propuesta debe incluir la carga de datos (por parte del proveedor) para el inicio de la operación.

• La propuesta debe incluir la permanencia del proveedor mientras se estabiliza la aplicación.

• Para la toma de requerimientos, diseño y configuración de los procesos a implementarse se deben seguir las mejores práctica propuestas por ITIL adaptadas a los requerimientos de la institución.

• Los procesos a implementarse son: incidentes, problemas, configuración y cambios

• Incidentes: este proceso tiene como objetivos principales el restablecer los servicios de TI en caso de falla, restaurar la operación del servicio a un estado normal tan pronto como sea posible y minimizar el impacto adverso a las operaciones del negocio.

• Problemas: este proceso tiene como objetivo principal el disminuir el número de incidentes al identificar la causa raíz de las fallas y consecuente la disminución en la generación de incidentes recurrentes.

• Cambios: este proceso tiene como objetivo el asegurar que métodos y procesos estandarizados sean usados para manejar eficientemente todos los cambios, en orden de minimizar el impacto de cualquier incidente relacionado con el servicio.

• Configuración: este proceso tiene como objetivo proveer un modelo lógico de la infraestructura de IT identificando, controlando, manteniendo y verificando las versiones de todos los Items de Configuración (CIs) en existencia.

• Entre las actividades a realizarse para la puesta en marcha de los procesos y funcionalidades deberían incluirse las siguientes:

• Definición de los procesos y funcionalidades .

• Identificación y establecimiento de: políticas, procedimientos, roles y responsabilidades asociadas a los procesos y funciones.

• Definición de reportes según mejores prácticas y necesidades de negocio.

• Documentación de los procesos y funciones.

• Documento de análisis y planificación

• Plan de pruebas de aceptación.

• Por cada proceso se deben entregar un documento que contenga:

• Resumen ejecutivo

• Objetivos y beneficios de implementar el proceso

• Alcance,

• Análisis y Evaluación del proceso actual.

• Flujo del proceso a implementarse

• Funciones básicas,

• Roles,

• Actividades,

• Relación con otros procesos,

• Métricas

• Recomendaciones

• La funcionalidad a implementarse es: del Service Desk como único punto de contacto entre TI y el negocio

• Todos los flujos de trabajo definidos en los procesos y funcionalidades deben quedar funcionando en la solución.

• Para la implementación se exige un equipo de trabajo por parte del proveedor de al menos:

• Un Gerente de Proyecto, es el responsable por las definiciones claves, de la planificación y control del proyecto, del logro de los objetivos y asignación y coordinación de los recursos claves.

• Debe tener mínimo 3 años de experiencia como gerente de proyectos similares,

• Debe tener 2 años de experiencia en la herramienta ofertada.

• Un consultor Funcional, es el responsable de la toma de requerimientos, el diseño y documentación de los procesos.

• Debe tener mínimo 2 años de experiencia como consultor funcional en proyectos similares, y ser certificado Itil.

• Debe tener 3 años de experiencia en la herramienta ofertada.

• Un consultor técnico, es el profesional que realiza la implantación y configuración de los procesos diseñados en el producto (modificación de pantallas, configuración de la base de datos, etc.)

• Debe tener mínimo 2 año de experiencia como consultor técnico en proyectos similares,

• Debe tener 3 años de experiencia en la herramienta ofertada y ser certificado en la herramienta.

• La Institutción dispondrá de un equipo de trabajo contraparte.

• El proveedor deberá incluir en su propuesta el cronograma estimado.

6. Soporte y mantenimiento

• El producto debe incluir Soporte técnico durante un tiempo mínimo de un (1) año, posterior a la firma del acta de entrega recepción única.

• El servicio de mantenimiento debe incluir la capacidad de abrir casos de soporte directamente con el fabricante, ya sea por telefónico o a través de un portal de soporte. Sin depender del proveedor.

• El servicio debe incluir la provisión, sin cargo alguno, de las actualizaciones del producto ofertado y las mejoras que pudieron ser desarrolladas durante el lapso del servicio contratado, junto con la documentación correspondiente.

• El servicio de mantenimiento debe incluir un horario de atención de 5 x 8, para todos los incidentes.

• El servicio debe incluir un usuario para acceder al portal de soporte del producto ofertado para encontrar los parches e información técnica de manejo del producto. Sin dependencia del proveedor,

• Los servicios profesionales de diseño, configuración e implementación deben tener una garantía de al menos 6 meses.

7. Capacitación

• La propuesta debe incluir una capacitación en la administración de la aplicación y generación de reportes.

• Este curso debe enseñar las funciones básicas de cómo utilizar las herramientas que provee el producto para su administración así como la administración de reportes. Este curso está enfocado en las funciones que el administrador usa para configurar, controlar y mantener el ambiente de trabajo del producto.

• Duración: mínimo 2 días

• Participantes: mínimo 5 personas

• La propuesta debe incluir una capacitación en la parte funcional de la herramienta.

• Este curso debe enseñar cómo se utiliza la aplicación para acceder a la arquitectura entera del proyecto, incluyendo técnicas comunes de navegación y acceso a datos.

• También debe proporcionar el conocimiento y las habilidades básicas necesarias para explotar las capacidades de la herramienta y optimizar la administración de servicio, mejorar su disponibilidad y atenuar los riesgos.

• Duración: mínimo 3 días

• Participantes: mínimo 5 personas

• A los efectos de desarrolla una transferencia de conocimientos intensiva y eficiente, se realizará el plan de implementación mediante un proceso de realización de tareas compartidas entre los especialistas de la empresa contratista y el personal de la institución

8. Licenciamiento

• El oferente deberá proveer las licencias del Software necesarias para la utilización del producto a perpetuidad.

• El licenciamiento deberá ser a nivel corporativo.

• Se necesita el siguiente esquema de licenciamiento:

• Se necesita el siguiente esquema de licenciamiento:

	Service Desk/ Incident/Problem	Change
Nombrados	2
Concurrentes	7	2

• Las licencias básicas (servidor, reporteador, etc) requeridas para la implementación de los productos ofertados.

Integración con:

• Oracle Grid

• Net View (tyvoli)

• Insight Manger (HP)

Qué ofrecen en la integracion (funcionalidad) y cuanto cuesta.

• Se debe cotizar a manera referencial los precios de soporte del producto para los próximos tres años.

9. Tiempo de entrega

• 5 meses desde la firma del contrato para terminar de implementar y estabilizar la solución.

Saludos/Greetings
Quiliro Ordóñez
593(02)340 1517 / 593(09)821 8696