De MorfeoWiki

Tabla de contenidos 1 Definición del escenario 1.1 Planteamiento 1.2 Introducción 1.3 Definición del escenario 1.3.1 Identificación de aplicaciones relevantes 1.3.2 Análisis de la interconectividad modular 1.3.3 Selección de prototipos operacionales para la evalucación de la plataforma 2 Diseño de la Arquitectura del Sistema Operacional y de Negocio en grandes empresas 3 Evaluación del Sistema de soporte Operacional y de Negocio en grandes empresas 3.1 Conclusiones 3.1.1 Comparación de plataformas 3.1.2 Implementación de gadgets utilizando la plataforma mashups de Netvibes 3.1.3 Inconvenientes encontrados en el uso de la plataforma Netvibes: 3.2 Líneas futuras

Definición del escenario

Planteamiento

• Se trata de estudiar el Marketplace de soluciones que soporta la operativa de negocio de las grandes cuentas.
• Este estudio se centra principalmente en los elementos operacionales, característicos y diferenciadores de este tipo de sociedades, a los cuales les infieren unas necesidades computacionales distintas de las de las PYMEs y microempresas.
• Se reutilizarán y ampliarán los Gadgets desarrolladores en el WP5.1, añadiendo nuevos módulos específicos y habituales en grandes empresas, pero que cada vez son más demandados por las PYMES a medida que aumentan sus necesidades y su negocio va creciendo.
• Este planteamiento proporciona la suficiente moduladidad para que cada empresa construya y utilice la plataforma según la complejidad de su sector de mercado.

Introducción

Actualmente los ERP pueden ser vistos como soluciones de tecnologías de la información que permiten integrar los procesos de la empresa.

Estos productos son modulares y ofrecen capacidades para logísticas integradas, ventas, procesos de órdenes, producción y control de los recursos materiales.

Las organizaciones pueden escoger implementar uno o varios módulos dejando otros para implementaciones futuras en función de sus necesidades y su crecimiento.

Un sistema para la gestión de los recursos de la empresa comprende la integración de todos los paquetes de software que gestionan la información que fluye a través de la compañía: financiera, contable, recursos humanos, la cadena de proveedores y la información del cliente.

El éxito del ERP está determinado por los beneficios operacionales y estratégicos que aportan ciertas consideraciones en la implementacion:

• Entrada de la información al sistema solo una vez.
• Customización.
• Proporcionar funcionalidad para interactuar con otros módulos.
• Proporcionar herramientas para consultas complejas.

Definición del escenario

Identificación de aplicaciones relevantes

El operativo de una gran empresa necesita integrar la información que se encuentra almacenada en los diferentes sistemas disponibles, pasando a formar parte de un único Sistema integrado de Gestión (ERP).

Los requisitos generales que debería soportar este operativo son:

Desde el punto de vista funcional

Requerimientos del área Económico Financiera

• Registros de facturas (o IVA, de compra, de venta).
• Contabilidad según Plan General Contable (Diario, Sumas y Saldos periódicos, Balances de Situación y Explotación).
• Gestión de cobros y pagos.
• Resúmenes sobre impuestos: IVA, retenciones, etc.
• Permitir obtener cuentas de resultado analíticas por unidad de negocio, línea de negocio, línea de producto y por proyecto y/o producto.
• Creación de un Cuadro de Mando para la Dirección.
• Informes de actividad, facturación, ingresos, costes y evolución comparando con distintos períodos, desglosando en Unidades de Negocio, Línea de Negocio, Línea de Producto y Proyecto.
• Posibilidad de crear balance y cuenta de pérdidas y ganancias a nivel global de toda la compañía, por unidades de negocio y por líneas de negocio.
• Gestionar , de manera eficiente, las necesidades ámbito legal, presupuestario y fiscal.
• Ofrecer información sobre datos de actividad.

Requerimientos del proceso de facturación

• Emitir facturas por proyecto y/o producto y/o cliente (configuradas y formato libre).
• Emitir abonos por proyecto y/o producto y/o cliente (configuradas y formato libre).
• Mantenimiento de facturas, posibilitando modificar o borrar.
• Posibilidad de realizar diferentes series de facturación.
• Emitir facturas y abonos con diferentes tipos de IVA (tipo de IVA abierto).
• Posibilidad de asignar los proyectos y/o productos y/o clientes a Líneas de Producto.
• Posibilidad de asignar los proyectos y/o productos a Líneas de Negocio.
• Posibilidad de asignar los proyectos y/o producto y/o clientes a Unidades de Negocio.
• El sistema debe permitir emitir facturas de un proyecto y/o producto y/o cliente con cargo a diversas Líneas de Negocio o Unidades de Negocio.
• Emitir facturas parciales o totales del proyecto y/o Producto y/o cliente.
• Posibilitar facturar por hitos del proyecto y/o servicio o en función de niveles de avance del mismo.
• Posibilidad de facturar de forma global o por partidas.
• Permitir el registro y aplicación de datos de actividad para aplicarlos a facturaciones de proyectos y/o productos (a precio de coste o aplicando el margen).
• Permitir el registro y aplicación de gastos derivados y/o adquisiciones asociadas a un proyecto susceptibles de facturación a ese proyecto y/o un cliente. El gasto debe facturarse a coste o con margen (profesionales independientes, comisiones de servicio…).
• Posibilidad de guardar los datos maestros de los clientes, así como de los pedidos que se les ha hecho anteriormente.
• Permitir dar de alta proyectos por parte de la unidad de negocio interesada como paso previo a la facturación de un proyecto y/o producto. El proyecto contendrá información sobre cliente, proponente, descripción de las tareas a realizar, finalidad del proyecto, recursos técnicos y humanos necesarios (presupuesto de gastos), estimación de los ingresos que generará etc....
• Asignar una codificación de proyecto
• Crear distintos status por los que debe pasar una oportunidad o proyecto.
• Workflow para que el Responsable de Negocio correspondiente o el Director General en su caso, si es un proyecto deficitario o requiere nuevo personal, aprueben la ficha de proyecto mediante firma electrónica o proceso similar.
• Workflow para que el Responsable del Área Económica firme la propuesta de facturación y la factura emitida (firma electrónica o proceso similar).
• Informe de relación de proyectos (Unidad de Negocio, Línea de producto, ingresos, costes , actividad, codificación..etc..)
• Relacionar el proyecto con un contrato, acuerdo, convenio, pliego, encomienda,…Ambos documentos deberán poder relacionarse en el sistema entre sí y con la facturación posterior que se realice.
• El sistema debe posibilitar que para llevar a cabo una facturación, se deba cumplimentar un formato de propuesta de facturación (codificado en el sistema) que indicará los datos necesarios para llevar a cabo la facturación. Este formato deberá permitir una ruta de aprobación (firma electrónica o similar).
• Permitir que la contabilización de las facturas se realice de forma automática, paso previo de chequeo de la información por parte del responsable del área económica.
• Posibilidad de que cada uno de los proyectos y/o productos y/o clientes lleve asociada sus cuentas de ingresos y de gasto y/o coste con el fin de generar automáticamente la contabilidad.
• Permitir que los proyectos que se facturen íntegramente al final del contrato puedan periodificarse en función del nivel de alcance del mismo, o según el criterio que se establezca.
• Informe de facturas emitidas por proyecto
• Informe de facturas emitidas por cliente
• Informe de proyectos facturados por cliente
• Informe de facturas de proyectos por línea de producto
• Informe de facturas de proyectos por líneas de negocio
• Informe de facturas de proyectos por Unidad de negocio
• Informe de actividad facturada y planificada por proyecto y/o producto, por cliente, por línea de producto, por línea de negocio, por Unidad de Negocio.
• Permitir obtener un catálogo de los proyectos y/o productos existentes, con todas sus características.
• Permitir obtener la planificación económica de la ficha del proyecto y su comparación con reales.
• Posibilidad de exportar a las herramientas de alta implantación en el mercado cualquier información para elaborar diferentes informes.
• Posibilidad de que existan otros centros de coste, donde se imputará costes indirectos que se repartirán aplicando diferentes criterios de reparto (nº de empleados, consumos, actividad, ingresos…).
• Posibilidad que los centros de apoyo puedan repercutir un precio a las Unidades de Negocio. Este precio podrá determinarse a partir de un coste o algoritmo, pudiendo tener la posibilidad de añadir un margen.
• Permitir que se puedan introducir datos de actividad de los trabajadores (horas, meses….), de instalaciones, consumos, número de personas, etc.…, lo que permitirá que a partir de estos datos, se puedan crear relaciones con criterios de imputación de costes.
• El sistema debe posibilitar realizar simulaciones de diferentes escenarios de distribución de ingresos y gastos.

Requerimientos generales de Contabilidad

• Consolidar estados financieros.
• Periodificaciones y desperiodificaciones automáticas de un gasto, previo chequeo del apunte contable si la mercancía o el servicio ha sido recepcionado.
• Posibilidad de amortizar determinados elementos del inmovilizado por horas de actividad del elemento.
• Realizar previsiones de tesorería.
• Realizar conciliaciones bancarias de forma automática.
• Registrar diferentes tipos de operaciones con los activos: adquisición, amortización, apreciación, depreciación, provisión, venta y baja contable.
• Definir un número ilimitado de libros de amortización para cada activo, que permitirá satisfacer las necesidades contables internas, los criterios fiscales y las normas contables internacionales.
• Ubicar los activos en las localizaciones que se establezcan (unidades, áreas, etc.) y asignar a éstas el coste de amortización.
• Bajas, cesiones o ventas parciales de activos.
• Realizar diversos escenarios de presupuestos, ofreciendo la posibilidad de comparar los presupuestos reales con los diferentes modelos de presupuestos que se establezcan y obtener las correspondientes desviaciones.
• Posibilidad de realizar presupuestos por unidades de negocio, por líneas, por proyecto y en conjunto de la Sociedad.
• Trabajar con múltiples presupuestos.
• Debe considerar las Normas Internacionales de Contabilidad (NIC).
• Informes de IVA e IGIC detallado por compras y por inversiones.
• Informe de IVA Intracomunitario, con documento equivalente.
• Declaración de IVA e IGIC.
• Declaración del Impuesto de Sociedades.

Gestión de Cobros

• Generar alertas en el caso de vencimiento de avales.
• Extraer listados de las facturas de profesionales independientes introducidas en el sistema, con datos fiscales del profesional, base sobre la que se aplica la retención, tipo de retención y cuota.
• El sistema no podrá permitir la introducción de ninguna factura de profesionales independientes, una vez que el Departamento de Recursos Humanos haya realizado el cierre de IRPF.
• Enviar alertas de que existen facturas de clientes ya vencidas, carta automática de reclamación del cobro.
• Generar una carta automática de reclamación de un cobro vencido.
• Informe de morosos.
• Informe para realizar verificación de facturas con el fin de relacionar éstas con los cobros recibidos.

Gestión de Pagos

• El sistema deberá proporcionar la funcionalidad básica necesaria para generar un Plan Contable y registrar en diarios contables requeridos legalmente: plan de cuentas, diarios generales, IVA, diarios periódicos y códigos de origen, retenciones y declaración del volumen de operaciones anuales con terceros.
• Informes contables base para la empresa.
• El sistema debe ser capaz de realizar apuntes contables predeterminados (plantillas).
• Posibilidad que el sistema automatice los apuntes contables que se realizan mensualmente, previo chequeo de los mismos por parte del departamento económico-financiero.
• Se debe considerar cualquier forma de pago.
• Realizar pagos por los bancos con soportes magnéticos normalizados.
• Posibilidad de casar los anticipos (clientes o proveedores/acreedores) con la factura cuando llegue.
• Pago automático de facturas cuando estén domiciliadas.
• Workflow de aprobaciones de órdenes de pago con varios niveles.
• Contabilizar las facturas en base a los datos aportados, imputando a gasto o inversión.
• Posibilidad de que el sistema envíe alertas de fecha de vencimiento de las facturas.

Gestión de Compras

• Registros de presupuestos y relación con el proceso de contratación administrativo.
• Creación de Registro de proveedores.
• Control de licitadores en relación a los correspondientes Pliegos.
• Relacionar el presupuesto con el pliego correspondiente. Ambos documentos deberán poder relacionarse con en el sistema entre sí , con la facturación posterior que se realice, y con el proceso jurídico de contratación.
• Recepción y registro de ofertas.
• Sistema de recepción y respuesta ágil de dudas sobre pliegos.
• Procesos de respuesta a adjudicatarios y no adjudicatarios, relación con área jurídica.
• Integración total con la Contabilidad General, a través de las cuentas de mayor asociadas. Será necesario especificar para cada proveedor la cuenta de mayor en la que se reflejará su saldo, a nivel de Contabilidad General.
• Registro de contratos. Seguimiento y control en relación al área técnica correspondiente.
• Realización y seguimiento de los pedidos.
• Demoras en las entregas
• Reclamaciones de entregas.
• Al registrarse cada entrada se actualizará el stock del almacén.
• Al producirse la contabilización de una factura, el sistema debe actualizar automáticamente el saldo de la cuenta del proveedor o acreedor manteniendo el vínculo con las partidas del documento que se ha contabilizado. Esto permite ver el estado de la cuenta del proveedor o acreedor visualizando su saldo contable y desglosándolo en las partidas que lo componen, hasta llegar al documento contable.
• La verificación y conformación de las facturas se realizará a partir de la información del circuito de compras a partir del albarán de recepción de material. Caso de no existir el circuito logístico será de introducción directa de la factura para su registro, creación de asiento automático así como del efecto de pendiente de pago.
• Introducir en los documentos tanto artículos con stock físico como artículos ficticios o servicios.
• Realización de consultas relacionadas con los distintos documentos (pedido, albarán,…).
• Trazabilidad documental.
• Control de la subcontratación de servicios y fabricación de artículos.

Gestión de Almacén

• Relación de albarán con factura.
• Gestión de stock (precio medio, ponderado y precio real).
• El sistema debe permitir la impresión de albaranes de entrada y salida de materiales/productos.
• Identificar los materiales/productos a través de su "part number".
• Asignar a ciertos materiales/productos un stock de seguridad.
• Utilizar números de serie para identificar unívocamente productos concretos.
• Posibilidad de conocer el historial de los productos.
• Posibilidad de realizar solicitudes de compra.
• Informes para poder comparar (en función del precio, plazo de entrega, etc.) la respuesta de los distintos proveedores/acreedores a las solicitudes de compra y de intercambio.
• Workflow de aprobaciones con unos o varios niveles, según el coste, para aprobar un gasto asociado a una orden de pedido.
• El sistema debe facilitar la creación de solicitudes de oferta a proveedores/acreedores.
• Guardar los datos maestros de los proveedores/acreedores, así como de los pedidos que se les ha hecho anteriormente.
• Posibilidad de consultar el ciclo de vida del producto (compra/venta).

Desde el punto de vista de la Seguridad

El sistema de Gestión (ERP) deberá contar con sistemas de auditoria, protección de información, log de registros de todos los movimientos, acceso seguro etc...

Debe disponer de una metodología, política y demás detalles referidas a las prácticas de backup y recuperación de la información.

Análisis de la interconectividad modular

La globalización actual hace que las organizaciones sean operadas en una escala global, con múltiples sitios de fabricación, distribución y socios situados alrededor del mundo.

• Las aplicaciones ERP deben gestionar y optimizar el concepto de cadena de suministros.

• Deben posibilitar la integración de diferentes topologías de tecnologías de información (TI) y protocolos de transmisión electrónica de datos (EDI), a través de las empresas.

• El potencial de este tipo de sistemas reside en la capacidad de organizar las diferentes unidades de negocio que utilizan diferentes procesos operacionales y de producción, usando además diferentes lenguajes y monedas.

• El sistema ERP debe ser fácilmente configurable y adaptable a la estructura particular de cada organización, soportando operaciones multi-sitio, centralizadas o descentralizadas, ayudando a la organización a integrar toda la información a través de sus módulos, interrelacionandolos entre sí.

El ERP es una forma de modelar el flujo de información en los negocios, ya que este beneficia el intercambio de información entre sus divisiones. Constituye una red de todos los sistemas de la organización, incluyendo las herramientas administrativas, producción, etc.

Los principales motivos para instalar un software ERP son dos: la necesidad de contar con datos más precisos y actualizados, e información íntegra y fiable, además de la necesidad de simplificar y unificar los procedimientos de los diferentes departamentos.

Estos sistemas de administración corporativa de recursos cuentan con funciones que integran la información del negocio y los procesos de gestión:

• Mejorando la comunicación con los inversores.
• Colaborando con clientes y proveedores en las actividades de pago y liquidación.
• Reducciendo los costos de transacción y aumento de la eficiencia operativa.
• Integrando la información entre diferentes áreas.
• Disponibilidad de información de forma inmediata para la toma de decisiones.
• Incremento en la productividad.
• Mejora de los tiempos de respuesta.
• Rápida adaptación a los cambios.
• Escalabilidad del sistema.
• Integridad de los datos.
• Seguridad definida por el usuario para el manejo de información.

La herramienta ERP es una reorganización de la empresa en sus procesos y en la forma de manejar la información dentro de la organización.

Selección de prototipos operacionales para la evalucación de la plataforma

Se trata de desarrollar aplicaciones totalmente accesibles para el usuario final, siendo además adaptables y fácilmente manejables.

Se tendrá en cuenta su uso por parte de personas sin experiencia en tecnologías de la información.

Resulta indispensable considerar la elevada velocidad requerida en las aplicaciones y en el acceso a los datos.

En cuanto a su usabilidad, destacará la ausencia del uso de periféricos ajenos al teclado para ejecutar todas las funcionalidades.

Serán, además, aplicaciones síncronas y perfectamente comunicadas entre ellas.

Asimismo, se tienen en cuenta, de forma exhaustiva, todos los requisitos establecidos en el documento D 1.1.1.

• Reutilización de los gadgets especificados en el “WP 5.1: PYMES”

• Alta de usuarios

Aplicación que permite dar de alta nuevos usuarios, otorgando privilegios de acceso a recursos y funcionalidades. Se complementará el registro con parámetros adicionales propios del usuario (tipo de usuario, fecha de alta en la aplicación, ...).

• Identificación y gestión de empleados

Identificación del empleado mediante la introducción de usuario y clave. A partir del registro realizado quedan registradas las características del usuario (hora de registro, localización, hora de desconexión...). Una vez registrado un usuario, se permite el acceso o restricción a una serie de recursos (en función de sus características y privilegios registrados con anterioridad). Por ejemplo, mientras que una cajera puede acceder solamente a sus estadísticas personales, un gerente de la empresa podría acceder a las estadíticas de todas las cajeras.

• Fidelización de clientes

El empleado introduce un código de identificación del cliente (DNI, PIN,...). Una vez que el cliente está identificado, el gadget pemite modificar automáticamente la información perteneciente al mismo (puntos obtenidos,...) en función de la acción realizada (compra, solicitud de entrega a domicilio,...). Este gadget alimenta al de ticketing, identificando los usos y costumbres del cliente, permitiendo explotar estos datos para un gadget de estadísticas de cliente y para un gagdet de propuesta de “Carro de compra”.

• Estadísticas de clientes

Visualiza los totales de venta por cliente. Estadísticas realizadas a partir de una característica propia del cliente frente al tiempo (Ejemplo: número de elementos comprados el último mes, puntos de cliente en la última quincena...). Las características se pueden obtener a partir de los elementos que forman los tickets asociados al cliente (elementos que se han comprado en cada ticket, fecha de la compra, gasto total por ticket...) y las características propias del usuario creadas por otros gadgets. Permite explotar distintos niveles de detalle y agrupación. Permite generar una selección de tickets para ser utilizados por otros gadgets (Gestión de Tickets, Impresion de Tickets).

• Propuesta de “Carro de compra”

Recibe un código de cliente, por teclado o salida de otro gadget, y nos facilita la lista de los últimos tickets del cliente. La selección de uno o varios de estos tickets generará una propuesta de artículos a adquirir. Este gadget puede ser utilizado en un terminal independiente del TPV, donde el cliente pueda acceder a esta información. El TPV también puede utilizarlo, para indicar al cliente los artículos que habitualmente adquiere y no están en el ticket actual.

• Inventario

Después de la introducción del código interno de uno o varios artículos (mediante teclado o salida del gadget de búsqueda de artículos) se nos solicita la cantidad actual del producto en el establecimiento.

• Stock

Nos muestra el stock actual (teórico) de los artículos seleccionados, calculado a partir del dato del último inventario y teniendo en cuenta las entradas y salidas de mercancías (venta). Indica los días que cubre este stock, en función del promedio de ventas del artículo, así como del periodo de aprovisionamiento del producto y la cantidad del producto óptima de pedido.

• Pedido

Permite introducir la cantidad solicitada del producto, apoyándonos en los gadgets de búsqueda de artículos y stock.

Diseño de la Arquitectura del Sistema Operacional y de Negocio en grandes empresas

• Alta de usuarios

• Identificación y gestión de empleados

• Fidelización de clientes

• Estadísticas de clientes

• Propuesta de “Carro de compra”

• Inventario

• Stock

• Pedido

Evaluación del Sistema de soporte Operacional y de Negocio en grandes empresas

Conclusiones

Comparación de plataformas

Se han comparado las diferentes plataformas que se encuentran en uso actualmente: Netvibes, PageFlakes, MyYahoo y POSH.

La plataforma MyYahoo no es de utilidad en el ámbito de crear pequeñas aplicaciones configurables, ya que no se pueden crear gadgets propios. Por otro lado, la plataforma PageFlakes fue descartada ya que los gadgets implementados en ella se deben mandar por e-mail, siendo los administradores de la plataforma quienes deciden si han de ser publicados o rechazados.

La plataforma POSH de Portaneo, a pesar de ser código libre y por tanto dar la ventaja de poder acceder a su implementación, ha sido rechazada por su estado muy poco avanzado y por la cantidad de fallos encontrados en la misma.

Por último, destacar que se ha elegido la plataforma Netvibes para comenzar a implementar gadgets por ser la única que tiene un sistema sencillo de crear y subir nuestras propias aplicaciones junto con una buena calidad del portal.

Implementación de gadgets utilizando la plataforma mashups de Netvibes

Para la implementación de los gadgets en la plataforma Netvibes se ha dispuesto de las siguientes tecnologías:

1. XHTML, Javascript y AJAX.
2. El XHTML se usa rtr para definir propiedaddes del gadget y en el formateo de los datos devueltos por los métodos AJAX.
3. Definición de la lógica del gadget mediante javascript incustado en el html.
4. Definición del aspecto mediante hojas de estilo.

En cuanto a las comunicaciones, se han utilizado distintas posibilidades. Por una parte, los gadgets pueden recibir datos usando los métodos AJAX y Javascript adecuados, pudiendo ser en XHTML normal, XHTML en formato JSON, o texto plano. Se ha llegado a la conclusión que no existen métodos específicos para el envío de datos, pudiéndose conseguir de forma rudimentaria mediante formulario en HTML.

La recolección y envío de datos se tiene que llevar a cabo a través de los métodos ofrecidos por la plataforma. El tener que utilizar estos métodos propios de la plataforma plantea problemas, principalmente cuando es necesario enviar información hacia el servidor, ya que los gadgets no están pensados en principio para este uso.

Como se ha comentado anteriormente, actualmente ni se dispone de un sistema de comunicaciones específico entre gadgets, ni tampoco es posible usar variables globales javascript (método permitido en la plataforma iGoogle para la comunicación). El punto de partida para ralizar una comunicación eficiente entre gadgets será el uso de un sistema por ficheros compartidos en el servidor web.

Inconvenientes encontrados en el uso de la plataforma Netvibes:

• No disponibilidad de un método de autenticación seguro.

La plataforma Netvibes ofrece un sistema de envío de claves. Sin embargo, el sistema está pensado para un único usuario por cuenta, por lo que las claves sólo se envían la primera vez y éstas quedan almacenadas en el servidor. Esto no sería problema si cada usuario dispusiese de su propia cuenta, pero, del mismo modo, no es útil si una misma cuenta va a ser usada por diferentes usuarios. Este problema, en conjunción con la imposibilidad de usar sesiones debido al proxy AJAX utilizado por Netvibes, hace que, en el caso de necesitar autenticación, se deba enviar las claves en cada consulta, por lo que se hace necesario establecer algún método de seguridad para evitar el envío de claves en texto plano, lo cual, debido a las limitaciones del lenguaje Javascript, puede ser bastante problemático.

• Recogida de datos asíncrona.

La petición de datos al servidor web se realiza de manera asíncrona, es decir, el código javascript del gadget no se detiene a esperar la respuesta del servidor.Todas las funciones AJAX han de ser llamadas a través de la API de Netvibes, negando todas posibilidades de usar funciones AJAX normales, por lo que no es posible forzar la comunicación síncrona. Esto hace que la implementación de ciertas funcionalidades sea especialmente complicada, y puede incluso llegar a imposibilitar ciertas funciones. Esto que en el funcionamiento usual de un gadget no supone ningún problema para ciertos usos, como por ejemplo esperar una confirmación de un envío de datos, o realizar una validación de un dato, puede provocar conflictos. Este problema, añadido al hecho de que Javascript hace imposible crear una espera inactiva en el lado del cliente, provoca que en muchos casos sea necesario crear un código más complicado y difícil de mantener, siendo posible que en algunos casos no se pueda solucionar de una manera correcta.

• Valoración de las comunicaciones.

Las comunicaciones de los gadgets con el servidor de datos son bastante problemáticas, debido a que éstas, al tener que pasar por los servidores de Netvibes y concretamente a través de su proxy AJAX, sufren unas restricciones bastante fuertes, como es por ejemplo la imposibilidad de hacer uso de sesiones, o de un envío seguro de claves. Estos problemas serían bastante graves si se quisiese hacer un uso empresarial de la plataforma, ya que provocan que la protección de datos se convierta en una tarea muy complicada, pudiendo llegar a ser imposible en algunos casos. Otro problema que implica usar la plataforma Netvibes, el cual es inherente a cualquier plataforma de este tipo alojada en servidores ajenos, es que no se puede controlar a través de donde se va a transmitir nuestra información, convirtiendose en un problema mucho más serio de seguridad. Se puede concluir afirmando que en la plataforma NetVibes no es posible comunicar un widget con otro, por lo que requisitos como por ejemplo la comunicación de un widget de búsqueda con el resto de widgets, para poder exportar los datos de un búsqueda y poder utilizar los mismos para otras funcionalidades, resulta imposible.

• Importar ficheros externos

Netvibes no permite importar ficheros externos como hojas de estilo o archivos javascript (.js), por lo que toda la lógica de presentación y de funcionamiento han de estar en el fichero del widget. Esto hace que si se quiere llevar a cabo un cambio de aspecto, o de una funcionalidad de la que hacen uso todos lo widgets, todos los archivos han de ser modificados.

• Tamaño del widget

No se permite definir ni ancho ni alto de los widgets. El ancho viene definido por el número de columnas que el usuario defina en las preferencias de su cuenta, y el alto viene fijado por el contenido del widget. Mientras que el ancho no es muy problemático, ya que se puede adaptar el contenido de todos los widgets para un número de columnas concreto, el no poder fijar el alto del widget es bastante molesto, porque en los widgets con contenido dinámico, como el de búsqueda, cambian de tamaño continuamente.

Como conclusiones finales del trabajo realizado en las plataformas existentes, es necesario destacar las limitaciones de todas ellas, incurriendo por tanto en un esfuerzo adicional a la hora de crear una lógica de negocio incluida en un servidor web junto con una base de datos

Líneas futuras

A partir del estudio realizado en las plataformas mash-up actuales se deben centrar esfuerzos en las siguientes líneas de investigación:

• Comunicaciones entre widgets: es necesario disponer de un sistema sencillo de comunicación entre widgets. También se ha de disponer de un sistema de gestión de las comunicaciones para así poder crear grupos y lleva a cabo comunicaciones broadcast, multicast e individuales.
• Comunicaciones locales: investigar a cerca de las posibilidades de comunicación local entre gadgets sin comunicación intermedia con un servidor web. Para ello hay que definir el tipo de comunicación a implementar, qué tipos de datos se comparten, datos de salida, datos de entrada, interfaz de comunicación entre dos gadgets, tratamiento de eventos que puedan surgir, etc.
• Autenticación: mediante un envío de claves, inicio de sesiones, etc. El objetivo final de esta línea de investigación comprende tanto todo el proceso de intentar verificar la identidad del remitente de una comunicación, como una petición para conectarse
• Sincronismo: evaluar las posibilidades de mantener una comunicación síncrona entre la petición de datos de un gadget en concreto al servidor web.
• Funcionalidades máximas: definir la carga máxima de funcionalidad de un gadget particular. Evaluar las ventajas e inconvenientes entre implementar gadgets autocontenidos con alta funcionalidad o gadgets básicos con alta capacidad de comunicación y variación de sus prestaciones finales fruto de su unión con otros gadgets del entorno.
• Diseño gráfico: comprende la etapa de diseño e implementación del intefaz gráfico con el usuario. Capacidades de configuración personalizable, habilitación/deshabilitación de características, etc. Para obtener un entorno fácil de usar, más agradable visualmente y mejor integrado, es necesario que los widgets tengan un mayor número de propiedades para definir.
• Sistema seguro de envío de información: habilitar un sistema de forma que el programador pueda fácilmente garantizar que los datos sensibles van a ser enviados de una forma segura.
• Sesiones: implementar algún tipo de sistema de sesiones de forma que las acciones de un usuario siempre estén identificadas desde que entra hasta que sale del sistema
• Interacción con el entorno del usuario: el uso de javascript en las plataformas limita totalmente la interacción con el entorno local del usuario, por lo que resulta imposible el uso de fichero de ámbito local, sería muy útil poder tener acceso a ficheros locales del usuario.
• Navegación específica: Los navegadores web normales disponen de multitud de opciones y de atajos de teclado, de los cuales muchos son contraproducente o totalmente indeseables para el manejo del sistema, por lo que sería interesante disponer de un navegador con las opciones justas y necesarias para interactuar con la aplicación.
• Definición de atajos específicos: Para mejorar la usabilidad del sistema es muy recomendable permitir al usuario definir sus propios atajos de teclado a las distintas funciones que le proporciones su interfaz.