Aplicación de ejemplo para el sector minorista

Octubre de 2006

Publicado: 4 de Diciembre de 2006

Moin Moinuddin
Microsoft Corporation

Este artículo hace referencia a:
   Microsoft BizTalk Server 2006
   Microsoft Business Scorecard Manager
   Windows Communication Foundation

Resumen: Las condiciones de un mercado en constante cambio requieren agilidad en las aplicaciones empresariales. La orientación al servicio responde a este reto y se centra en estándares de servicios XML y Web que revolucionan la forma en que los programadores diseñan sistemas y los integran a través de redes distribuidas. (32 páginas impresas)

En esta página

Introducción Introducción
Objetivos de la aplicación de ejemplo Objetivos de la aplicación de ejemplo
Escenarios y componentes Escenarios y componentes
Estándares para el sector minorista Estándares para el sector minorista
Interacción de los componentes Interacción de los componentes
Flujo de información Flujo de información
Decisiones técnicas Decisiones técnicas
Conclusión Conclusión

Introducción

Los establecimientos minoristas se enfrentan a numerosos desafíos: globalización, normativas, mayores costos y clientes exigentes. Además de las condiciones cambiantes del mercado, en la actualidad existen numerosos canales para llegar a los clientes. Esta situación incrementa la necesidad de contar con aplicaciones empresariales flexibles y ágiles. No obstante, en un momento en que la competencia está muy interesada en conceptos de moda como agilidad y adaptabilidad, las empresas se enfrentan a sistemas que parecen hechos de acero y cemento, desarrollados como si nada fuese a cambiar nunca. Estos sistemas se hacen cada vez caros y complejos a medida que las organizaciones los adaptan a las nuevas necesidades del negocio. Lamentablemente, esto conlleva que la automatización sea cada vez menor, ya que los sistemas requieren una intervención humana y un desarrollo de la TI constantes. Con demasiada frecuencia, la alineación de la tecnología con los objetivos empresariales se atasca por problemas de integración y no supera la fase inicial.

Una de las áreas donde los minoristas se enfrentan normalmente con grandes desafíos es la disponibilidad de la información correcta, en el momento y el lugar adecuados; por ejemplo, poner a disposición de los encargados de tienda, directores regionales y responsables de promoción comercial de la sede central de la empresa la información de ventas casi en tiempo real. Otro ejemplo es la disponibilidad de la información de producto para los representantes comerciales. La disponibilidad de la información prácticamente en tiempo real requiere que los sistemas puedan generar datos y enviarlos a los lugares adecuados así como consumir los datos y todo ello casi en tiempo real.

La orientación al servicio afronta estos desafíos al centrarse en los estándares de servicios XML y Web de rápida evolución que están revolucionando la forma en que los programadores diseñan sistemas y los integran a través de redes distribuidas. A los programadores ya no se les exige que trabajen con lenguajes y modelos de objetos rígidos y de titularidad privada como sucedía siempre antes de que entrase en escena la estrategia basada en el servicio. La aparición de esta nueva metodología ayuda a desarrollar nuevos enfoques, específicamente para la informática distribuida basada en Web. Esta revolución está transformando el sector gracias a la integración de sistemas dispares para crear una empresa que opere en tiempo real.

Lograr que la información esté disponible allá donde se necesita para simplificar los procesos de suministro de mercancías requiere una metodología basada en una integración de acoplamiento flexible entre las distintas aplicaciones de tienda y almacén Esta demanda convierte la integración entre aplicaciones dispares en un factor crucial una arquitectura que se base en la orientación al servicio.

Este artículo, junto con la aplicación de ejemplo, se han elaborado tras seleccionar una serie de escenarios comunes en el sector minorista (como la falta de disponibilidad de existencias, la prevención de pérdidas, los servicios de atención al cliente y la productividad en la tienda) para demostrar la integración mencionada mediante la orientación al servicio. En este artículo se describe la conectividad entre aplicaciones en tiempo real. Los datos se transmiten desde la tienda a la empresa como un evento empresarial y no como una secuencia de lotes. Los datos se transmiten entre las aplicaciones de la tienda y la línea de negocios (LOB) en el formato IXRetail estándar del sector.

En este artículo también se explica la mejor forma de lograr la agilidad y la integración mediante la orientación al servicio. Finalmente, se puede descargar una aplicación de ejemplo que explica este procedimiento a través de una serie de escenarios seleccionados.

Objetivos de la aplicación de ejemplo

Los objetivos principales de este artículo son explicar:

  • La integración de aplicaciones dispares mediante servicios Web.

  • El uso de estándares del sector para lograr la interoperabilidad.

  • La sencillez de crear servicios Web mediante la plataforma de Microsoft.

  • Las capacidades de transformación y orquestación de Microsoft BizTalk Server (BTS) 2006.

  • La facilidad de crear mesas de trabajo de administradores y escritorios mediante Microsoft Business Scorecard Manager (SCM).

Creación de la aplicación de ejemplo

Para demostrar el uso de la arquitectura orientada al servicio para automatizar este escenario, se creó una aplicación de ejemplo mediante el estándar del sector IXRetail para empresas minoristas, BizTalk, Windows Communication Foundation (WCF) y SCM. El método fue el siguiente:

  • Crear una aplicación de punto de venta (PDV) de ejemplo basada en Visual C#.

  • Usar el esquema IXRetail para diseñar las definiciones de interfaz de servicio Web.

  • Crear un adaptador IXRetail de servicios de fondo para BizTalk

  • Crear un servicio Web de ejemplo mediante WCF que active flujos de trabajo basados en alertas y eventos

  • Crear un servicio de proveedor de ejemplo que interactúe con el servicio Web de almacén

  • Empaquetar la aplicación en un conjunto de servicios Web, aplicaciones Windows, metadatos (configuración, definiciones de esquema) y un conjunto de aplicaciones

¿De qué manera se benefician los minoristas?

Esta aplicación de ejemplo describe muchas ventajas para los minoristas. Algunas de las características clave de la aplicación de ejemplo que suponen una ventaja al crear una solución para el sector minorista conectada en tiempo real son las siguientes:

  • Demuestra el uso de estándares para crear una solución ampliable.

  • Tiene un acoplamiento flexible para ofrecer agilidad, adaptabilidad y alineación.

  • Está creada mediante tecnologías preempaquetadas, a diferencia de su creación desde cero.

El uso de estándares, el acoplamiento flexible y el uso de tecnologías existentes, ayuda a los minoristas a cambiar incrementalmente a esta solución, a diferencias de las soluciones existentes de "cortar y reemplazar". Estas características también ayudan a seleccionar "lo mejor de lo mejor", a diferencia de estar anclado a soluciones de un determinado proveedor. Finalmente, también permiten ampliar la solución fácilmente a medida que cambien las condiciones del mercado.

Escenarios y componentes

En esta sección se describe la arquitectura de referencia para crear un minorista integrado. Tal como se ha descrito en las secciones anteriores, los minoristas afrontan el desafío de integrar sus sistemas anteriores en sus tiendas y en la sede de la empresa. Este desafío se hace más crítico con clientes exigentes que esperan una experiencia satisfactoria tanto en la tienda como en otros canales.

Para lograr la disponibilidad de los datos prácticamente en tiempo real y cosechar los frutos que esto supone, debemos comprender primero en qué consiste la cadena de valor del sector minorista.

Figura 1. Cadena de valor del sector minorista

En una cadena de valor del sector minorista, los datos de ventas y de clientes van de las tiendas a los sistemas de la empresa. Según la previsión, los niveles de inventario y los datos de ventas, los sistemas de la empresa solicitan nuevos productos y mercancías a los proveedores. Los proveedores llevan a cabo los pedidos desde sus almacenes y, a su vez, realizan pedidos a los fabricantes cuando el inventario del almacén está por debajo de un determinado umbral.

Para que todo esto funcione perfectamente y evitar que los clientes se encuentren en situaciones de falta de existencias, los minoristas necesitan un proceso que sea ágil, adaptable y alineado a sus necesidades. De este modo se reducen los costos y la ineficacia, a la vez que se garantiza una experiencia del cliente sin problemas. Si este proceso no está configurado para obtener las ventajas de agilidad, adaptabilidad y alineación, la empresa minorista está expuesta a los puntos negativos descritos anteriormente.

Escenarios del sector minorista que se abordan en esta aplicación de ejemplo

En el sector minorista existen numerosos escenarios y casos de uso. No obstante, para demostrar las capacidades de las tecnologías, hemos seleccionado unos cuantos escenarios habituales:

  • Artículo no encontrado: Se trata de un escenario habitual que se produce en el entorno minorista. En este escenario, un artículo llega a la tienda y se apila en las estanterías mucho antes de que se incorpore al sistema de comercialización y de que el precio se transmita a la tienda. Un cliente toma el artículo y se dirige a la caja. Cuando se escanea el producto, no se puede pasar por caja porque no se encuentra. Actualmente, esto conlleva numerosos pasos manuales, como tener que llamar por busca al supervisor para que se dirija a la línea de cajas, tomar el producto del cajero y dirigirse al almacén para intentar encontrar el precio buscando el de algún artículo parecido. Después de haber encontrado el precio de un artículo parecido, el responsable introduce el precio manualmente en el punto de venta para finalizar la transacción.

  • Retirada de artículo: En este escenario, un proveedor normalmente envía un mensaje a la sede de la empresa para retirar un artículo. El responsable de mercancías actualiza el sistema de administración comercial para que conste dicha retirada y envía un mensaje a las tiendas. La respuesta de las tiendas se basa en el tiempo que los responsables de las mismas tardan en procesar el mensaje y en quitar el artículo retirado de las estanterías. En la aplicación de ejemplo se explica cómo se puede automatizar este escenario por completo mediante el uso de las nuevas tecnologías, en concreto, los servicios Web.

  • Artículo agotado: Se trata de un escenario muy habitual en el sector minorista. En este escenario, un cliente busca un artículo, no lo encuentra en las estanterías y pregunta al empleado de la tienda, quien le informa de que está agotado, aunque en realidad se encuentra en el almacén. Este problema se produce debido a una falta de visibilidad en tiempo real del inventario de la tienda. En la aplicación de ejemplo se explica cómo las nuevas tecnologías pueden solucionar este problema y ofrecer una experiencia del cliente mucho más satisfactoria.

  • Transferencia de datos de ventas en tiempo real de artículos en promoción: Normalmente, los datos de ventas se transfieren a los sistemas de la empresa por la noche o dos veces al día. Esto no proporciona una visibilidad adecuada al personal de administración de comercialización sobre los niveles de inventario y, en concreto, sobre los artículos en promoción. En la aplicación de ejemplo se muestra la transferencia de la información de las transacciones en tiempo real desde la tienda a los sistemas de la empresa. También se muestra la aplicación de determinadas reglas empresariales en la transmisión de la información de las transacciones de ventas en tiempo real. Por ejemplo, la información de ventas relacionada con los artículos de gran valor y con los artículos en promoción se transmite en tiempo real con la máxima prioridad, mientras que para los datos de otras transacciones se asigna una prioridad secundaria para la transmisión en tiempo real. El servicio alojado en el host local recopila las actualizaciones simultáneas de los datos de ventas procedentes de varios dispositivos de punto de venta, las agrupa y las transforma para, posteriormente, transferir los datos según las reglas establecidas por la sede de la empresa.

  • Cadena de suministro: Normalmente, cuando se introduce una transacción en el sistema de puntos de venta, llega al sistema de la empresa más tarde durante la misma jornada o incluso el día siguiente. De este modo, se reduce la visibilidad para los ejecutivos y los empleados del sistema de la empresa acerca del rendimiento de las tiendas desde el punto de vista del inventario y de las ventas. En la aplicación de ejemplo de sistema conectado se muestra la integración completa del ciclo de la cadena de suministro, desde la tienda pasando por el sistema de comercialización, el sistema de almacenaje y, finalmente, de vuelta a la tienda. Cuando se introduce una transacción en el punto de venta, ésta se transfiere a una función de inventario en la tienda y actualiza los datos disponibles en la propia tienda. Cuando la cantidad disponible está por debajo de un umbral mínimo, se activa un pedido inmediato dirigido a la aplicación de administración de almacén. Es posible que el sistema de administración de almacén interactúe con un socio comercial para llevar a cabo el pedido. El pedido se envía y se recibe en la tienda, y las cifras de inventario de almacén correspondientes al artículo se incrementan de la forma adecuada.

En la aplicación de ejemplo se usan los escenarios anteriores para mostrar cómo se pueden automatizar por completo y cómo se puede proporcionar visibilidad en tiempo real, para que los empleados y los ejecutivos puedan tomar decisiones con los datos necesarios en el momento oportuno.

Componentes clave de la aplicación de ejemplo

En esta sección se ofrece una descripción que explica los componentes de la aplicación de ejemplo. En la figura 2 se proporciona la vista de la arquitectura completa de cómo se integran y funcionan estos componentes. En esta arquitectura se muestra la integración de acoplamiento flexible entre las distintas aplicaciones de tienda y de almacén. Esta arquitectura de alto nivel proporciona los fundamentos que se pueden ampliar o reemplazar según las necesidades de negocio o se pueden modelar de forma similar para otro sector.

Figura 2. Diagrama de la arquitectura

Punto de venta (PDV)

La aplicación de ejemplo dispone de una aplicación para puntos de venta. Se trata de una aplicación creada como .NET (POSSystem, para demostrar la integración con aplicaciones de LOB independientemente de la plataforma). La aplicación para puntos de venta puede funcionar de dos formas: en línea y sin conexión. En línea significa que existe una conexión con el servidor de la tienda y sin conexión significa que se trabaja desconectado del servidor de la tienda. En el modo sin conexión, estos terminales almacenan las transacciones de ventas localmente en un archivo sin formato. Después de establecer una conexión con el servidor de la tienda en el modo en línea, las transacciones sin conexión se envían a dicho servidor.

En una tienda real, los escenarios sin conexión se producen por la pérdida de la conectividad de red o por que el servidor de la tienda deja de funcionar. No obstante, en esta aplicación de ejemplo los modos sin conexión y en línea se controlan mediante el archivo de configuración. Un parámetro en el archivo de configuración de la solución para PDV controla el modo de funcionamiento, tal como se muestra aquí.

<!--This is the POS Id where one can give the name of the POS-->
   <add key="POSID" value="101"/>

<!--This indicates the online/offline status of the application-->
   <add key="Online" value="true"/>

El nombre de la aplicación para PDV se configura en la clave POSID, que se transfiere junto con cada mensaje de notificación que se envía a la tienda. Si el valor de la clave Online es "true", el PDV está conectado al servidor de la tienda. En un escenario de establecimiento minorista, puede haber varias bases de datos para las que cada PDV debe hacer referencia a su propia configuración de conexión de base de datos. También se puede configurar en el archivo Config.xml, tal como se muestra aquí.

<add key="ConString" value="Data Source=machinename;
Initial Catalog=Databasename;
User Id=test;Password=test123;/>

Todas las transacciones del escenario en línea se envían a la base de datos de la tienda y todas las transacciones se mantienen en las tablas maestras y de detalles de ventas de la base de datos. También se mantiene un archivo adicional en el sistema que contiene los detalles del maestro de artículos, cuya ruta de acceso se configura en el archivo Config.xml, tal como se muestra aquí. (Asegúrese de que la aplicación de PDV tiene acceso a este archivo de transacciones.)

<!--This is the path where the WCF Web service writes the details 
to a 
shared location that will then be accessed by the POS application-->
<add key="FileItemPath" value="//machinename//temp//price.xml"/>

Si el valor de la clave Online se cambia a "false", la aplicación de PDV se desconecta de la base de datos de la tienda y todas las transacciones se llevan a cabo con el archivo de detalles de maestro de artículos, Price.xml, que se ha creado en el paso anterior. También se crea un archivo de registro de transacciones adicional en la unidad local, cuya ruta de acceso también se puede configurar en el archivo Config.xml, tal como se muestra aquí El nombre de este archivo es el mismo que el del Id. de factura generado. A continuación, estas transacciones se combinan en la base de datos de la tienda cuando el PDV está en línea o si el PDV pasa de estar sin conexión a estar en línea.

<!--This is the path where the POS application writes the details of 
the transaction to an xml file in the offline mode-->
<add key="FileTransactionPath" value="C:\\"/>

Base de datos de la tienda o Store (figura 2, elemento 3)

La base de datos Store mantiene los datos de ventas y de inventario de la tienda. Los datos de transacciones de todas las aplicaciones de PDV se agregan a la base de datos Store para su almacenamiento local.

Todas las notificaciones generadas por la aplicación de PDV y la aplicación Store Manager (que se explica en la siguiente sección) también se almacenan en la base de datos. El diagrama E-R de la base de datos se muestra en la figura 3. Las tablas principales de la base de datos Store son las siguientes:

  • SalesDetails: en esta tabla se almacenan los detalles de cada artículo vendido desde la aplicación de PDV.

  • SalesMaster: en esta tabla se almacenan los pedidos con el subtotal, impuestos, etc.

  • PoSMaster: en la base de datos se almacenan los detalles de cada terminal PDV. La aplicación Store Manager hace referencia a esta tabla para encontrar las ubicaciones PDV de todas las aplicaciones, para difundir eventos.

  • Employees: en esta tabla se incluyen los detalles de los empleados de la tienda.

  • ProductDetails: se trata de la tabla maestra de productos, que enumera los detalles de todos los productos de la tienda.

  • ItemMaster: es la tabla maestra de la base de datos de la tienda que contiene los datos de transacciones y la notificación correspondiente a cada artículo. Esta tabla contiene la etiqueta RecallFlag, que indica el estado de retirada de todos los artículos.

  • Inventory: esta tabla contiene el inventario de los artículos disponibles en el almacén o en las estanterías de la tienda. Esta tabla se actualiza siempre que se vende un artículo.

  • LocationMaster: esta tabla almacena los detalles de ubicación del almacén y de las estanterías de la tienda.

  • OutOfStockItemHistory: si el inventario de un artículo está por debajo del umbral, los detalles de transacción de dicho artículo se envían a esta tabla.

  • RecalledItemHistory: si la aplicación Store Manager retira un artículo de las estanterías de la tienda por algún motivo, se asigna el valor "true" a RecallFlag de ItemMaster para dicho artículo y se introduce el historial del artículo retirado (RecalledItemHistory) en esta tabla.

  • UoMMaster: en esta tabla se almacenan los detalles de unidad de medida de cada uno de los artículos de ItemMaster.

  • Promotions: esta tabla contiene los detalles de los artículos de oferta u ofrecidos en promoción.

Figura 3. Diagrama E-R de la base de datos Store

La aplicación Store Manager hace referencia a esta base de datos para todas las operaciones necesarias. La conexión a la base de datos Store se efectúa mediante la clase DBManager que se encuentra en el componente DataAccess de la aplicación de ejemplo. En esta solución se administran todas las conexiones a la base de datos.

Aplicación Store Manager (figura 2, elemento 6)

Esta aplicación .NET actúa como la aplicación Store Manager que se podría ejecutar en Tablet PC. Todos los mensajes y notificaciones del PDV se enrutan a esta aplicación. La aplicación Store Manager actúa de interfaz para todos los mensajes que se envían al servicio Web de tienda y para los que se reciben desde éste.

La aplicación Store Manager recibe notificaciones de las aplicaciones de PDV y las devuelve mediante CSTStoreWinService, que es el servicio de comunicaciones de Windows que se ejecuta en la tienda. Esta comunicación se lleva a cabo mediante la escucha TCP/IP configurada en CSTStoreWinService, cuya IP de comunicación (y el puerto en el que realiza la escucha) está configurada en la aplicación Store Manager. Esta configuración se efectúa en el archivo App.config, tal como se muestra aquí.

<!-- IP address of the box that host the Communication Windows Service-->
   <add key="CommunicationIP" value="172.28.41.61"/>
<!-- Port number on the box on which the Communication Windows Service is 
listening-->
   <add key="CommunicationPort" value="8000"/>

La aplicación Store Manager se comunica mediante este socket. La aplicación Store Manager también genera archivos XML de notificación por cada notificación recibida en la tienda, tanto de la aplicación de PDV como de las aplicaciones de la empresa Los archivos de notificación se configuran en el archivo App.config, tal como se muestra aquí.

<!--XML file name where Item recalled notifications will be stored-->
   <add key="IRCXmlName" value="ircnotify.xml"/>
      
<!--XML file name where Item out of stock (shelf) notifications will be stored-->
   <add key="IOOSSXmlName" value="ioossnotify.xml"/>
      
<!--XML file name where Item out of stock (back room) notifications will be stored-->
   <add key="IOOSBXmlName" value="ioosbnotify.xml"/>
      
<!--XML file name where Item shipment received notifications will be stored-->
   <add key="ISHIPMENTXmlName" value="ishipmentnotify.xml"/>

Estos archivos de notificación se crean según los esquemas IXRetail para todos los escenarios. Estos archivos de notificación actúan de mensajes de notificación que enruta el servicio Store como correos de notificación al personal de almacén (en sus PDA o terminales) en los escenarios de retirada de artículos, y a las aplicaciones de la empresa en los escenarios de artículos no encontrados.

En el escenario de artículo no encontrado, se dirige un correo electrónico mediante el servicio Store a la aplicación Enterprise para que el empleado pueda establecer el precio del artículo que faltaba en la base de datos de la tienda. La configuración de correo electrónico que se enviará a la empresa también se define en el archivo de configuración, tal como muestra aquí.

<!-- headquarters Mail ID-->
<add key="headquartersMailID" value="testmail@microsoft.com"/>

El correo electrónico se envía mediante el servidor SMTP que está configurado en el servidor IIS. Los valores de configuración, como el nombre y el puerto del servidor SMTP, también forman parte del archivo de configuración.

<!-- IP Of a box that has SMTP (Generally this is Indigo box) -->
   <add key="SMTPIP" value="smtphost"/>

<!-- Port on which SMTP Service is running-->
   <add key="SMTPPort" value="25"/>

Además, la dirección de punto final del servicio Store se puede configurar en el archivo Config.xml.

<!-- Indigo Store Service path -->
<add key="EndPointAddress 
value="http://localhost:2769/StoreService/Service.svc"/>

Servicio de Windows Store (figura 2, elemento 4)

El servicio de Windows Store (CSTStoreWinService) se muestra como un servicio de Windows y se comunica con la aplicación Store Manager mediante el uso de notificaciones generadas por el PDV. El servicio CSTStoreWinService también administra la comunicación entre la aplicación Store Manager y el servicio Store, ya que el servicio Web Store se aloja en el servicio de Windows.

El servicio de Windows activa cuando es necesario una notificación dirigida a Store Manager siempre que los artículos de gran valor o en promoción se venden por encima de su valor de umbral de inventario. Este enrutamiento de notificaciones a la aplicación Store Manager se lleva a cabo mediante la configuración de la dirección de Store Manager en el archivo de configuración del servicio CSTStoreWinService.

<!-- IP address of device on which Manager application will run-->
    <add key="MGR" value="172.28.41.61"/>

Tan pronto como el servicio CSTStoreWinService se inicia, busca las reglas empresariales de transmisión de datos de ventas.

Servicio Web Store (figura 2, elemento 5)

El servicio Web Store se aloja como un servicio Web WCF que se muestra a la aplicación Enterprise. Todas las comunicaciones entre la aplicación Store Manager y la aplicación Enterprise se enruta mediante este servicio Web. Los puntos finales de este servicio Web se configuran en el archivo de configuración. La lógica empresarial necesaria en la tienda se incorpora en los métodos públicos de este servicio Web Store.

El servicio Web Store se comunica con la aplicación Enterprise mediante el servicio BizTalk que actúa de interfaz en la sede de la empresa. El servicio BizTalk expone las reglas empresariales y los métodos de información de ventas. El servicio Web Store se comunica con el servicio Web BizTalk con los esquemas IXRetail. Realiza la transformación de los datos de tienda al formato IXRetail. Esto se lleva a cabo mediante la asignación de los datos de la base de datos Store a los esquemas expuestos por el servicio Web BizTalk. Más adelante se ofrecerá información acerca de la transformación de datos.

Las funciones básicas del servicio Web Store se enumeran a continuación:

  • Agregación de datos: Los datos de ventas y las transacciones del dispositivo PDV se agregan y se envían a la base de datos con métodos de inserción de base de datos. La configuración de conexión a la base de datos se lleva a cabo en el archivo Web.config del servicio Web Store, tal como se muestra aquí.

    !-->Db connection string Data Source=<Database server> 
    Catalog=<Database name> -->
    <add key="ConString" value="Data Source=servername;Initial 
    Catalog=db name;Integrated Security=True"/>
    
  • Transformación de datos: El servicio Web Store realiza la transformación de los datos de tienda al formato IXRetail mediante la asignación de los datos de la base de datos Store a los esquemas expuestos por el servicio Web BizTalk. Esta operación se explica mediante el escenario Aplicación de reglas en actualizaciones de datos en tiempo real.

    • En esta aplicación de ejemplo, la información de transacciones se transfiere en tiempo real desde la tienda a los sistemas de la empresa; durante este proceso, se aplican determinadas reglas empresariales para seleccionar la información que se transferirá. Por ejemplo, la información de ventas relacionada con los artículos de gran valor o en promoción se transmite en tiempo real con la máxima prioridad. Los demás datos de transacciones obtendrán una prioridad secundaria en la transmisión en tiempo real. El servicio alojado en el host local recopila las actualizaciones simultáneas de los datos de ventas procedentes de varios dispositivos de punto de venta, las agrupa y las transforma para, posteriormente, transferir los datos según las reglas establecidas por el responsable de la tienda o los sistemas de la empresa.

    • El servicio BizTalk expone el esquema en función del formato IXRetail y lo enlaza a la orquestación. A continuación, estas orquestaciones se exponen como un servicio Web y los métodos empresariales se exponen a la tienda como métodos de servicio Web.

      [System.Web.Services.WebMethodAttribute()]
              [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://temp
      uri.org/BizTalkWS/PriceNotFound", 
      Use=System.Web.Services.Description.SoapBindingUse.Literal, 
      ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Default)]
      
      [return:System.Xml.Serialization.XmlElementAttribute(Namespace="http://
      BizTalkWS.PriceNotFound", ElementName="PriceNotFound")]
      
      public PriceNotFound 
      PriceNotFound([System.Xml.Serialization.XmlElementAttribute(
      Namespace="http://BizTalkWS.PriceNotFound", 
      ElementName="PriceNotFound")] PriceNotFound part)
      {
      }
      

En el método Web anterior, el parámetro de entrada se debe asignar al esquema PriceNotFound expuesto por BizTalk. En el escenario de artículo no encontrado, el servicio Store recupera los datos de la base de datos Store y los transforma en el objeto de esquema expuesto por BizTalk. Por lo tanto, la transformación se lleva a cabo mediante la asignación del conjunto de datos expuesto por la base de datos Store al esquema PriceNotFound.

Servicio Web Corporate o Enterprise (figura 2, elemento B)

El enrutamiento de ida y vuelta de los mensajes, las notificaciones y los datos de ventas desde la tienda a los sistemas de la empresa se lleva a cabo mediante el servicio Web Corporate o Enterprise. El servicio Web Corporate se expone como un servicio BizTalk. El flujo de datos entre las tiendas y los sistemas de la empresa se realiza con técnicas de transformación de datos. Todos los esquemas de escenario de establecimientos minoristas se exponen mediante el servicio Web BizTalk. A partir del escenario de comercio minorista, se crean esquemas para cada uno de los escenarios. A continuación, estos esquemas se transforman en mensajes y se exponen como orquestaciones. Después, el conjunto de orquestaciones y las ubicaciones de recepción que crea BizTalk se exponen como un servicio Web. Este servicio Web se publica con el asistente para publicación de servicios Web. El servicio Web Corporate se configura con el archivo Config.xml, que se encuentra en la clase auxiliar BizTalk. El servicio Web Corporate también guarda los eventos en la parte empresarial en un archivo de registro, cuya ruta de acceso se indica en la configuración.

<category name="Common">
   <setting name="LogFilePath" value="CSSample applicationLog.txt"></setting>
   <setting name="EventSourceName" value="CS Sample application"></setting>
   <setting name="EventSourceLogName" value="CSSample 
applicationLog"></setting>
</category>

Las notificaciones a los sistemas de la empresa, al responsable de comercialización, a los proveedores y al personal de almacén se envían por correo electrónico, cuya configuración se encuentra en el archivo de configuración.

<setting name="DBConString" value="Data Source=ibm-indigo;Initial 
Catalog=Test_headquartersDB;Integrated Security=True"></setting>
<setting name="MerchandisersEmail" value="testemail@test.com"></setting>
<setting name="headquartersEmail" value="testemail@test.com"></setting>
<setting name="BusinessRuleFilePath" value="\\ibm-
indigo\temp\BusinessRules.xml"></setting>

Aplicación Supplier

La aplicación Supplier se expone como una aplicación Web y se aloja en el lado de la empresa (o sede) para permitir que el responsable de la sede retire artículos de las aplicaciones de PDV. La aplicación Web Supplier permite que el responsable introduzca los detalles del artículo que se retirará y el mensaje de retirada se dirige a la tienda mediante el servicio Web BizTalk.

Figura 4. La aplicación Supplier usa esta pantalla para enviar el mensaje de retirada de artículo

Base de datos Corporate o Enterprise (figura 2, elemento D)

La base de datos Enterprise mantiene las ventas y el inventario en su propio sistema, al cual se conectan directamente las aplicaciones de la empresa. Todas las notificaciones generadas o enrutadas por el servicio Web BizTalk y las aplicaciones Web de la empresa también se almacenan en la base de datos. Las tablas principales de la base de datos de la empresa son las siguientes:

  • SalesDetails: aquí se almacenan los detalles de cada artículo vendido desde el PDV.

  • SalesMaster: se trata de la tabla maestra de facturas que almacena las facturas generadas después de cada transacción.

  • PoSMaster: en la base de datos se almacenan los detalles de cada terminal PDV. La aplicación Store Manager consulta esta tabla para encontrar las ubicaciones de PDV de todos los terminales cuando difunde algún evento.

  • Employees: aquí se mantienen los detalles de todos los empleados que trabajan en las tiendas.

  • ProductDetails: se trata de la tabla maestra de productos, que enumera los detalles de todos los productos de la tienda.

  • ItemMaster: es la tabla maestra de la base de datos de la tienda que contiene los datos de transacciones y la notificación correspondiente a cada artículo. Esta tabla contiene RecallFlag, que indica el estado de retirada de todos los artículos.

  • Inventory: esta tabla contiene el inventario de los artículos disponibles en el almacén o en las estanterías de las tiendas. Esta tabla se actualiza siempre que un artículo pasa por caja desde el PDV.

  • LocationMaster: esta tabla almacena los detalles de ubicación del almacén y las estanterías de la tienda.

  • OutOfStockItemHistory: si algún artículo pasado por caja en el PDV no está disponible en la tienda y la cantidad pasada por caja está por debajo del nivel de umbral del inventario, los detalles de transacción de dicho artículo se envían a esta tabla.

  • RecalledItemHistory: si la el responsable de tienda retira un artículo de las estanterías de la tienda por algún motivo, se asigna el valor "true" a RecallFlag de ItemMaster para dicho artículo y se introduce el historial del artículo retirado (RecalledItemHistory) en esta tabla.

  • UoMMaster: en esta tabla se almacenan los detalles de unidad de medida de cada uno de los artículos de ItemMaster.

  • Promotions: esta tabla contiene la entrada de los artículos de gran valor que están de oferta o en promoción.

Aplicación Web Corporate o Enterprise (figura 2, elemento E)

La aplicación Enterprise se expone como una aplicación Web. Se aloja en la sede, realiza todas las operaciones relacionadas con la misma. Esta aplicación Web admite varias operaciones, como el envío de notificaciones, la funcionalidad de comercialización para abastecer las existencias, transferirlas, enviar el solicitado por las tiendas y generar pedidos de compra. Sus funciones principales son:

  • Edición de precios de artículo.

  • Transferencia en tiempo real de cambios de precio a las tiendas mediante el servicio WCF en la tienda. Esto se lleva a cabo mediante UpdateItem, que se muestra cuando la aplicación se inicia. Tan pronto como el precio se actualiza y transmite, se envía un correo electrónico al responsable de la tienda y aparece una notificación en la aplicación Store Manager.

  • Capacidad para retirar artículos de la tienda mediante la funcionalidad RecallItem. Cuando se introducen el Id. de artículo y el motivo de la retirada y se envían a la aplicación Store Manager, se retienen los artículos retirados de la tienda.

  • Funcionalidad de administración de inventario, proporcionada para crear una solicitud de envío de inventario y enviarla a las tiendas. El Id. de tienda se selecciona en una lista desplegable y la cantidad que se transferirá se selecciona para completar la transferencia.

  • Configuración de reglas empresariales, proporcionadas para crear las reglas empresariales para transferir información de ventas desde las tiendas en tiempo real. Esta información se almacena en el archivo SampleBusinessRules.xml. A continuación se explica la configuración de las reglas empresariales:

  • Frecuencia de transmisión de prioridad:

    • Inmediata

    • Cada <cuadro de texto> horas

  • Frecuencia de transmisión estándar:

    • Cada <cuadro de texto> horas

    • Una vez al día (al completarse un turno en el PDV)

  • Artículos de gran valor:

    • Recuento de precio unitario de artículo >= <cuadro de texto> $ como gran valor

  • Guardar/cancelar:

    • Guardar los valores en un archivo XML en la ruta de acceso leída de Web.config

Portal de Store Manager

Esta aplicación SharePoint actúa como la aplicación Store Manager que se ejecuta en una aplicación de Tablet PC o PDA. Todos los mensajes y notificaciones del PDV se enrutan a esta aplicación. La aplicación Store Manager PDA actúa como interfaz para todas las notificaciones que se enviarán al servicio Web Store o se recibirán de él. En esta aplicación, Store Manager PDA recibe la notificación del PDV mediante una llamada a la base de datos.

La aplicación Store Manager PDA se usa para editar el precio de los artículos, ver los datos de ventas e iniciar la aplicación Store Manager de Windows desde el selector de vínculos rápidos.

Formularios de InfoPath: Siempre que Store Manager recibe notificaciones de artículo no encontrado en el dispositivo PDA o Tablet PC, se inicia un formulario InfoPath para editar el precio de un artículo. El formulario InfoPath se publica en la biblioteca de formularios de SharePoint Portal.

Web de notificaciones: Se ha desarrollado un elemento Web que muestra todas las notificaciones generadas por las aplicaciones de PDV y Store Manager. Todos los mensajes y notificaciones del PDV se enrutan a esta aplicación. La aplicación Store Manager PDA actúa como interfaz para todos los mensajes que se enviarán al servicio Web Store o se recibirán de él.

Web de datos de ventas: Se ha desarrollado un elemento Web en Business Scorecard Manager para mostrar la información de ventas semanales de forma gráfica. Los datos se leen desde el cubo de servicios de análisis, que agrega y procesa los datos de ventas. Business Scorecard Manager se usa para publicar la información de datos de ventas en la biblioteca de SharePoint Portal.

Figura 5. Elemento Web de datos de ventas de ejemplo

Estándares para el sector minorista

Los estándares del sector minorista son muy importantes, ya que ayudan a estandarizar las interfaces entre dispositivos (por ejemplo, un escáner y un terminal de punto de venta) o aplicaciones y definir normas para interactuar con el dispositivo. Los estándares del sector minorista también garantizan que los mensajes entre las aplicaciones compartidas estén en un formato predecible, por lo que las aplicaciones desarrolladas por distintas personas pueden entenderse entre sí. Los estándares benefician tanto a programadores de aplicaciones como a usuarios finales. Desde el punto de vista de los programadores, los estándares reducen el costo del diseño y desarrollo de los sistemas, además de permitir una migración sencilla y la especialización en un área de aplicación. Desde el punto de vista del minorista, los estándares permiten la integración o la interoperabilidad de dispositivos y aplicaciones de distintos proveedores, lo que permite la creación de sistemas más rentables, personalizables, avanzados y potentes. Los estándares también proporcionan libertad a los clientes para seleccionar las aplicaciones de mayor calidad que mejor se ajusten a sus requisitos.

Los estándares del sector minorista pueden ofrecer las siguientes ventajas al sector:

  • Soluciones menos caras.

  • Experiencia más satisfactoria para el usuario.

  • Aumento de la productividad.

  • Reducción del costo de mantenimiento.

  • Posibilidad de seleccionar las mejores aplicaciones.

  • Se basan en un lenguaje abierto (como XML) que es independiente del proveedor y que cualquier aplicación puede generar y consumir, sin importar la plataforma o el proveedor. El estándar define los datos que se intercambiarán; XML proporciona un lenguaje abierto para transmitir datos, mientras que los métodos de transporte abiertos, como los servicios Web, permiten que las aplicaciones intercambien dichos datos.

  • El cliente tiene flexibilidad para cambiar de una aplicación a otra con pocas dificultades.

La asociación ARTS (Association of Retail Technology Standards) usa tiene los estándares denominados IXRetail para POSLog y otros datos sobre transacciones relacionadas con las ventas. POSLog de IXRetail describe las distintas interfaces que un sistema de PDV usa para comunicar los resultados de sus actividades a otros sistemas de la empresa minorista. POSLog incluye numerosos tipos distintos de transacciones y eventos. El esquema POSLog de IXRetail consta de un único esquema XML que define el conjunto de todas las transacciones y eventos posibles que puede enviar un PDV a otro sistema.

IXRetail se basa en el modelo de datos de ARTS para desarrollar esquemas y conjuntos de mensajes XML, a fin de facilitar la integración entre aplicaciones dentro de una empresa minorista. La solución de la aplicación de ejemplo debe cumplir los esquemas XML estándar de IXRetail de ARTS para interactuar con las aplicaciones dentro de la empresa minorista. Los esquemas que se usan en la aplicación de ejemplo cumplen el estándar IXRetail y se extraen del conjunto estándar de esquemas que facilita ARTS. El flujo de datos entre la tienda y la línea de negocio se lleva a cabo con estos esquemas.

Esta implementación de referencia usa los estándares IXRetail que pertenecen a POSLog, donde los artículos se compran y devuelven. Aquí se muestra un POSLog de IXRetail de ejemplo.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- UseCase: Item Purchase from shelf -->
<!-- Note: This example includes all optional fields -->
<POSLog
xmlns="http://www.nrf-arts.org/IXRetail/namespace/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace/ POSLog.xsd">
<Transaction CancelFlag="false" OfflineFlag="false" TrainingModeFlag="false">
<RetailStoreID>HighStreet</RetailStoreID>
<RevenueCenterID>6333-1221</RevenueCenterID>
<WorkstationID>POS5</WorkstationID>
<TillID>22</TillID>
<SequenceNumber>4294967295</SequenceNumber>
<BusinessDayDate>2001-08-13</BusinessDayDate>
<BeginDateTime>2001-08-13T09:03:00</BeginDateTime>
<EndDateTime>2001-08-13T09:05:00</EndDateTime>
<OperatorID>John</OperatorID>
<CurrencyCode>USD</CurrencyCode>
<RetailTransaction Version="2.1" OutsideSalesFlag="false">
<ManagerApproval>false</ManagerApproval>
<ReceiptDateTime>2001-08-13T09:04:32</ReceiptDateTime>
  <LineItem VoidFlag="false">
  <SequenceNumber>1</SequenceNumber>
  <BeginDateTime>2001-09-16T09:04:00</BeginDateTime>
  <EndDateTime>2001-09-16T09:04:03</EndDateTime>
    <Sale ItemType="Stock">
    <POSIdentity>
      <POSItemID>01234567890123</POSItemID>
    </POSIdentity>
    <ItemID>CA7865</ItemID>
    <MerchandiseHierarchy Level="Department">Chocolates</MerchandiseHierarchy>
    <ItemNotOnFileFlag>false</ItemNotOnFileFlag>
    <Description>4oz Dark Chocolate</Description>
    <TaxIncludedInPriceFlag>false</TaxIncludedInPriceFlag>
    <UnitCostPrice>1.23</UnitCostPrice>
    <UnitListPrice>1.79</UnitListPrice>
    <RegularSalesUnitPrice>1.63</RegularSalesUnitPrice>
    <InventoryValuePrice>1.23</InventoryValuePrice>
    <ActualSalesUnitPrice>1.63</ActualSalesUnitPrice>
    <ExtendedAmount>4.89</ExtendedAmount>
    <DiscountAmount>0.00</DiscountAmount>
    <ExtendedDiscountAmount>4.89</ExtendedDiscountAmount>
    <Quantity>3</Quantity>
  </Sale>
</LineItem>
<Total TotalType="TransactionGrossAmount">4.89</Total>
  </RetailTransaction>
</Transaction>
</POSLog>

Interacción de los componentes

En la sección anterior se han descrito los distintos componentes que constituyen la aplicación de ejemplo. En esta sección se describirá cómo estos componentes interactúan y se combinan para crear una herramienta ágil para tomar decisiones prácticamente en tiempo real en el sector minorista.

Esta implementación de ejemplo supone la creación de la arquitectura de referencia, el código de ejemplo para demostrar las ventajas del acoplamiento flexible y las capacidades de la plataforma de Microsoft para lograrlo con el mínimo esfuerzo. Además, se muestra cómo un minorista puede cambiar a un proceso de toma de decisiones próximo al tiempo real de un modo incremental, a diferencia de lo que sucede con una metodología que se base en cortar y reemplazar. La implementación conlleva el uso de WCF para crear servicios Web que se comuniquen prácticamente en tiempo real con los sistemas de la empresa para intercambiar mensajes. Los estándares IXRetail se usan para intercambiar datos con los sistemas de la empresa y se ha implementado un acelerador de ejemplo IXRetail personalizado para BizTalk para la comunicación con los sistemas de la empresa.

El método elegido para esta implementación de referencia consistió en implementar la solución con WCF y BizTalk Server, tipos de mensaje IXRetail como formatos de mensajes de intercambio y canónicos, así como mensajería a través de un protocolo de conexión de servicios Web.

Vista de implementación de la arquitectura en la tienda

En esta sección se proporciona una descripción general de la arquitectura de referencia para la tienda.

Figura 6. Interacción con los servicios de la tienda

En la figura 6 se muestra una vista funcional de una tienda con sistemas de PDV, un host local o servidor de tienda, una estación de trabajo del responsable y la base de datos Store. Los sistemas de PDV almacenan información de transacciones en la base de datos local y recuperan la información de precios de la base de datos para realizar las transacciones de ventas. En el diagrama también se muestra un servicio Web, el cual actúa en función de la información almacenada en la base de datos o de los mensajes recibidos de los sistemas de la empresa. Cuando un sistema PDV completa una transacción de venta, el servicio Web toma los datos de venta, éstos se transforman al formato IXRetail estándar y se transfieren a los sistemas de la sede de la empresa. Los servicios Web recopilan los datos de venta según las reglas que han configurado el responsable de la tienda o los sistemas de la sede de la empresa. Por ejemplo, los datos de venta de un artículo en promoción sustituyen a los de otro que no está en promoción para su transferencia al sistema de la sede de la empresa.

Los mensajes salientes realizan los pasos de agregación, transformación y compresión antes de transferirse a los sistemas de la empresa. Esta transferencia de datos en tiempo real desde la tienda a los sistemas de la empresa ayuda al proceso de toma de decisiones en tiempo real en la sede de la empresa. También ayuda a supervisar los indicadores clave de rendimiento (KPI) en tiempo real y puede activar flujos de trabajo en la empresa. Por ejemplo, la transferencia de información relacionada con los niveles de inventario en la tienda puede activar flujos de trabajo para solicitar artículos del proveedor.

Figura 7. Mensajes salientes desde las tiendas

Además, tal como se muestra en la figura 7, los datos de venta de los sistemas de PDV se agregan, transforman y comprimen antes de que se transfieran a los sistemas de la empresa.

Un escenario de artículo no encontrado puede activar un flujo de trabajo de la tienda, por lo que su responsable puede omitir un precio sugerido para que la transacción avance. En un escenario de artículo no encontrado, el servicio Web avisa al responsable en tiempo real, que a su vez inicia la aplicación de administración de inventario en una estación de trabajo o PDA, con el fin de asignar temporalmente un precio para que el dependiente realice la transacción. Al mismo tiempo, el servicio Web avisa al sistema de la empresa del precio que falta. Cuando el responsable de mercancías recibe la alerta de un precio que falta, actualiza el precio y esta información se transfiere a todas las tiendas en tiempo real.

Los mensajes entrantes de los sistemas de la empresa realizan pasos similares, en tiempo real, a los mostrados en la figura 8.

Figura 8. Mensajes entrantes desde los sistemas de la empresa

Los mensajes con actualizaciones de precios o notificaciones de retirada de artículos procedentes de los sistemas de la empresa siguen pasos similares. Por ejemplo, cuando los mensajes de actualización de precios llegan a la tienda, se descomprimen y se transforman antes de transferirse a la base de datos de precios. Las actualizaciones de precios se reflejan en tiempo real en todos los sistemas de PDV de las tiendas.

Por ejemplo, cuando la tienda recibe un mensaje de retirada de artículo, se almacena en la base de datos y se suspende inmediatamente la venta del artículo retirado. Un servicio Web de alerta recibe el mensaje y avisa al responsable de la tienda para que lleve los artículos de la tienda al almacén e impedir que el artículo retirado se siga vendiendo. Esta activación de flujos de trabajo en tiempo real impide la venta de los artículos retirados y reduce las responsabilidades del minorista.

Esta arquitectura de referencia muestra cómo pueden implementarse los servicios en tiempo real con el concepto de arquitectura orientada a servicios, donde los flujos de trabajo se activan sin demasiada intervención manual. Toda la comunicación entre las tiendas y los sistemas de la empresa se realiza mediante mensajes XML estandarizados. Tal como se ha descrito en el capítulo anterior, un mensaje es un documento XML procedente de la tienda, los sistemas de la empresa o un proveedor. Una parte del documento XML identifica el tipo de mensaje y la información de enrutamiento. Cada mensaje está asociado a un esquema XML que define el conjunto de formatos de mensaje válidos. En esta implementación de referencia, los mensajes entrantes procedentes de los sistemas de la empresa se entregan en el formato IXRetail siempre que sea posible a través de HTTP. Aunque los mensajes se pueden intercambiar con distintos patrones, en esta implementación se ha optado por usar la mensajería bidireccional asincrónica.

Cuando en la tienda se recibe un mensaje, se transforma si es necesario, y se almacena en la base de datos para que lo consuman otros servicios. Los demás servicios Web toman el mensaje y activan una alerta o acción.

Vista de implementación de la arquitectura en la sede de la empresa

En la figura 9 se muestra la arquitectura de referencia del sistema de la sede de la empresa. En este caso, MSMQ (no se implementa en la aplicación de ejemplo) se puede usar como un mecanismo de administración de colas; BizTalk se usa para la agregación, transformación y orquestación de los mensajes que llegan a la empresa. Los mensajes contienen desde datos de venta de las tiendas hasta información de retirada de artículos del proveedor o confirmaciones de pedidos de compra. El acelerador BizTalk se usa para establecer comunicación con los sistemas de línea de negocio de la empresa, como sistemas de comercialización o sistemas ERP y el almacén de datos.

BizTalk se usa para transformar los datos y orquestar los mensajes entrantes. Esto contribuye a integrar rápidamente los sistemas de las tiendas con los sistemas de línea de negocio de la empresa.

Figura 9. Arquitectura de referencia de la empresa

La empresa recibe mensajes de las tiendas, los proveedores y los sitios multicanal, como pedidos de comercio electrónico y de venta por catálogo. Los mensajes de las tiendas contienen desde datos de transacciones de venta hasta umbrales de nivel de inventario y solicitudes de precios de artículos. Los datos de transacciones de venta se transforman y almacenan en la base de datos y el almacén de datos en tiempo real. Estas bases de datos facilitan la supervisión de KPI en tiempo real y la capacidad de generación de informes en la empresa. Los pedidos de comercio electrónico y de venta por catálogo requieren comprobaciones de inventario en tiempo real para realizar el pedido, así como para confirmar las solicitudes de los clientes para obtener el artículo en la tienda. Si se implementa correctamente y un pedido de comercio electrónico o de venta por catálogo se acepta con la promesa de que se encontrará en la tienda, esta situación podría dar lugar a clientes disgustados, ya que las tiendas podrían tener agotados estos artículos. Por lo tanto, es fundamental que la aplicación de realización de pedidos compruebe los niveles de inventario en las tiendas en tiempo real antes de aceptar el pedido.

Los mensajes de las tiendas, como los de "artículo no encontrado", generan alertas en la empresa y obligan al responsable de comercialización de productos a introducir el precio de un artículo, que se descarga en tiempo real en las tiendas. Cuando el inventario cae por debajo de un determinado umbral en las tiendas, la empresa recibe un mensaje que activa un flujo de trabajo para generar un pedido de compra y requiere la aprobación por parte del responsable de comercialización de la empresa. A continuación, el pedido de compra se envía al proveedor.

El flujo de información en tiempo real entre las tiendas y la empresa contribuye a mejorar el proceso de toma de decisiones y la supervisión en tiempo real de la empresa.

En la figura 10 se muestran los mensajes salientes desde la empresa. Los mensajes de actualización de precios, comprobaciones de inventario y retirada de artículos se envían a las tiendas en tiempo real, lo que impide que la empresa incurra en pérdidas y la responsabilidad financiera.

Figura 10: Mensajes de empresa salientes

Los mensajes salientes, como los de retirada de artículos recibidos del proveedor, se transmiten inmediatamente a las tiendas para suspender la venta posterior de los artículos retirados. El mensaje del proveedor se recibe en cualquier formato y se transforma a un formato XML. A continuación, se efectúa una búsqueda en el inventario para comprobar las tiendas en las que se encuentra el artículo retirado y el mensaje de retirada se transmite a dichas tiendas.

Las respuestas a las solicitudes de artículo no encontrado también siguen una ruta similar. La información actualizada del precio sólo se envía a las tiendas que venden el artículo en cuestión.

Flujo de información

En esta sección se describe el flujo de la información para cada uno de los escenarios. Se muestra cómo interactúan los distintos servicios para facilitar la toma de decisiones en tiempo real, tanto en la tienda como en la empresa. Cada uno de los escenarios de ejemplo se describe de forma detallada, junto con los pasos correspondientes para enviar la información al lugar adecuado en tiempo real.

Escenario 1: Artículo no encontrado

Tal como se ha descrito en la sección anterior, se trata de un escenario habitual en el entorno minorista. En este escenario se requiere que el responsable intervenga en tiempo real con el fin de garantizar que los artículos pasen por caja sin problemas y ofrecer una experiencia satisfactoria para el cliente.

Los pasos necesarios para replicar este escenario con la aplicación de ejemplo, junto con la solución, son los siguientes:

  1. Seleccione un artículo en la aplicación de PDV para el que el precio de la tabla ItemMaster de la base de datos Store sea cero.

  2. Haga clic en Add (Agregar) para pasar el artículo por caja. Se muestra el mensaje siguiente: "Price not found for this item. Do you want to convey it to the Store Manager?" (Precio no encontrado para este artículo. ¿Desea enviarlo a Store Manager?)

  3. Haga clic en Yes (Sí). La notificación se envía a Store Manager.

  4. Haga clic en la ficha Notifications (Notificaciones) para ver la notificación en la aplicación Store Manager.

  5. En la aplicación Store Manager, haga clic en la ficha Inventory (Inventario) y seleccione el artículo cuyo precio no se ha encontrado. Edite el precio y guárdelo. Se envía un correo electrónico al responsable de comercialización en la sede de la empresa y el precio se actualiza en la base de datos Store.

  6. Abra la aplicación Merchandising en la sede de la empresa desde la siguiente ubicación: http://localhost/HQSystemsetup/UpdateItem.aspx

  7. Actualice el precio del artículo cuyo precio no se encontró y guárdelo

  8. El precio final se guarda en la base de datos Store y en la base de datos HQ, y se muestra el mensaje.

  9. De nuevo, seleccione el mismo artículo en el PDV. Ahora se puede pasar el artículo por caja con el precio actualizado.

Figura 11. Escenario de artículo no encontrado

Figura 12. Diagrama de secuencia de escenario de artículo no encontrado

Escenario 2: Retirada de artículo

Tal como se ha descrito en la sección anterior, se trata de un escenario habitual en el entorno minorista. En este escenario se requieren acciones en tiempo real tanto por parte del responsable como de los empleados. En la aplicación de ejemplo se explica cómo se puede automatizar este escenario por completo mediante el uso de las nuevas tecnologías, en concreto, los servicios Web.

Los pasos necesarios para replicar este escenario con la aplicación de ejemplo, junto con la solución, son los siguientes:

  • El proveedor inicia el proceso de retirada iniciando la aplicación Supplier en la siguiente ubicación: http://localhost/SupplierAppSetUp/SupplierApp.aspx

  • Se selecciona un artículo y el proveedor envía el mensaje de retirada de artículo al responsable de comercialización cuyo identificador de correo está configurado en el archivo Web.config de la aplicación Supplier

  • Tras recibir el correo electrónico, la aplicación de la sede de la empresa se inicia en la siguiente ubicación: http://localhost/HQSystemSetUp/RecallItem.aspx

  • Al hacer clic en el botón Notify Recall (Notificar retirada) se envía una notificación a Store Manager.

  • Al hacer clic en Notifications (Notificaciones) en la aplicación Store Manager, se muestra la notificación.

  • Cuando se intenta pasar el artículo retirado por caja, se muestra un mensaje en el que se indica que se trata de un artículo retirado que no se puede pasar por caja.

  • Simultáneamente, en la aplicación Store Manager se muestra una notificación de retirada de artículo con el fin de avisar al responsable para que quite los artículos retirados de las estanterías de la tienda.

Figura 13. Escenario de artículo retirado

Figura 14. Diagrama de secuencia de escenario de artículo retirado

Escenario 3: Artículo agotado

Tal como se ha descrito en la sección anterior, se trata de un problema muy habitual en el sector minorista. En la aplicación de ejemplo se explica cómo las nuevas tecnologías pueden solucionar este problema y ofrecer una experiencia del cliente mucho más satisfactoria.

Los pasos necesarios para replicar este escenario con la aplicación de ejemplo, junto con la solución, son los siguientes:

  1. Cuando se intenta pasar un artículo por caja, el dispositivo de PDV muestra un mensaje de artículo agotado.

  2. Inmediatamente se envía una notificación al responsable de la tienda para que transfiera artículos del almacén a las estanterías.

  3. Se repiten los mismos pasos si los niveles de inventario del artículo pasado por caja están por debajo de un determinado umbral, que fija la sede de la empresa.

  4. Se envía una alerta al responsable de la tienda, en la que se indica la situación (artículo agotado).

  5. Al hacer clic en la ficha Notification (Notificación) en la aplicación Store Manager se abre la alerta.

  6. Al hacer clic en el vínculo Stock Transfer (Transferencia de stock) en la aplicación Store Manager se transfiere el inventario del almacén a la estantería (siempre que el almacén tenga el inventario).

  7. A continuación, se pueden transferir algunos productos desde el almacén de la empresa si se abre la aplicación de la sede de la empresa desde la siguiente ubicación: http://localhost/HQSystemsetup/InventoryShipment.aspx

  8. En la aplicación de la sede de la empresa, seleccione el artículo agotado y, en el cuadro combinado, la ubicación de la tienda a la que se debe transferir el artículo. Por último haga clic en OK (Aceptar)

  9. Los artículos se transfieren desde la tabla de inventario de la base de datos HQ a la aplicación Store Manager donde está pendiente la aceptación de existencias del artículo

  10. Los artículos se pueden recibir en la tienda si se hace clic en el vínculo Stock Transfer(In) (Transferencia de existencias [Entrada]) en la aplicación Store Manager y si se aceptan las existencias que se muestran.

  11. El inventario se actualiza en la base de datos Store

Figura 15. Escenario de artículo agotado

Figura 16. Diagrama de secuencia de escenario de artículo agotado

Escenario 4: Transferencia de datos de ventas de artículos en promoción en tiempo real

Tal como se ha descrito en la sección anterior, la transferencia de datos de ventas de tienda se lleva a cabo como un proceso por lotes y, a continuación, se transfiere a la empresa por la noche o dos veces al día. Esto limita la visibilidad imprescindible para la empresa en relación con el rendimiento de las tiendas. Es necesario facilitar datos de transacciones de venta prácticamente en tiempo real. En la aplicación de ejemplo se muestra la transferencia de la información de las transacciones en tiempo real desde la tienda a los sistemas de la empresa. También se muestra la aplicación de determinadas reglas empresariales en la transmisión de la información de las transacciones de ventas en tiempo real. Por ejemplo, la información de ventas relacionada con los artículos de gran valor y en promoción se transmite en tiempo real con la máxima prioridad. Los demás datos de transacciones obtienen una prioridad secundaria en la transmisión en tiempo real. El servicio alojado en el host local recopila las actualizaciones simultáneas de los datos de ventas procedentes de varios dispositivos de punto de venta, las agrupa y las transforma para, posteriormente, transferir los datos según las reglas establecidas por la sede de la empresa.

Los pasos necesarios para replicar este escenario con la aplicación de ejemplo, junto con la solución, son los siguientes:

  1. Las reglas para la transferencia en tiempo real se establecen en la sede de la empresa iniciando la aplicación HQ en la siguiente ubicación: http://localhost/HQSystemsetup/SalesConfig.aspx

  2. A continuación, introduzca los detalles en Details y la condición necesaria para asignar prioridad a un artículo mediante la aplicación Web de la sede de la empresa

  3. Estos detalles se almacenan en el archivo BusinessRules.xml cuya ruta de acceso se establece en la aplicación BizTalk. Se almacenará en la ubicación compartida que se indica en el archivo de configuración

  4. Abra la aplicación de PDV y seleccione los elementos que se pasarán por caja. Haga clic en Proceed (Continuar). Se muestra una notificación Check for PRITRANS (Comprobar PRITRANS).

  5. Seleccione True (Verdadero) para el bit transmitido de SalesDetails en la tabla de la base de datos Store para los datos con alta prioridad de transmisión

  6. Los datos se transfieren inmediatamente a la tabla SalesDetails de la base de datos HQ para la tabla de datos con alta prioridad de transmisión

  7. Cierre el PDV. En una ventana emergente se muestra "Checking for standard data transmission" (Comprobando transmisión de datos estándar). A continuación se transmiten todos los datos de baja prioridad a la tabla SalesDetails de la base de datos Store

Figura 17. Escenario de transferencia de datos de ventas de artículos en promoción en tiempo real

Escenario 5: Cadena de suministro

Tal como se ha descrito anteriormente, los datos de venta de la tienda normalmente se transfieren a los sistemas de la empresa por lotes y de noche. En consecuencia, la visibilidad para la empresa es deficiente en relación con los niveles de existencias en el inventario de las tiendas y se puede ocasionar un retraso en la generación de pedidos para los proveedores que entreguen los productos mucho más tarde. A su vez, todo esto puede provocar una experiencia negativa para el cliente. En la aplicación de ejemplo se explica cómo las nuevas tecnologías pueden solucionar este problema y ofrecer una experiencia del cliente mucho más satisfactoria.

Los pasos necesarios para replicar este escenario con la aplicación de ejemplo, junto con la solución, son los siguientes:

  1. Se pasa un artículo por caja en el PDV. El nivel de inventario se actualiza y, si está por debajo del nivel de umbral, se envía una notificación a la aplicación Store Manager

  2. El responsable de la tienda transferirá los artículos restantes desde el almacén a las estanterías

  3. Se deben solicitar nuevos artículos para mantener intactos la cadena de suministro y los niveles de inventario. Para solicitar nuevos artículos, abra la aplicación HQ desde la siguiente ubicación: http://localhost/HQSystemsetup/Purchase Order.aspx

  4. Introduzca los detalles del artículo en Details (Detalles) y haga clic en Send PO (Enviar pedido de compra) para actualizar el inventario en la base de datos HQ.

  5. Una vez enviado el correo electrónico para la confirmación del pedido, abra la aplicación HQ desde la siguiente ubicación: http://localhost/HQSystemsetup/InventoryShipment.aspx

  6. Seleccione el artículo y la ubicación de la tienda a la que se debe transferir el artículo en el cuadro combinado y haga clic en OK (Aceptar).

  7. Los artículos se transfieren desde la tabla de inventario de la base de datos HQ a la aplicación Store Manager donde está pendiente la aceptación de las existencias del artículo

  8. Después de que el responsable finalice el paso de recepción yendo a la aplicación Store Manager y aceptando la transferencia de inventario, se puede pasar el artículo por caja en el PDV

  9. En la aplicación de PDV, se puede comprobar el inventario del artículo haciendo clic en Check Availability (Comprobar disponibilidad). De este modo se muestra la cantidad actualizada de la base de datos Store.

Figura 18. Escenario de cadena de suministro

Decisiones técnicas

Existen numerosas formas para agilizar una empresa minorista. No obstante, el uso de una tecnología que facilite el desarrollo y el mantenimiento, y que sea flexible en previsión de futuras ampliaciones, reducirá el costo total de propiedad para una empresa minorista. En esta sección se describen la funcionalidad, las características de la tecnología más reciente y las ventajas asociadas al uso de estos elementos de tecnología.

Windows Communication Foundation (WCF)

WCF (cuyo nombre en código anterior era "Indigo") es un conjunto de tecnologías .NET para crear y ejecutar sistemas conectados. Se trata de una nueva infraestructura de comunicaciones que se basa en la arquitectura de servicios Web.

WCF proporciona compatibilidad con servicios Web avanzados mediante mensajes seguros, fiables y procesados, además de interoperabilidad. No obstante, cabe destacar tres aspectos importantes de WCF: la unificación de varias tecnologías existentes de Microsoft, la compatibilidad con la interoperabilidad entre proveedores y la orientación a servicios explícita.

Además, una de las principales preocupaciones al desarrollar la aplicación de ejemplo fue que se estaban uniendo sistemas desconectados (punto de venta, línea de negocio, tienda) en una aplicación en tiempo real difícil de implementar. Pero como el mecanismo fundamental de comunicación de WCF es SOAP, las aplicaciones WCF se pueden comunicar con otros software en ejecución en varios contextos. Una aplicación basada en WCF puede interactuar con:

  • Aplicaciones WCF que se ejecuten en un proceso distinto en el mismo equipo Windows.

  • Aplicaciones WCF que se ejecuten en otro equipo Windows.

  • Aplicaciones basadas en otras tecnologías, como los servidores de aplicaciones basados en Java 2 Enterprise Edition (J2EE) que admitan servicios Web estándar. Estas aplicaciones se pueden ejecutar en equipos Windows o en equipos con otros sistemas operativos, como Sun Solaris, z/OS de IBM o Linux.

Por lo tanto, si se desea ampliar esta aplicación de ejemplo para plataformas que no sean de Microsoft, se puede llevar a cabo de forma bastante sencilla.

Para obtener más que la comunicación básica, WCF implementa un grupo de nuevas tecnologías de servicios Web que se denominan especificaciones WS-* de forma colectiva. En estos documentos se definen formas de agregar mensajería fiable, seguridad, transacciones, etc. de varios proveedores a los servicios Web basados en SOAP. Las especificaciones de servicios Web admitidos en la primera versión de WCF son WS-Addressing, WS-Policy, WS-MetadataExchange, WS-ReliableMessaging, WS-Security, WS-Trust, WS-SecureConversation, WS-Coordination, WS-AtomicTransaction y MTOM (Message Transmission Optimization Mechanism) de SOAP.

Finalmente, debido a que WCF proporciona una base estándar para el software orientado a servicios, será la base de una gran parte de las comunicaciones de Windows.

Las consecuencias de esta tecnología serán importantes. Los programadores de aplicaciones distribuidas en Windows, en concreto las aplicaciones que deben interactuar con las de otras plataformas, deben prestar especial atención, porque WCF cambiará su vida.

Implementación de WS-* en la tienda

WS-*(WS-Security, WS-Reliability) permite que las organizaciones creen aplicaciones de servicios Web fiables e interoperativas mediante la definición de un mecanismo estándar para identificar e intercambiar mensajes de servicios Web entre varios puntos finales. Con una forma estándar de expresar dónde se debe entregar un mensaje en una red de servicios Web, los programadores pueden simplificar la comunicación y el desarrollo de servicios Web, así como evitar la necesidad de desarrollar soluciones costosas y exclusivas que tienen dificultades para interactuar entre diferentes plataformas.

WS-* es una parte clave de la arquitectura de servicios Web básicos. En concreto, la especificación está diseñada para ser la base de otras especificaciones, como WS-ReliableMessaging, WS-Federation y WS-AtomicTransaction, para proporcionar una forma independiente del protocolo y común de encontrar servicios Web que admitan características como transacciones, seguridad, entrega de mensajes fiable y federación de identidades.

WS-Security: Autenticación de Windows

Los archivos de configuración de esta aplicación establecen el atributo de modo del elemento Security de wsHttpBinding en Message y el atributo clientCredentialType en Windows. Otras opciones de clientCredentialType son None, Username y Certificate. Otras opciones del modo de seguridad son Transport y TransportWithMessage.

<bindings>
   <wsHttpBinding>
      <binding name="Binding1">
         <security mode="Message">
               <message clientCredentialType="Windows"                
                negotiateServiceCredential="True" />
         </security>
         <reliableSession enabled="true" ordered="true" />
      </binding>
   </wsHttpBinding>
    </bindings>

La configuración del punto final de cliente consta de un nombre de configuración, una dirección absoluta para el punto final de servicio, la vinculación y el contrato. La vinculación de cliente se configura con los valores adecuados de securityMode y authenticationMode. En un escenario de ejecución en varios equipos, use los elementos identity y userPrinicpalName.

<system.serviceModel>
   <client>
      <endpoint address="http://mmoin/contoso/Service.svc" 
           bindingConfiguration="WSHttpBinding_IStoreService"
           binding="customBinding" contract="IStoreService">
          <identity>
          <servicePrincipalName value="host/mmoin" />
          </identity>
      </endpoint>
   </client>
   <bindings/>
</system.serviceModel>

El código fuente del servicio se ha modificado para demostrar cómo se puede usar CurrentPrincipal para tener acceso a la identidad del autor de la llamada. Este código requiere la inclusión del espacio de nombres System.Security.Principal.

WS-Security: Kerberos

Existen varios escenarios en los que se usa la autenticación Kerberos en vez de la de Windows.

La negociación SSPI de Windows requiere internamente varios intercambios de información entre el cliente y el servidor para llegar al protocolo de autenticación real que se usará. Si el rendimiento es fundamental, es posible que no resulten aceptables las negociaciones de varios tramos.

El patrón de intercambio de mensajes previsto podría indicar que el cliente se autenticará con el servicio usando la autenticación Kerberos en cada mensaje.

Con WCF, se puede crear e implementar el cliente y el servicio de modo que se requiera el uso de Kerberos.

El archivo de configuración de cliente y de servidor se debe modificar para indicar que no se debe usar la negociación para esta vinculación.

<bindings>
   <wsHttpBinding>
      <binding name="Binding1">
         <security mode="Message">
            <message clientCredentialType="Windows"
            negotiateServiceCredential="False" />
         </security>
   </wsHttpBinding>
</bindings>

Si este ejemplo se ejecuta en varios equipos, se debe especificar un nombre completo de equipo en la dirección de punto final. Además, la identidad debe especificar el nombre principal de servicio con el nombre completo de equipo. WCF casa el nombre completo de host de la dirección de punto final con el nombre principal de servicio. Si se supera esta comprobación, se considera que el cliente ha autenticado el servicio.

WS-Security: anónimo

El ejemplo Anonymous muestra cómo implementar una aplicación WCF que usa WS-Security sin autenticación de cliente, pero que requiere la autenticación de servidor con el certificado X.509v3 del servidor. Todos los mensajes de aplicación entre el cliente y el servidor están firmados y cifrados.

Configuración de cliente

<security mode="Message">
   <message clientCredentialType="None" />
</security>

<!--Service Configuration-->

<security mode="Message">
   <message clientCredentialType="Certificate" />
</security>

WS-Security: certificado

Configurar WS-Security con la autenticación de certificado X.509v3 para que el cliente requiera la autenticación de servidor mediante el certificado X.509v3 del servidor.

El certificado de servidor debe contener el mismo valor para SubjectName que findValue en serviceCredentials.

<serviceCredentials>
   <serviceCertificate findValue="localhost"
           storeLocation="LocalMachine" storeName="My"
           x509FindType="FindBySubjectName" />
</serviceCredentials>

<!--Client & service both should be configured for clientCredentialType 
as certificate.-->

<security mode="Message">
   <message clientCredentialType="Certificate" />
</security>

WS-Security: nombre de usuario

Para implementar una aplicación que usa WS-Security con autenticación de nombre de usuario, todos los mensajes de aplicación entre el cliente y el servidor están firmados y cifrados. De forma predeterminada, el nombre de usuario y la contraseña facilitados por el cliente se usan para iniciar sesión en una cuenta de Windows NT válida.

<security mode="Message">
   <message clientCredentialType=" UserName " />
</security>

La llamada de cliente usará el nombre de usuario y la contraseña.

proxy.ClientCredentials.UserNamePassword.UserName = username;
proxy.ClientCredentials.UserNamePassword.Password = password;

WS-Reliability

El servicio se configurará del siguiente modo

<reliableSession enabled="true" ordered="true" />

BizTalk Server 2006

BizTalk Server 2006 es un servidor de administración de procesos empresariales (BPM) que permite a las compañías automatizar y optimizar los procesos empresariales. Cuenta con herramientas eficaces y fáciles de usar para diseñar, desarrollar, implementar y administrar estos procesos. Por lo tanto, para administrar el flujo empresarial desde la tienda a la empresa y viceversa, y para administrar el flujo de trabajo, se eligió BizTalk Server 2006.

Además, BizTalk Server 2006 creó mensajes XML a partir de esquemas IXRetail que se usaron para la comunicación entre la tienda y la sede central.

BizTalk Server 2006 proporciona compatibilidad para intercambiar mensajes de distintos equipos de forma eficaz entre las tiendas y la sede central. Dada la diversidad de estilos de comunicación que existen, el motor de BizTalk Server 2006 debe admitir varios protocolos y formatos de mensajes, como IXRetail.

BizTalk Server 2006 también proporciona adaptadores para diferentes productos como Microsoft SQL Server para su integración. Por lo tanto, en la aplicación de ejemplo, para la integración con el servicio Store y SQL Server, se usaron el adaptador de servicio Web y el adaptador de SQL.

La lógica empresarial para los distintos escenarios minoristas se implementó con el motor de orquestación de BizTalk Server 2006, que constituyó una capa intermedia común para alojar la lógica empresarial.

BizTalk Server 2006 también proporciona una función de inicio de sesión único empresarial y, por tanto, la capacidad de asignar la información de autenticación entre sistemas Windows y no Windows. Por lo tanto, se puede lograr la interoperabilidad entre plataformas heterogéneas.

Resumiendo, el objetivo de BizTalk Server 2006 consistió en ayudar a la aplicación de ejemplo a superar los desafíos de crear procesos empresariales automatizados basados en sistemas diversos y a usar los cimientos del producto, el motor de BizTalk Server 2006, que proporciona funciones básicas de mensajería y orquestación.

BizTalk Server agregará compatibilidad con WCF como una opción de comunicaciones con posterioridad a la publicación de BizTalk Server 2006.

Business Scorecard Manager

Management Dashboard es una aplicación creada en la aplicación de ejemplo para que los responsables vean las ventas, los niveles de inventario y las alertas en una ubicación Web común, lo que les permite administrar el stock y los recursos cómodamente en las tiendas.

Management Dashboard mejora la eficacia de un responsable al proporcionarle un portal de informes basados en Web que permite a los responsables tener acceso y ver sólo la información más importante y más pertinente. Se pueden ver varios informes simultáneamente que destacan cuestiones clave de los datos de las tiendas. Se pueden desglosar hasta llegar a los informes detallados subyacentes. Para ello, se ha usado Business Scorecard Manager (BSM) 2005.

Un escritorio digital mejora la aplicación de ejemplo al usar por completo el escritorio de equipo en combinación con otras informaciones necesarias: datos no estructurados, herramientas para trabajo en colaboración, diagramas y gráficos, así como otros cuadros de mandos. El escritorio digital ofrece una vista exhaustiva para la comunicación y análisis de datos, muestra tendencias en forma de gráficos y proporciona al usuario información contextual adicional para la toma de decisiones.

BSM es una aplicación completa de cuadro de mandos y escritorio digital que proporciona información contextual exhaustiva de los factores clave del negocio. Con un diseño que permite un uso intuitivo y sencillo, cualquier usuario de la organización puede crear, supervisar y administrar los indicadores de rendimiento clave (KPI) que considere relevantes.

Con BSM, la aplicación de ejemplo proporciona los KPI de ventas, inventario y datos de promoción en Management Dashboard para que los responsables de tienda analicen las relaciones entre los KPI y los objetivos empresariales tangibles

Desde un punto de vista empresarial, mediante el seguimiento de los datos más importantes en BSM en relación con el rendimiento y las finanzas, la aplicación de ejemplo mejora considerablemente la visibilidad y acelera la elaboración de informes, por lo que está atenta a los cambios materiales en el sector minorista y se ajusta a los requisitos de confidencialidad y archivo.

Además, el uso de un sistema equilibrado de cuadros de mandos va más allá de los datos financieros para vincular la estrategia empresarial con la actuación de la línea de negocio. Esto se debe a que los cuadros de mandos normalmente elaboran informes sobre el rendimiento de la organización en términos tanto financieros como no financieros, según los KPI. La estrategia empresarial tiende a abarcar los esfuerzos de toda la organización, desde finanzas y ventas hasta operaciones, por lo que los cuadros de mandos y los KPI que los componen también deben tener el mismo alcance.

BSM se usó en la implementación de ejemplo para:

  • Emplear una interfaz gráfica clara que permitiera la interpretación de los datos sin ambigüedades.

  • Estar totalmente habilitada para Web, lo cual conlleva una transmisión instantánea del mismo mensaje a varias ubicaciones remotas con un medio universal y, por ello, una visibilidad en tiempo real de las tendencias empresariales clave. Así es como las ventas y los niveles de inventario de BSM se actualizan en tiempo real en la aplicación de ejemplo, que era uno de los requisitos clave al elegir BSM para la administración de escritorios digitales.

  • Introducir flexibilidad mediante el fomento de la definición individual de objetivos, así como la medición, supervisión y administración del rendimiento comercial.

  • Asignar y vincular la información de ventas a los objetivos estratégicos de la organización, crear una operación centrada en la estrategia y fomentar el uso de la información para medir y optimizar el motor de ventas, o bien impulsar nuevas iniciativas.

  • Proporcionar información personalizada y puntual entre diferentes tiendas a los distintos responsables.

  • Volver a conectar la información con los procesos empresariales que la han creado para que funcionen de forma más eficiente y eficaz.

  • Habilitar distintas vistas de datos e informes y análisis exhaustivos y de fácil ejecución para proporcionar una herramienta empresarial de elevada personalización con valor cuantificable.

  • Presentar datos estructurados, así como documentos, hojas de cálculo, vínculos y otros datos sin estructurar, todo lo cual contribuye un proceso de toma de decisiones equilibrado y documentado.

  • Ofrecer una capa sobre aplicaciones de línea de negocio de ventas tradicionales, con el fin de proteger la inversión financiera y de formación y aprovechar los datos existentes.

Conclusión

Las tecnologías innovadoras, como la identificación por radiofrecuencia (RFID), pagos remotos, pagos por dispositivos móviles, pagos mediante sistemas biométricos, Wi-Fi, etc., suponen desafíos y oportunidades para los minoristas. Los minoristas que primero adopten estas tecnologías y las usen para llegar a más clientes y abrir nuevos mercados verán crecer sus ingresos, mientras que quienes recelen de adoptar estas tecnologías tendrán más dificultades para sobrevivir en un mercado tan competitivo.

A medida que crece la disponibilidad de la banda ancha y del sistema RFID en el mercado, los clientes esperan de los minoristas una experiencia más satisfactoria. Esto no sólo requiere adoptar estas tecnologías internamente, sino también cambiar los sistemas existentes para consumir los nuevos datos que se generan. Estos datos adicionales, si se usan correctamente, pueden ayudar a tomar decisiones en tiempo real, o, de lo contrario, pueden desbordar y acabar con una empresa. Por lo tanto, la toma de decisiones en tiempo real resulta fundamental en el sector minorista. A medida que los clientes se hacen más exigentes y la presión competitiva aumenta, crece la necesidad de agilidad. Para lograr la agilidad se necesita la disponibilidad de la información adecuada, en el momento adecuado y en el lugar adecuado.

Los minoristas trabajan con márgenes muy reducidos, por lo que siempre intentan modos de recortar costos. Las aplicaciones antiguas impiden el crecimiento y el departamento de TI dicta el crecimiento de la empresa en vez de apoyarlo. Para que el departamento de TI respalde las necesidades empresariales en constante cambio, debe disponer de soluciones ágiles y adaptables que se basen en tecnologías que permitan el crecimiento. La orientación a servicios es el nuevo paradigma de arquitectura que tiene el potencial de ayudar al departamento de TI a ser ágil y a atender las demandas empresariales.

Agradecimientos

Me gustaría expresar mi agradecimiento a Nick Lewis, Tim Gruver y Michael Graber de Microsoft Corporation; Avadh Jain, Anurag Katre y Ramesh Lankaand de Tata Consultancy Services; y Jon Tobey de Ideastream por su ayuda en la realización de este trabajo.

Mostrar: