Problema, Punto de Dolor y Objetivo

InfraImport tiene la información comercial y operativa separada o poco integrada. Esto significa que ventas, clientes, pedidos y stock no se visualizan juntos, por lo que puede ser difícil saber qué productos quedan realmente disponibles, cuáles se venden más, qué clientes están activos y cuándo debería realizarse una nueva importación. El problema no es únicamente que se utilicen herramientas manuales, sino que una modificación en un sector no necesariamente actualiza el resto de la información.

Nuestro objetivo fue diseñar un sistema centralizado que integre clientes, productos, ventas, pedidos, stock y reportes. De esta manera, la empresa puede tener una visión más completa y actualizada del negocio. Elegimos enfocarnos en este punto porque afecta directamente la venta y la capacidad de cumplir con los pedidos. Si la información de stock es incorrecta, la empresa puede vender algo que no tiene o detectar demasiado tarde que necesita importar.

Cómo Funciona y por qué Resuelve el Problema

La solución no consiste solamente en pasar la información a una pantalla; lo importante es que las distintas funciones quedan conectadas. Cuando el vendedor registra un pedido, el sistema guarda la venta, descuenta los productos del inventario, actualiza el historial del cliente y alimenta los reportes. Si después de esa operación un producto queda por debajo de su stock mínimo, se genera una alerta.

Esto resuelve el problema porque evita tener que actualizar manualmente varios archivos o planillas después de cada venta. Además, se reduce el riesgo de que un registro diga una cosa y otro registro diga algo diferente. La gerencia puede consultar las ventas, los productos más vendidos, los pedidos pendientes y los niveles de stock desde un mismo lugar.

Por ejemplo, si se venden cinco unidades de un producto que tenía ocho, el stock pasa a tres. Si el mínimo era quince, el sistema lo marca automáticamente como “Bajo”. Esa información ayuda al responsable de importaciones a decidir qué producto reponer.

Idea clave: La solución aporta integración, automatización y trazabilidad. Una venta deja de ser un dato aislado y afecta automáticamente a todos los registros relacionados.

Tipo de Sistema, Personas, Procesos y Tecnologías

El prototipo es principalmente un sistema de gestión comercial e inventario. Tiene características de un TPS (Transaction Processing System) porque registra operaciones cotidianas, como clientes, productos, pedidos, cantidades y ventas. También tiene características de un sistema de información gerencial, porque procesa esos datos y los presenta como reportes, indicadores y gráficos que sirven para tomar decisiones.

No lo definiría como un ERP completo, porque no incluye todas las áreas de la empresa, como recursos humanos, contabilidad, proveedores o liquidación de sueldos. Sin embargo, sí tiene una lógica integrada y podría ampliarse en el futuro o conectarse con un ERP.

• Dimensión Personas: Participan vendedores, responsables del depósito o stock, encargado de importaciones y gerencia.
• Dimensión Procesos: Aparecen el registro de clientes, la venta, la actualización del stock, la generación de alertas y la planificación de reposiciones.
• Dimensión Tecnologías: Sería necesaria una aplicación web, una base de datos centralizada, usuarios con permisos y herramientas de reportes.

Stock, Alertas, Pedidos y Reglas del Sistema

Cada producto tiene un stock actual y un stock mínimo. El actual muestra cuántas unidades existen, mientras que el mínimo representa el nivel por debajo del cual la empresa debería comenzar a planificar una reposición. Cuando el stock actual queda por debajo del mínimo, el sistema genera una alerta y muestra el producto como “Bajo”. La secuencia es: se registra una venta, se descuenta el stock, el sistema compara el nuevo valor con el mínimo y, si corresponde, genera la alerta. Luego el responsable analiza esa información y decide si es necesario realizar una importación. El sistema no toma por sí solo la decisión final, sino que proporciona información para apoyarla.

El stock mínimo no debería definirse igual para todos los productos. Podría depender de las ventas históricas, el tiempo que demora una importación, la estacionalidad y la importancia del producto. En una versión más avanzada, estos datos podrían calcularse automáticamente.

Antes de guardar un pedido, el sistema también debería validar que exista stock suficiente. Si no lo hace, podría permitir cantidades negativas o confirmar una venta imposible de cumplir.

Requerimientos, Indicadores y Datos para Decidir

Los requerimientos funcionales indican qué tiene que hacer el sistema. En este caso: permitir registrar clientes y productos, crear pedidos, calcular subtotales y totales, comprobar disponibilidad, descontar stock, generar alertas, guardar el historial del cliente y producir reportes por período.

Los requerimientos no funcionales indican cómo debe funcionar. Por ejemplo: la aplicación debe ser fácil de usar, rápida, segura, mantener respaldos y restringir funciones según el usuario. También debería conservar trazabilidad, es decir, registrar quién realizó una venta o modificó un producto.

Los reportes transforman datos aislados en información. Las ventas totales muestran los ingresos comerciales del período; el ticket promedio se obtiene dividiendo las ventas entre la cantidad de pedidos; los productos más vendidos ayudan a priorizar importaciones; y las ventas por departamento permiten conocer dónde se concentra la demanda.

Un KPI no es simplemente cualquier número; tiene que relacionarse con un objetivo. Por ejemplo, si el objetivo es mejorar la disponibilidad, un KPI podría ser el porcentaje de pedidos entregados sin faltantes. La alerta de stock, en cambio, es un aviso puntual y no necesariamente un KPI.

Mock-up, Implementación, Riesgos y Costos

El prototipo presentado es un mock-up, no un sistema terminado. Sirve para mostrar las pantallas, la navegación y el comportamiento esperado antes de invertir en el desarrollo completo. Es útil porque permite validar con los usuarios si las funciones propuestas realmente solucionan el problema y hacer cambios con un costo mucho menor.

Para implementarlo habría que desarrollar la aplicación y la base de datos, migrar los registros actuales, configurar usuarios y permisos, probar las funciones y capacitar a los empleados. También se debería definir cómo se manejarán anulaciones, devoluciones, modificaciones de stock y respaldos.

Entre los riesgos están la resistencia de los empleados, la carga incorrecta de datos, la pérdida de información, permisos excesivos y que algunos trabajadores continúen utilizando planillas paralelas. Para reducirlos se necesitarían capacitación, pruebas con usuarios, respaldos, controles de acceso y una implementación gradual.

El costo total de propiedad (TCO) no incluye solamente desarrollar o comprar el sistema. También abarca alojamiento, licencias, soporte, mantenimiento, actualizaciones, capacitación, seguridad y tiempo de adaptación de los empleados.

Ficha del Proceso, Actores, Entradas, Actividades y Salidas

El proceso principal sobre el que trabajamos es la gestión de ventas y pedidos, relacionado directamente con el control de inventario. Su objetivo es registrar correctamente la venta al cliente, verificar que exista mercadería disponible y mantener actualizada toda la información comercial. El dueño del proceso podría ser el responsable comercial, aunque en la parte de inventario también participa el encargado de depósito o importaciones.

El proceso comienza cuando un cliente solicita determinados productos. Las entradas serían los datos del cliente, los productos solicitados, las cantidades, los precios, la condición de pago y el stock disponible. Las actividades principales son seleccionar al cliente, agregar los productos, comprobar las existencias, calcular el total, confirmar el pedido y actualizar los registros relacionados. Las salidas serían el pedido registrado, el stock actualizado, el historial de compra del cliente, la posible alerta de stock bajo y la nueva información incorporada a los reportes.

Los actores principales son:

• Vendedor: registra la operación.
• Responsable de stock: controla existencias.
• Encargado de importaciones: utiliza las alertas para planificar compras.
• Gerencia: consulta los reportes.
• Cliente: recibe el resultado del proceso (el pedido correctamente preparado y entregado).

Caso de uso básico: el vendedor ingresa a “Nuevo pedido”, selecciona al cliente, agrega productos y cantidades, y el sistema verifica la disponibilidad. Si hay stock, calcula el total y guarda el pedido. Si no hay suficiente, debería impedir la confirmación o mostrar una advertencia. Al confirmar, actualiza automáticamente el stock, el historial del cliente y los indicadores.

Alternativas, Elección de la Solución e Integración Futura

Antes de elegir el prototipo podían considerarse distintas alternativas:

1. Continuar usando planillas: pero mejor organizadas y compartidas. Sería económica y fácil de implementar, aunque seguiría dependiendo mucho de cargas manuales, tendría riesgos de errores y no integraría completamente las operaciones.
2. Comprar un sistema existente: como un software de gestión comercial o un ERP. La ventaja es que tendría funciones ya desarrolladas, soporte y mayor experiencia de uso. Como desventaja, podría ser más costoso, incluir herramientas que InfraImport no necesita o no adaptarse bien a características específicas de sus productos, como series, colores, perfiles y procesos de importación.
3. Desarrollar una solución diseñada a medida (prototipo): pensada para las necesidades concretas de InfraImport. Se eligió porque permite mostrar exactamente cómo deberían conectarse clientes, pedidos, stock, alertas y reportes. No significa que necesariamente haya que programarla desde cero: el mock-up también podría utilizarse para comparar sistemas existentes y seleccionar el que más se acerque a los requerimientos.

En una implementación real, el sistema debería integrarse con las herramientas que ya utilice la empresa. Por ejemplo, podría enviar la información de ventas a un sistema contable, recibir datos de productos o importaciones y conectarse con la facturación electrónica. La integración evita volver a cargar la misma información y reduce inconsistencias.

También habría que definir una migración inicial de datos: revisar clientes, productos, precios y existencias antes de cargarlos al sistema. Si se ingresan datos incorrectos, aunque el software funcione bien, los reportes y las decisiones también serían incorrectos. Por eso primero se deberían limpiar y validar los registros existentes.