Pliego Bases Técnicas · Importación de la base de datos de solicitantes de Etxebide....

V 09/11/2015

Pliego de Bases Técnicas:

Implantación ERP corporativo

ego Registro de Contrataciones

2

P

lieg

o B

ase

s T

écn

ica

s

Índice

1. Información sobre Alokabide ................................................................................ 3

2. Escenario actual .................................................................................................... 3

3. Contexto ............................................................................................................... 5 4. Alcance .................................................................................................................. 5 5. Objeto ................................................................................................................... 6 6. Descripción del proyecto ...................................................................................... 7

6.1. Modelo de datos ................................................................................................... 7

6.2. Requisitos Entidades principales ........................................................................... 7 Expediente Solicitante ........................................................................................... 7

Vivienda ................................................................................................................. 9 Contratos............................................................................................................. 12

6.3. Requisitos por procesos ...................................................................................... 13

Adjudicación de viviendas ................................................................................... 13

Contratación........................................................................................................ 14

Gestión de arrendamiento .................................................................................. 15

Fin de contrato y renovaciones ........................................................................... 17 Tanteos y ofertas de venta .................................................................................. 17

Gestión económica-financiera ............................................................................ 17 6.4. Requisitos generales ........................................................................................... 18

Experiencia de usuario ........................................................................................ 18

Rendimiento ........................................................................................................ 19

Gestión documental. ........................................................................................... 19

Intercambio de información con terceros........................................................... 19 Interacciones ....................................................................................................... 20

Generación de Históricos .................................................................................... 20

Generación de listados ........................................................................................ 20

6.5. Migración de los datos ........................................................................................ 20

6.6. Funcionalidad descrita ........................................................................................ 20

6.7. Fases del proyecto .............................................................................................. 21

6.8. Gestión de la seguridad ...................................................................................... 24

6.9. Licenciamiento .................................................................................................... 24

6.10. Entorno tecnológico ..................................................................................... 24

7. Gestión del proyecto ........................................................................................... 25

7.1. Recursos Materiales: Lugar de trabajo/equipamiento........................................ 25

7.2. Planificación de alto nivel ................................................................................... 25

7.3. Equipo de Proyecto ............................................................................................. 25

Cambios en la composición del equipo ............................................................... 27 7.4. Organización del Proyecto y Estructuras de Control ........................................... 28

7.5. Puntos de Riesgo ................................................................................................. 29


3

P

lieg

o B

ase

s T

écn

ica

s

1. Información sobre Alokabide

ALOKABIDE es la sociedad pública dependiente del Gobierno Vasco para el desarrollo de la función social de la vivienda a través de la política de alquiler. Moviliza y gestiona vivienda en régimen de alquiler protegido para las personas que acrediten necesidad de la misma, actuando en base a criterios de sostenibilidad y de forma coordinada con otros agentes público-privados implicados de la CAE. La actuación de ALOKABIDE se enmarca en la apuesta decidida del Gobierno Vasco por el alquiler protegido de viviendas, en especial en la modalidad de viviendas sociales. Entre los parques de vivienda que se gestionan desde ALOKABIDE se encuentran:

• Viviendas sociales propiedad de ALOKABIDE destinadas al alquiler (más de 3.200)

• Viviendas sociales y alojamientos dotacionales propiedad del Gobierno Vasco y cuya

gestión encomienda a ALOKABIDE (más de 2.800)

• Viviendas privadas incluidas en el Programa Bizigune, mediante el cual un propietario o

propietaria particular cede a ALOKABIDE su vivienda libre para destinarla a un alquiler

social a cambio de unas garantías establecidas (más de 5.000 viviendas)

• Viviendas en arrendamiento propiedad de Ayuntamientos y otras Entidades, que

encargan su gestión a ALOKABIDE (más de 140 viviendas y más de 6 entidades

diferentes)

Por otro lado, ALOKABIDE es agente colaborador del Programa Asap, mediante el cual se ofrece a propietarios o propietarias de viviendas libres, un servicio de intermediación del alquiler mediante unas garantías aportadas por el Gobierno Vasco. Además, desde ALOKABIDE se gestionan ofertas de venta de viviendas de protección oficial entre particulares, y ejercita el derecho de tanteo en representación del Gobierno Vasco.

2. Escenario actual

ALOKABIDE se encuentra actualmente en una situación en la que dispone de varias herramientas informáticas, y aunque éstas intercambian datos entre sí para mantener la integridad de la información, en base a antiguos modelos y aplicaciones lo que dificulta un tratamiento integral y eficiente de la información de la empresa. La relación actual de sistemas de información está conformada por:

• ERP LOGIC CLASS

� Soporta y gestiona los datos de adjudicatarios, inquilinos, propietarios,

viviendas y contratos de alquiler de los parques propio, de Gobierno Vasco y

Ayuntamiento y otras entidades, así como los datos del programa Bizigune, los


4

P

lieg

o B

ase

s T

écn

ica

s

cuales son importados de ERP Navision. A su vez exporta parte de esta

información a CRM Lantek

� Además soporta y gestiona toda la información económica-financiera

• ERP NAVISION

� Soporta la información de gestión del programa Bizigune (propietarios,

inquilinos, viviendas y contratos), incluida la facturación, exportando parte de

esta información a Logic Class

• CRM LANTEK

� Soporta la gestión del Call Center así como toda la gestión de incidencias de

Alokabide, importando datos de Logic Class para mantener los datos de gestión

necesarios

• OTROS:

• INTRANET SHAREPOINT

� Noticias

� Gestión documental / Conocimiento

� Calendarios

� Espacios colaborativos de trabajo

� Otras aplicaciones (encuestas, etc.)

• DORLET. Área RRHH

� Control presencia

� Gestión permisos y vacaciones

� Espacio del empleado

• BBDD (Access, Excel, etc.)

� Decenas de Access para combinar documentos y/o sacar indicadores

(emisión de contratos, notificaciones, reporting,…)

� Access para el control de desahucios

� Access de registro de pedidos de compra

• Otras aplicaciones

� Conexiones vía ODBC

� Explotación de información y consultas

� Generación de documentos

� Intercambio información con Administraciones y otros

� Gestión del ámbito preventivo social


5

P

lieg

o B

ase

s T

écn

ica

s

3. Contexto

El escenario actual de múltiples plataformas provoca una serie de problemas técnicos y organizativos:

• Ineficiencias operativas que provocan sobrecarga en la plantilla:

o Duplicación de datos y procesos, fruto de la existencia de 2 ERP y 1 CRM

o Dificultades para soportar la casuística del día a día fruto de sistemas que no se

ajustan a las necesidades actuales del negocio y que son cambiantes

o Dificultad en la obtención y explotación de indicadores

o Ámbitos de información y gestión no cubiertos

o Existencia de distintos entornos de trabajo en algunas áreas de gestión

o Lentitud en la ejecución de procesos clave del negocio

o Dificultades para atender operaciones de gran volumen

• Degradación progresiva del sistema, fruto de:

o Modelo de datos inadecuado: muy condicionado por el modelo diseñado en la

implantación inicial de ERP, obsoleto y demasiado simplista

o Necesidad de diferentes procesos batch de intercambio de datos entre

aplicaciones

o Dispersión de los datos

o Rendimientos inadecuados por insuficiente capacidad del sistema para manejar

el actual volumen de información

o Continuos ajustes y evolutivos sobre una base excesivamente manipulada

4. Alcance

En este contexto ALOKABIDE se plantea la implantación de una nueva herramienta de gestión integral. Planificada en diferentes fases a abordar en función de las capacidades y prioridades de ALOKABIDE. Así, en una primera fase que responde al alcance recogido en este pliego, se prevé reemplazar los dos ERP actuales, Logic Class y Navision por una única solución de ERP que dé soporte a los procesos administrativos con propietarios, solicitantes, adjudicatarios, inquilinos, contratos de arrendamiento y a la gestión económica financiera de la empresa, sin perder de vista las integraciones actuales con el resto del sistema. Aunque no sea objeto de esta contratación, se anticipan algunos aspectos a resolver en una segunda fase para que el diseño de la primera no los limite ni condicione:

• Business intelligence.

• Gestor documental.

• C.R.M.


6

P

lieg

o B

ase

s T

écn

ica

s

5. Objeto

El objetivo del proyecto es realizar la implantación de un ERP basado en Microsoft Dynamics NAV 2015, que garantice la funcionalidad que ya ofrecen los ERPs actuales Navision + Logic + desarrollos sobre ofimática, de forma que alcance ese escenario y además ofrezca al menos las siguientes mejoras:

• Modelo de datos único, adecuado, flexible y escalable de forma que permita, soportar

las necesidades actuales y futuras (CRM; B.I. y otras) de ALOKABIDE derivadas del

desarrollo de las siguientes fases previstas

• Modelo de datos que garantice la coherencia de la información

• Que la solución soporte, como mínimo, todos los procesos de ALOKABIDE que

actualmente soportan las aplicaciones, sin los gaps que presentan los ERPs actuales.

• Mejora de eficiencia en todos los procesos, tanto en la facilidad de uso como en los

tiempos de respuesta del sistema

• Mayor facilidad para la integración con otros sistemas a través de estándares

• Mejor experiencia de usuario en todos los sistemas

• Diseño teniendo en cuenta una evolución tecnológica futura

• Servir de base sólida y fiable para las próximas fases del rediseño completo de sus

sistemas.


7

P

lieg

o B

ase

s T

écn

ica

s

6. Descripción del proyecto A continuación se describen los requisitos básicos que el ERP debe cubrir. No trata de ser un

inventario exhaustivo sino una aproximación de necesidades que permita comprender a

grandes rasgos la problemática a resolver.

6.1. Modelo de datos

En la gestión de ALOKABIDE intervienen una serie de entidades principales cuya definición y relación entre sí es clave para el diseño y evolución futura del modelo de datos y así como de herramientas informáticas que se basarán en dicho modelo. Es importante resaltar que el modelo de datos requerido no encaja de forma natural con el esquema clásico de un ERP, siendo necesario crear diferentes entidades intermedias alrededor de los principales maestros (Clientes, Proveedores, Maestros de artículos, etc.) para cubrir las necesidades actuales de ALOKABIDE y para adaptarse con flexibilidad a escenarios futuros. Destacar que una misma persona usuaria de los servicios (contacto) puede desempeñar roles simultáneos en su relación con Alokabide (Solicitante-Inquilino) (Propietario-Inquilino) así como tener múltiples relaciones a lo largo del tiempo. Es un riesgo que se debe considerar el hecho de que los usuarios actuales de las aplicaciones consideran que algunas de las limitaciones del sistema actual y su degradación progresiva vienen motivadas en parte, por forzar un encaje directo en las tablas nativas de los productos ERP. Este aspecto se considera de máxima criticidad dentro del proyecto, siendo vital realizar un análisis exhaustivo de alternativas para cubrir el escenario actual y posibles derivadas futuras.

6.2. Requisitos Entidades principales

Se incluye una descripción resumida de cada entidad, que permita tener una visión global de las gestiones que realiza ALOKABIDE y ayude a comprender las necesidades que se presentan. No se trata en ningún caso de un diseño definitivo sino de una primera aproximación que ayude a comprender el escenario de trabajo.

Expediente Solicitante

Se entiende como Solicitante la persona que opta al alquiler de una vivienda. Normalmente los solicitantes deben estar inscritos en el Servicio Vasco de Vivienda (Etxebide) o en registros forales o municipales. Es el paso previo para convertirse en adjudicatario de una vivienda, para posteriormente convertirse en renunciatario o arrendatario.


8

P

lieg

o B

ase

s T

écn

ica

s

En aquellos casos en los que se materialice la adjudicación debe establecerse una vinculación entre el solicitante y su correspondiente cliente. Sería una entidad anterior a la de Cliente/Proveedor y por lo tanto previa a la creación del Cliente, en cuyo caso debe existir una vinculación entre el Solicitante y un Cliente. En un expediente de solicitante puede constar más de una persona, ya que la solicitud incluye a todos los miembros de la unidad convivencial.

A nivel de gestión de Solicitantes se han detectado las siguientes necesidades:

� Importación de la base de datos de solicitantes de Etxebide. � Importación de información de inquilinos de terceros � Importación de la base de datos de solicitantes web (ASAP). � Mecanismo para control de duplicados: a través del nombre, DNI, Tarjeta

residencia, etc. � Posibilidad de fusionar solicitantes. � Gestión de diferentes estados del solicitante.

� Miembros de Unidad Convivencial - MUC relacionados con Solicitante

� Indicar los MUC o personas que residen o vayan a residir en el mismo hogar (unidad convivencial)

� No limitar el número de MUC por Solicitante � Recoger datos de identificación: nombre, DNI, Parentesco, etc. � Recoger los datos económicos de los MUC y su ejercicio fiscal considerado.

� Condiciones acceso

� Cálculo de renta en función de los ingresos declarados por los miembros de la unidad convivencial un momento concreto

� Información anual o para un período � Auditoría de campos. � Un solicitante puede ser además inquilino de otra vivienda de cualquier parque.


9

P

lieg

o B

ase

s T

écn

ica

s

Vivienda

� Gestión de los diferentes estados y sub-estados para controlar fácilmente la situación en la que se encuentran las viviendas.

� Listados para el control sobre las Viviendas activas a partir de los estados. � Valorar la creación de un histórico de viviendas para evitar problemas de

rendimiento fruto del crecimiento constante de esta tabla.

� Parque

� Capacidad para crear y parametrizar diferentes parques.

� Parque propio de ALOKABIDE

o Planning de promociones. o Adquisición viviendas. o Puesta a punto de viviendas. o Solicitudes inquilinos de Etxebide. o Adjudicación realizada por Gobierno Vasco. o ALOKABIDE notifica adjudicatario. o ALOKABIDE firma contrato con inquilino o puede haber renuncias.

� Parque de Gobierno Vasco

o Planning de promociones de viviendas del Gobierno Vasco. o Notificación de promociones y viviendas a ALOKABIDE (también existe baja de

viviendas). o Solicitudes inquilinos de Etxebide. o Adjudicación realizada por Gobierno Vasco. o Gobierno firma contrato de arrendamiento entre Gobierno – Inquilino o Notificación a ALOKABIDE del contrato de alquiler.

� Viviendas privadas incluidas en el Programa Bizigune

o Solicitud propietario (llega a través de Call Center u oficina). o Cita masiva. Explicación programa a propietario. o Aceptación propietario.


10

P

lieg

o B

ase

s T

écn

ica

s

o Aportación documentación. o Solicitud de informe técnico del estado de la vivienda con diferentes estados o Alta de propietario y vivienda en el sistema. o Firma de contrato de usufructo con propietario (demora hasta que se adjudique

con posibilidad de romperlo si en 6 meses no se alquila). o ALOKABIDE parte de la BBDD de Solicitantes de Etxebide o ALOKABIDE barema y adjudica la vivienda. o Firma de contrato o renuncias.

� ASAP

o ALOKABIDE capta propietario y vivienda (igual que en Bizigune, hasta la aceptación del propietario).

o El Solicitante de Etxebide a través de la web selecciona vivienda. o ALOKABIDE coordina la firma del contrato de arrendamiento entre propietario

e inquilino. o Gestión posterior de ALOKABIDE (seguros de impagos y seguros de incidencias).

� Parque terceros - Ayuntamientos

o Las viviendas son de los Ayuntamientos. o La información de inquilinos la notifica el ayuntamiento correspondiente. o Ayuntamientos bareman inquilinos y adjudican (existe casuística en la que se

gestiona también la adjudicación). o ALOKABIDE recibe el adjudicatario y firma el contrato de arrendamiento.

� Parque terceros - Otros

o Convenio para cada promoción o ALOKABIDE gestiona la adjudicación. o Firma de contrato ALOKABIDE con inquilino o renuncia.

� Comunidades

� Gestión de comunidades en sus diferentes variantes dependiendo del parque.

o ALOKABIDE. o Gobierno Vasco. o Bizigune. o Ayuntamientos.

� Pago de ALOKABIDE al Administrador si el inquilino no paga la comunidad.

� Gestiones con área técnica

o Por cada Comunidad se deben identificar las viviendas que la componen. A su vez una Vivienda puede estar relacionada con varias Comunidades.

o Identificación del Administrador de la Comunidad. o Traslado a la herramienta de actas de comunidad.

� Área financiera

o Definición de conceptos de facturación relacionados con la Comunidad complementarios a los que se van a definir en el Contrato. Gastos puntuales repercutibles e Impagos.

o Debe permitir indicar a nivel de Comunidad gastos variables que puedan existir de manera puntual en algunos meses: conceptos como derramas, etc.


11

P

lieg

o B

ase

s T

écn

ica

s

o Posibilidad de identificar si los conceptos adicionales deben repercutirse al inquilino o no, y en qué fecha.

o Inclusión de los conceptos adicionales repercutibles en el proceso de facturación mensual y su reflejo en el Contrato.

o Registro de Impagados y posterior proceso de generación de la Factura de Compra.

o Intercambio de ficheros con las Comunidades.

� Promociones

� Datos básicos de Ubicación, Calificación, Certificación energética, etc. � Relación de los portales incluidos � Relación de las Comunidades asociadas. Una Comunidad sólo puede tener relación

con una Promoción. � Relación de Viviendas. Una Vivienda sólo puede pertenecer a una Promoción.

� Edificios

� Gestión de mantenimiento correctivo/preventivo

� Información básica como

o Dirección o Nº de viviendas o Aseguradora y Nº de póliza o Identificación del Gestor de Incidencias técnicas o Empresa de Mantenimiento con contrato en el edificio o Operaciones de mantenimiento preventivas, frecuencia de realización y

empresa encargada de llevarlas a acabo

� Titulares - relacionados con vivienda

� Identificación de titulares de la vivienda que figuran en las escrituras. Datos como nombre, apellidos, DNI (u otro documento probatorio) de los titulares con su porcentaje de titularidad, indicando siempre quién es el principal.

� Propietario

� Múltiples roles en función del tipo de parque. Puede ser Proveedor y/o Cliente.


12

P

lieg

o B

ase

s T

écn

ica

s

Contratos

� Contrato Inquilino

� Contrato de renta que relacione un Solicitante (inquilino) con una vivienda. � Posibilidad de que sobre una vivienda puedan existir varios contratos de inquilinos

diferentes en vigor � Fechas diferentes hitos: fecha firma contrato, fecha inicio contrato, fecha fin, fecha

devolución vivienda, fecha entrega llaves, fecha devolución fianza, etc. � Estado, que identifique claramente la situación del contrato. � Identificación de los diferentes conceptos de facturación � Vinculación de documentos asociados al contrato. � Histórico de comunicados enviados al Inquilino en relación con el contrato.

� Contrato Propietario

� Diferentes tipos de Contrato que se pueden firmar con los Propietarios: usufructo, mandato, otros

� Posibilidad de relacionar un Propietario con varias viviendas � Posibilidad de relacionar la vivienda con varios propietarios indicando porcentaje

de participación sobre la misma.


13

P

lieg

o B

ase

s T

écn

ica

s

6.3. Requisitos por procesos

Se adjunta el mapa de procesos de Alokabide

Adjudicación de viviendas

Desde el sistema deben tener contempladas varias alternativas de adjudicación de vivienda a los solicitantes:

• La adjudicación manual de vivienda a los solicitantes.

• La adjudicación mediante la importación de ficheros emitidos por otros órganos adjudicadores

• La adjudicación mediante proceso parametrizado en el sistema de los datos de solicitantes previamente cargados.

También se deberá tener en cuenta la procedencia de la adjudicación. Se debe permitir el control de bloqueos de viviendas en los distintos procesos de adjudicación debido a la necesidad de reservar viviendas por distintos motivos. Además deberá tenerse en cuenta la gestión de renuncias siendo la renuncia del Solicitante: computable, no computable y gestión de los motivos de renuncia, así como la creación de históricos de renuncias. Como orientación se señala a continuación como se realizan actualmente los procesos:

� Alokabide

� Actualmente se realiza mediante carga manual, estando prevista la emisión por parte del Departamento de vivienda de la generación de ficheros (TXT o XLM)

� Gobierno Vasco

� Proceso de importación de los ficheros XML o Excel suministrados por Gobierno Vasco con las adjudicaciones.

� Bizigune

� Proceso de adjudicación es realizado por el sistema. � Necesidad de parametrizar los criterios de adjudicación. � Proceso automático de adjudicación � Posibilidad de hacer el proceso de adjudicación de forma manual sin verificación

de criterios. � Opción de bloquear vivienda para que no entre en el proceso de adjudicación.

� Parque terceros - Ayuntamientos

� La adjudicación se realiza manualmente


14

P

lieg

o B

ase

s T

écn

ica

s

Contratación

� Paso de Solicitante-Adjudicatario a Inquilino-Cliente

Se deben contemplar distintas modalidades de contratación, arrendamiento, subarrendamiento, precario, cesiones onerosas…así como la posibilidad de prorrogas de contratos y la renovación de los contratos mediante la firma de un nuevo contrato.

Detalle de requisitos:

� Necesidades del proceso de Contratación con el Inquilino variables según el parque de Viviendas.

� Creación del Contrato Inquilino a partir del proceso de adjudicación fijado. � Gestión de los estados del Contrato con control fechas (alta, en vigor, modificación,

cancelación temporal…) � Control de fechas: fecha contrato, fecha fin contrato, fecha prórroga, fecha

vencimiento, casuísticas particulares de cada parque,… � Aceptación y firma del Contrato. Sólo en este caso debe darse de alta al

adjudicatario como cliente � Identificación de los diferentes Conceptos del Contrato que van intervenir en la

facturación dándose la posibilidad de que existan cobros y pagos. � Utilidades para gestión masiva: contratos, conceptos, estados, notificaciones, etc.

con trazabilidad de las operaciones � Herramienta para la importación en diferido del importe correspondiente al

Concepto de IBI y tasas a través de ficheros facilitado por los Ayuntamientos. Información del Fichero llega referenciada a través de la Referencia catastral de la Vivienda.

� Utilidad para realizar reubicación del inquilino. Reserva de viviendas previamente, relacionado con los bloqueos señalados en el punto de anterior: Adjudicación.

� Proceso automático de generación de la fianza, previamente a la firma del contrato de arrendamiento, mediante norma 57 y su validación posterior en expediente y contabilidad.

� Propietario

Se deben contemplar también distintas modalidades de contratación, usufructo, mandato, arrendamiento… y distintas procedencias de propietarios por programas de alquiler.

Contemplar la posibilidad de prorrogas de contratos así como la renovación de los contratos mediante la firma de un nuevo contrato.

� Admisión:

o Gestión de Propietarios interesados en el programa desde Línea 900 (Call Center) u oficina territorial, con discriminación de municipios y tipología de vivienda admisible. .

o Utilidad de definición de citas masivas.


15

P

lieg

o B

ase

s T

écn

ica

s

o Registro de los datos de la entrevista. o Posibilidad de vincular a la solicitud toda la documentación aportada por el

Propietario y chequeos y comprobación de los mismos. o Solicitud de informe técnico del estado de la Vivienda o Funcionalidad de aceptación del Propietario y automatismo para la creación

de la Vivienda y Propietario si no estuviese registrado ya en el sistema. o Trazabilidad entre el registro de la llamada y el alta de la Vivienda. o Inclusión de información sobre la subrogación

� Contrato con propietario

o Control riguroso de fechas: formalización, fechas de entrada en vigor, vencimiento contrato, fecha prórroga.

o Gestión de estados: alta, en vigor, modificación, cancelación temporal, baja definitiva

o Conceptos de contrato: pagos y cobros o Gestión de fianza de compromiso de permanencia en el programa y su

posterior cancelación o Emisión de auto facturas de proveedor a propietario o Comisiones de propietario como cliente.

Gestión de arrendamiento

� Cálculo y actualización renta inquilino

� Proceso actualización anual del importe del concepto de renta, en función de numerosos sistemas de actualización:

o Control de renovaciones a realizar o Posibilidad de lanzar el recálculo de la renta a modo de simulación o Funcionalidad para trasladar la simulación a situación real a través de un

proceso de validación. o Creación de históricos de renovaciones de renta o Realización del proceso de forma individual o de forma masiva. En los

Procesos masivos: el rendimiento es un aspecto crítico

� El algoritmo de cálculo de la renta debe ser altamente parametrizable según el tipo de parque, condiciones del inquilino, tipología de contrato, parque en el que se encuentra, etc.

� Gestión de renovaciones de renta para casos especiales (rentas especiales)


16

P

lieg

o B

ase

s T

écn

ica

s

� Proceso facturación Inquilino

� Proceso crítico dentro del sistema: por importancia, impacto, volumen, rendimiento, etc.

� Requiere de un análisis exhaustivo para enfocar la mejor solución posible. � Posibilidad de agrupación o desagrupación de conceptos facturados en albarán,

factura o efecto. � Funcionalidad para lanzamiento masivo de la facturación mensual. � Máxima trazabilidad para control y seguimiento de impagos. � Posibilidad de creación de procesos batch � Registro y contabilización de las facturas automático en el proceso de facturación,

teniendo en cuenta que se facturan parques que no suponen ingresos para Alokabide (suplidos). .

� Generación automática de las remesas y contabilización de las mismas con los efectos creados en el proceso de facturación.

� Contemplar la posibilidad de definir distintos ordenantes/presentadores de la norma para los distintos parques de viviendas.

� Generación fichero Norma 19 para enviar al Banco. � Fijación fecha de pago. � Generación de fianzas Norma 57. � Mecanismo para la devolución de la fianza al inquilino mediante la Norma 34. � Opción de registrar depósito de garantía suministros, gestión de emisión de N57,

cobro y devolución. � Facturación Gobierno Vasco. � Proceso de conciliación entre rentas y facturación � Posibilidad de realizar neteo entre efectos de cobros y pagos

� Proceso facturación Propietario

� Posibilidad de ejecución batch � Facturación ordinaria. � Facturación extraordinaria. � Trazabilidad y control de errores � Informes de control sobre la facturación real emitida y detección de discrepancias. � Utilidad de suspensión de pagos al Propietario.

� Gestión impagos Inquilinos

� Seguimiento de los cobros e impagos. � Proceso de importación del fichero de devolución de la Norma 19 � Generación remesa con los impagados. � Generar Norma 57 a partir de la remesa de impagados � Importación del fichero del banco con los cobros realizados a través de Norma 57 � Unir o dividir efectos con cambios de vencimientos. Acuerdos de cobro. � Pago por parte de terceros.


17

P

lieg

o B

ase

s T

écn

ica

s

Fin de contrato y renovaciones

� Inquilino

� Control y seguimiento de vencimientos de contrato. � Herramienta para la gestión de notificaciones � Control sobre las viviendas para inspección y puesta a punto � Gestión Baja Contrato. � Gestor de ficheros XML que permita importación de la información de las Bajas

suministrada por Gobierno Vasco. � Renovación Alkondoren/Euskondoren/Ondoren inquilinos. � Prórrogas. Ondoren o tácita.

� Propietario

� Obtención del listado de Propietarios a los que les vence el contrato � Generación automática y masiva de comunicados a Propietarios � Contemplar la casuística de cada parque � Parametrización de los meses/años ampliables en cada caso.

Tanteos y ofertas de venta

El parque de viviendas sobre las que ALOKABIDE puede ejercer el derecho de tanteo en representación del Gobierno Vasco es residual y no debe ser determinante a la hora de elegir una nueva herramienta. Aun así, el nuevo sistema debe ofrecer la posibilidad de que se puedan gestionar las ofertas de venta de viviendas de protección oficial desde ALOKABIDE.

Gestión económica-financiera

La gestión económica, financiera y contable de ALOKABIDE no presenta particularidades significativas. A continuación se identifican de forma muy general los requerimientos de alto nivel o ámbitos que la solución informática debe cubrir.

� Contabilidad: Contabilización de facturas, bancos, fianzas, impuestos, nóminas, amortizaciones, provisiones, periodificaciones de intereses y subsidiaciones, subvenciones de capital, préstamos, etc. En este sentido, existe alguna particularidad a tener en cuenta:

o Por cada parque de viviendas se lleva una contabilidad específica, que se vuelca en la contabilidad general de ALOKABIDE. Se debe proponer alternativas flexibles y eficientes para poder llevar el control económico (contable o analítico) de cada parque, pero sin penalizar la contabilidad general de la Sociedad ALOKABIDE.

o En este sentido, se debe tener en cuenta que existe registro de facturación de terceros (de Gobierno, Ayuntamientos, etc.) que no deben registrarse en


18

P

lieg

o B

ase

s T

écn

ica

s

libro de IVA, ya que el ordenante no es ALOKABIDE. Lo mismo puede ocurrir con los gastos.

� Contabilidad analítica: posibilidad de estructurar la analítica en múltiples dimensiones, como por ejemplo: Parques, promociones, edificios, viviendas, Departamentos (de ALOKABIDE), Oficina Territorial, Partida presupuestaria…

� Contabilidad presupuestaria: determinación partidas presupuestaria y seguimiento presupuestario.

� Gestión bancaria: Permitir la gestión manual de cobros y pagos, permitir la gestión de remesas de cobros y pagos, automatización de procesos de conciliación bancaria y automatización de la contabilización de cobros y pagos, etc.

� Tesorería: funcionalidades para realizar una previsión y seguimiento de la situación de tesorería.

� Impuestos: control, cálculo y generación de modelos de impuestos IVA, IRPF, IS, IAE, 347, etc.

o Existe una particularidad con la gestión del IVA, en el que pueden existir diferentes modelos de contabilización del IVA, en función del parque de viviendas gestionado (en la actualidad existen 3 modelos: IVA no deducible / IVA con parte deducible y parte no deducible / IVA deducible completamente).

� Flujo de aprobación de facturas de proveedores, con autorizaciones en función de los importes y contabilización automática.

6.4. Requisitos generales

Experiencia de usuario

En algunos ámbitos de la solución es vital disponer de una estructuración de información en pantalla eficiente. Se definirán distintas pantallas en función de la información necesaria para cada perfil de usuario. Así, por ejemplo, los usuarios del sistema que interactúan directamente con el Cliente deben disponer de pantallas resumen de situación que, de una forma muy ágil y ordenada, presenten la información resumida de los mismos:

• Vivienda

• Situación de incidencias

• Facturas emitidas

• Situación de pago

• Etc.

Esta información deber presentarse de forma agrupada sin que se requiera navegar por todo el sistema para ir recopilándola y sin que sea necesario conocimientos profundos para interpretarla.


19

P

lieg

o B

ase

s T

écn

ica

s

Rendimiento

El sistema debe soportar y gestionar con agilidad un volumen elevado de transacciones, siendo crítico el rendimiento en algunos procesos, algunos de ellos masivos. Actualmente se maneja un parque aproximado de 15.000 viviendas.

Gestión documental.

Posibilidad de hacer uso de diferentes modelos de documentación con información vinculada a las entidades principales de forma que pueda ser posible generar dicha documentación y mantener una trazabilidad de los documentos generados a lo largo del tiempo, así como la posibilidad de gestionar la biblioteca de plantillas de documentos.

Se requiere por tanto de una herramienta ágil y flexible para la generación masiva de documentos de uso interno y externo: comunicaciones, certificaciones, etiquetas, desde cualquier ámbito de gestión y su posterior validación y confirmación del envío. Debe ser posible parametrizar mediante filtros este tipo de documentación. Además seguimiento de envío y recepción de comunicaciones mediante correo ordinario, certificados, notificaciones administrativas…

Intercambio de información con terceros

Se requiere un mecanismo ágil y flexible que permita la interoperabilidad mediante la utilización de los actuales estándares de intercambio de información con otros sistemas tanto en base a intercambio de ficheros como con otros servicios. Debe permitir la importación y exportación de ficheros en distintos formatos (TXT, XLM, EXCEL…) de forma permanente y mediante la utilización de filtros. El sistema debe garantizar la trazabilidad de la información para generación de dichos archivos. Actualmente se intercambian como ejemplo ilustrativo:

• Importación de Solicitantes de Etxebide

• Importación repercusiones e impagos con Comunidades

• Importación de las adjudicaciones (altas y bajas) en XML proporcionado por Gobierno Vasco

• Exportación de Información con la relación de Vivienda –Propietario/Inquilino - Contrato (Programa Bizigune)

• Exportación de Información sobre el detalle de los inquilinos.

• Diputaciones Forales. IRPF, tanto en la importación de datos económicos de los usuarios como en la generación de certificados I.R.P.F.

• Ficheros para Correos con la información requerida para los envíos postales.

• Intercambio información a través de plataformas informáticas con Gobierno Vasco (EJIE): licitación electrónica, Atrio, registro de representantes, pasarela de pago con Gobiernos vasco, Extranet JASO

• Interoperabilidad: con Administración general del estado, con seguridad social, con haciendas forales

• Etc.


20

P

lieg

o B

ase

s T

écn

ica

s

Interacciones

En la primera fase se requiere al menos la interacción de las siguientes entidades con otras herramientas dentro del mapa de sistemas de ALOKABIDE.

• Expediente solicitante, titulares e inquilinos.

• Viviendas, parques, promociones, edificios.

• Comunidades.

• Propietarios.

• Proveedores

• Contratos con proveedores.

• Gastos con proveedores.

Generación de Históricos

Se precisa la funcionalidad de creación de históricos de cambios para su registro y trazabilidad en diferentes ámbitos:

• Adjudicación.

• Gestión de renuncias.

• Actualización de rentas y otros conceptos de facturación.

• Renovaciones de contrato.

• Bajas de contratos.

• Viviendas incluidas y excluidas.

Generación de listados

En todos los ámbitos deberán parametrizarse listados.

6.5. Migración de los datos La migración de datos debe llevarse a cabo como una tarea crítica del proyecto: el arranque del nuevo ERP debe tener un impacto mínimo en ALOKABIDE, para lo que se requiere la migración de la información actual e histórica relacionada con el objeto y alcance de esta licitación como por ejemplo todos los maestros, operaciones vivas, históricos, etc.

6.6. Funcionalidad descrita La relación de funcionalidades descrita en los apartados anteriores es meramente orientativa para que las empresas licitadoras tengan un punto de partida para poder dimensionar el proyecto de cara a elaborar la oferta.

La empresa adjudicataria, a lo largo del ciclo de vida del proyecto, deberá elaborar la relación de funcionalidades definitiva, que lógicamente podrá variar en cierta medida de la aquí expuesta, pero en todo caso ALOKABIDE se reserva la potestad de exigir la implantación de las funcionalidades aquí descritas plenamente operativas.


21

P

lieg

o B

ase

s T

écn

ica

s

6.7. Fases del proyecto

Las principales fases que abarcará el proyecto son las siguientes:

1. Análisis

Durante esta fase se llevarán a cabo aquellas tareas necesarias para la correcta planificación, organización y lanzamiento del proyecto.

2. Diseño

Se ejecutarán las actividades precisas para obtener el Diseño del proyecto.

3. Desarrollo

En esta fase del proyecto se desarrollarán los trabajos necesarios para tener el sistema preparado para su puesta en marcha.

4. Puesta en marcha

Esta fase abarcará los trabajos necesarios para arrancar el nuevo sistema.

5. Monitorización

En esta fase, posterior a la puesta en marcha del sistema, se deberá supervisar el correcto funcionamiento del sistema y prestar un servicio de soporte.

A continuación se detallan los requerimientos mínimos para cada una de las fases enunciadas:

Fase Descripción

1.-

Análisis

Definición: Tareas necesarias para el correcto lanzamiento del proyecto. Durante esta fase se realizará un análisis de primer nivel tal que, en base al actual mapa de sistemas y a los requerimientos, permita elaborar el plan de proyecto.

Entregables:

o Plan de proyecto, incluyendo al menos: � Alcance. � Inventario de requerimientos. � Descomposición de trabajos y tareas. � Planificación (cronograma con reuniones tareas, tiempos y

recursos, tanto del adjudicatario como de ALOKABIDE). � Plan de comunicación. � Riesgos y planes de respuesta. � Diseño de alto nivel incluyendo un modelo de interacción entre

los distintos módulos del sistema y con los distintos sistemas de información de la organización.


22

P

lieg

o B

ase

s T

écn

ica

s

2.-

Diseño

Definición: Actividades precisas para obtener los diseños Funcional y Técnico del proyecto. Durante esta fase se realizará el análisis funcional del sistema según se indica en el punto “3.1 Funcionalidad”. La relación y el calendario de las entrevistas de toma de requisitos a usuarios clave que sean necesarias para la elaboración del diseño funcional se acordarán en el Comité de Dirección del Proyecto. En todo caso, la empresa adjudicataria no acudirá a estas entrevistas con un formulario en blanco, si no que al contrario, previamente habrá estudiado por su cuenta los documentos que se anexan en relación al análisis de requisitos preliminar no definitivo, los manuales y toda aquella información que desde Alokabide se le haya provisto.

Entregables: o Calendario de entrevistas. o Diseño Funcional del proyecto, incluyendo al menos:

� Catálogo de requisitos funcionales. � Modelos de los procesos a desarrollar. Incluyendo flujos de

trabajo entre áreas y relación de éstos con los módulos del diseño técnico.

� Prototipo basado en diseño de interacción / user interface sketching.

� Diseño de las personalizaciones. � Diseño de los informes y la explotación de datos

o Diseño Técnico del proyecto, incluyendo al menos: � Modelo de integración con otros sistemas. � Diseño individual de cada uno de los módulos del diseño de alto

nivel, incluyendo un diagrama con los distintos componentes de cada módulo.

� Modelo de datos. Incluyendo una relación de las tablas maestras. o Plan de pruebas1, incluyendo al menos tres tipos de pruebas:

� Pruebas funcionales. Tienen como objetivo la comprobación del correcto funcionamiento de todos los puntos de la aplicación, tanto interfaz de usuario como APIs programáticos y relación con otros módulos.

� Pruebas de integración. Tienen como objetivo garantizar la integración de la aplicación con los distintos sistemas de información de ALOKABIDE.

� Pruebas de rendimiento2. Tienen como objetivo la comprobación del desempeño de la aplicación bajo carga de trabajo.

1 Adicionalmente a las pruebas funcionales y de rendimiento, cada componente del sistema debe prever la inclusión de código destinado a las pruebas unitarias. Asociado al diseño técnico del sistema, en especial asociado a los diagramas de componentes se identificarán aquellos componentes susceptibles de ser probados de forma unitaria. 2 Las pruebas de rendimiento tienen que tener en cuenta la conexión con las oficinas territoriales de ALOKABIDE.


23

P

lieg

o B

ase

s T

écn

ica

s

3.-

Desarrollo

Definición: Adaptación del código estándar y creación del código fuente acorde al diseño del sistema y realización de los trabajos necesarios para tener el sistema preparado para su puesta en marcha. Durante esta fase se realizarán al menos las siguientes tareas: o Programación de las personalizaciones. o Programación de la integración con otros sistemas. o Diseño y programación de informes. o Diseño y simulación inicial de la migración para el testeo de la

funcionalidad en base a una precarga de muestra de datos. o Testeo de funcionalidad, de integración y de rendimiento o Diseño y simulación de la migración final de datos. Entregables: o Aplicación desarrollada e implantada en todos los entornos. o Código fuente, diagramas de BD y documentación asociada. o Manuales funcionales. o Informe de resultado de la ejecución del plan de pruebas. o Política de seguridad de la aplicación. o Plan de implantación y puesta en marcha (incluyendo los diseños de

la migración). o Plan de gestión del cambio.

4.-

Puesta en

marcha

Definición: Esta fase abarcará los trabajos necesarios para arrancar el nuevo sistema. Esta fase se inicia una vez ALOKABIDE certifique la superación del plan de pruebas e incluye los siguientes trabajos: o Parametrización del sistema y configuración de la seguridad. o Migración de los datos. o Formación a los usuarios.

Entregables: o Informe del resultado de la migración de los datos. o Evaluación de la formación a los usuarios. o Políticas de mantenimiento de la instalación. o Plan de transición al servicio de mantenimiento cotidiano.

5.-

Monitoriza

ción

Definición: Esta fase comprende los trabajos de soporte al usuario y monitorización del sistema, posteriores a la puesta en marcha. Esta fase se desarrollará durante un mínimo de 2 meses3 y comprende: o Asistencia a usuarios y transición al servicio de mantenimiento

ordinario.

Entregables: o Evaluación del proyecto.

3 Al finalizar esta fase comienza el periodo de garantía establecido sobre los trabajos realizados.


24

P

lieg

o B

ase

s T

écn

ica

s

6.8. Gestión de la seguridad El sistema garantizará el cumplimiento de las políticas de seguridad de la empresa. Para ello, la Política de Seguridad que se diseñe para el sistema, deberá tener en cuenta el menos las siguientes consideraciones:

- Gestión de la seguridad acorde a los requisitos normativos de LOPD y a las exigencias de las auditorías internas.

- Gestión de accesos: o Integración con el Directorio activo o Control de accesos tanto por tablas como por formularios o Gestión de permisos por responsables de módulos

- Implantación de entornos de pruebas y producción - Gestión de la vulnerabilidad técnica - Gestión de la continuidad operacional - Evaluación y tratamiento de los riesgos de seguridad

6.9. Licenciamiento

La adquisición de la licencia de Microsoft NAV 2015 para Alokabide, que constará con un total de 60 usuarios iniciales concurrentes, con las siguientes condiciones:

- 45 usuarios de la licencia de Alokabide se obtienen a partir de la segregación de la licencia a nombre de Visesa, empresa perteneciente al mismo Departamento del Gobierno Vasco y titular de la licencia actual:

Licencia License number: ES-ZA-001-EXDH0-B Licensed to: VIVIENDA Y SUELO DE EUSKADI, S.A. (VISESA)

- 15 usuarios serán nuevos - Adquisición de tablas y objetos adicionales. En la oferta presentada se deberán

reservar 10.000€ del importe asignado al apartado de licencias para satisfacer la necesidad de compra de objetos, tablas, …

- BREP: En el precio de licitación deberá estar incluido el BREP correspondiente a la licencia que está adquiriendo Alokabide

6.10. Entorno tecnológico

A continuación se presenta una descripción del entorno tecnológico general en el que se desarrollan actualmente los desarrollos informáticos:

- Logic Class Advanced v10.36.002 - Microsoft Navision 3.7 en servidor y 5.1 en cliente - Lantek Optima 2013 - Base de Datos SQL-Microsoft Server 2005 Estándar - Citrix Xenapp 6.5 - Puestos de trabajo con Windows W7 - Microsoft Office v2013 - Intranet en Microsoft SharePoint 2010-SP1 Standard y aplicaciones .Net


25

P

lieg

o B

ase

s T

écn

ica

s

Esta relación no es de carácter exclusivo, ni exhaustiva. Comprende los aplicativos principales y por tanto está sujeta a modificaciones.

7. Gestión del proyecto

7.1. Recursos Materiales: Lugar de trabajo/equipamiento

Lugar de Trabajo Las reuniones tendrán lugar en las dependencias de ALOKABIDE4.

Las personas asignadas al proyecto desarrollarán los trabajos en las dependencias de ALOKABIDE.

Equipamiento de desarrollo Equipamiento del Adjudicatario.

Implantación En las dependencias de ALOKABIDE.

Disponibilidad horaria Horario de trabajo de ALOKABIDE5.

7.2. Planificación de alto nivel

La planificación deberá detallar cada una de las fases del proyecto y el desarrollo de cada uno de los módulos y tareas, indicando claramente los recursos y la dedicación de las personas asignadas a cada uno de ellos, tanto para el personal de la empresa adjudicataria como para el personal de ALOKABIDE.

La duración máxima permitida para el proyecto es de 12 meses incluyendo la

monitorización.

En las ofertas se deberá incluir claramente la planificación temporal y los hitos de control en base a los entregables del proyecto.

7.3. Equipo de Proyecto

El presente proyecto, como todos los proyectos, es un esfuerzo temporal económico y de personas en el que se comprometen una serie de recursos para crear un producto único y como tal es muy importante que el equipo de proyecto tenga la capacidad suficiente para abordar el trabajo y que además permanezca estable durante el desarrollo del mismo. Por la razón descrita, el adjudicatario se compromete (en la medida de lo posible) a

mantener un equipo estable de personas que intervendrán en el proyecto según lo

planificado en el Plan de Proyecto.

4 Portal de Gamarra 1-A, Vitoria-Gasteiz. 5 Actualmente el horario vigente (sin perjuicio de modificación) es de 8:00 a 17:00 exceptuando parada de comida con duración flexible de mínimo 30 minutos, a realizar entre las 13:30h y las 15:00h.


26

P

lieg

o B

ase

s T

écn

ica

s

Teniendo esto en cuenta, así como las características del proyecto:

• Se debe proponer un equipo de proyecto estable.

• Distintos roles pueden ser asumidos por un mismo técnico.

• Debe haber una alta interacción con ALOKABIDE.

Los equipos asignados al proyecto por ALOKABIDE y la empresa adjudicataria responderán a la siguiente estructura:

ALOKABIDE

Rol Funciones Funciones en el proyecto

Comité de Dirección

del Proyecto

Alokabide

Dirige y marca las directrices del proyecto de reimplantación del ERP

o Liderazgo del proyecto. o Proporciona las condiciones para la

realización del proyecto. o Validación de hitos parciales, entregables y

toma de decisión en relación a aspectos funcionales horizontales

o Aprobación definitiva de especificaciones y pruebas

o Seguimiento y validación interna del cumplimiento del alcance, comunicaciones, recursos, gestión de riesgos, calidad

Responsable de

Proyecto

Director de Administración y Gestión de contratos

Gestión del Proyecto o Gestión de los recursos del proyecto o Coordinación con el resto de áreas de

ALOKABIDE.

Responsable funcional o Coordinación con los usuarios clave de negocio.

o Aprobación inicial de especificaciones funcionales.

o Seguimiento del avance del proyecto y del trabajo del equipo del proveedor

o Traslado al Comité de Proyecto del estado del proyecto y aprobaciones necesarias

Validación técnica o Aprobación inicial de especificaciones técnicas.

o Aprobación inicial de pruebas técnicas: monitorización, carga, alta disponibilidad, etc.

Apoyo Tecnológico

Procesos y Sistemas Soporte tecnológico o Marca estándares tecnológicos.

o Coordinación con otros proveedores informáticos de ALOKABIDE: implantación, pruebas, etc.

Usuarios clave

Responsables designados para cada Área/Proceso

Usuarios finales del sistema o Especificaciones funcionales. o Aprobación de especificaciones funcionales

de su ámbito de negocio. o Pruebas de negocio. o Aprobación de las pruebas de su ámbito de

negocio y VºBº al desarrollo.


27

P

lieg

o B

ase

s T

écn

ica

s

Empresa Adjudicataria

Rol Funciones Conocimientos

/Experiencia

Gestor del

proyecto

Seguimiento global de la evolución y progreso. Seguimiento y coordinación del resto del equipo asignado al proyecto. Interlocución con el Comité de Dirección del Proyecto de ALOKABIDE

REQUISITO experiencia de 3 años: � Dirección de proyectos de

implantación de ERP’s.

Responsable

Técnico /

Funcional

Arquitectura técnica de la solución. Coordinación del equipo técnico. Interlocución con el Responsable de Proyecto de ALOKABIDE. Supervisión de la implantación. Coordinación técnica con otros proveedores informáticos: implantación, pruebas, etc.

REQUISITO: 3 años de experiencia en: � Proyectos de implantación de MS

Dynamics NAV en empresas del sector inmobiliario.

Desarrollador

(Requerido como mínimo 4 personas)

Diseño y programación de las adaptaciones. Parametrización del Sistema. Implantación del sistema.

REQUISITO: 3 años de experiencia en: � Programación sobre MS

Dynamics NAV.

Diseñador Responsable de las interfaces de usuario. REQUISITO:3 años de experiencia en: � Diseño de interfaces gráficos de

usuario y usabilidad.

Cambios en la composición del equipo

Con el objeto de garantizar la estabilidad del equipo de trabajo, y que se respeta el equipo reflejado en la oferta, se establecen las siguientes condiciones para la realización de cambios en la composición del equipo de trabajo del adjudicatario. La autorización al adjudicatario de cambios puntuales en la composición del equipo de trabajo requerirá de las siguientes condiciones:

1. Solicitud escrita incluyendo justificación detallada y suficiente, explicando el motivo que suscita el cambio, con un mínimo de 15 días antes de que el mismo se haga efectivo.

2. Presentación de posibles candidatos con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir.

3. Aceptación por escrito de la persona sustituta por parte del Responsable del contrato.

4. El traspaso de conocimientos al candidato elegido correrá a cargo de la empresa. estimándose en un mínimo de 15 jornadas laborables desde su incorporación, no facturables.

ALOKABIDE se reserva el derecho de solicitar la sustitución de algún miembro del equipo de trabajo en el caso de que se verifique el incumplimiento de la solvencia exigida en el presente pliego.


28

P

lieg

o B

ase

s T

écn

ica

s

7.4. Organización del Proyecto y Estructuras de Control

Pese a que la organización y los equipos participantes en el proyecto, tal y como se ha descrito anteriormente, se definirán exactamente en la Fase 1.- Análisis, existirá al menos un Comité de Seguimiento de Proyecto que perdurará a lo largo de la vida del proyecto:

Componentes � Comité de Dirección de Proyecto de Alokabide. � Responsable de Proyecto de ALOKABIDE. � Gestor de Proyecto de la empresa adjudicataria. � Responsable Técnico / Funcional de la empresa adjudicataria. � Invitados cuya asistencia puntual se considere necesaria.

Reuniones � Lugar: ALOKABIDE � Periodicidad: quincenal o en función de las necesidades puntuales del

proyecto (inicialmente serán más frecuentes), en base a convocatorias formales por parte de la dirección de proyecto del Adjudicatario o de ALOKABIDE.

Temas � Entorno del proyecto: protección de las condiciones del mismo. � Evolución y seguimiento del proyecto. � Variaciones en el alcance. � Certificaciones parciales. � Cualquier tema relativo al proyecto que se considere necesario.

Adicionalmente, ALOKABIDE podrá de forma justificada convocar reuniones con carácter extraordinario, con un plazo de al menos 24 horas de antelación.

Notas importantes a tener en cuenta:

• La empresa adjudicataria levantará acta de cuantas reuniones formales se realicen.

• El adjudicatario deberá poner a disposición de los responsables de ALOKABIDE toda la

documentación del proyecto mientras se está elaborando en un servidor de trabajo colaborativo (Google Docs, Microsoft SharePoint o similar). En otras palabras: los

responsables de ALOKABIDE deben poder acceder a cualquier documento relacionado

con el proyecto en cualquier fase de su elaboración (aunque no esté terminado ni entregado).

• Los responsables técnicos de ALOKABIDE deben poder acceder al código fuente. Si alguna de estas normas no es respetada, puede dar lugar a la no aceptación de los entregables involucrados.


29

P

lieg

o B

ase

s T

écn

ica

s

7.5. Puntos de Riesgo

Se han identificado los siguientes puntos de riesgo ante los cuales se deberán exponer acciones mitigadoras en la oferta. Así mismo, si el ofertante identifica algún punto de riesgo no recogido en esta lista, puede exponerlo en su oferta junto con la acción mitigadora correspondiente, puesto que los riesgos formarán parte del contrato inicial y serán tenidos en cuenta y evaluados a lo largo de la vida del proyecto.

Riesgo Descripción

R1 Los usuarios temen que el proyecto no alcance las funcionalidades actuales que soportan las aplicaciones.

R2 Dificultades para integrarse con los sistemas existentes en ALOKABIDE.

R3 A pesar de haber cerrado un diseño de los módulos, una vez construido el sistema, se presentan gran cantidad de petición de cambios.

R4 El volumen de datos a migrar es muy amplio y la estructura de origen de la base de datos no coincide con la estructura final. Además, deben incorporarse los datos de los sistemas de legado (ERP Navision y Logic Class).

R5 La puesta en marcha es simultánea a la realización de la actividad de la empresa.

Pliego Bases Técnicas · Importación de la base de datos de solicitantes de Etxebide....

Documents

Transcript of Pliego Bases Técnicas · Importación de la base de datos de solicitantes de Etxebide....