|
|
|
Lo que entregamos · No. 04 · 17 al 21 de agosto 2026
Lo que estaba
en el papel
y en el código.
Dos cosas salieron de donde no correspondía. Del papel: las confirmaciones de PI ahora se cargan también en PDF —incluso escaneado— y el sistema verifica la aritmética del propio documento antes de aceptarlo, así que una PI escaneada dejó de transcribirse a mano.
Del código: las reglas de comisiones que solo un desarrollador podía cambiar —los esquemas, la tasa de un reemplazo, la equivalencia entre cargos— pasaron a administrarse desde Nexum por el área que las define.
Además el Forecast reemplaza el Presupuesto OPex con los ahorros definidos y está disponible en las apps del ecosistema, Gate se hizo dueño de los traslados y reemplazos con toda la historia del sistema anterior, y seis reportes de tienda ya viven fuera de Qlik.
|
📄 Cuarta edición · Newsletter interno Badamax Tech
|
|
|
|
930 mil
Clientes segmentados en el
nuevo modelo por marca
|
|
|
3.664
Movimientos de personal
migrados a Gate desde 2023
|
|
|
−$2,4 MM
Menos gasto mensual en reemplazos
con la regla acordada (−32%)
|
|
|
|
|
5 → 2
Esquemas de comisión, sin
mover el pago de nadie
|
|
|
46%
Avance del Despacho Desde
Tienda: 34 de 73 locales
|
|
|
6
Reportes de tienda ya
construidos fuera de Qlik
|
|
|
|
|
Palabras de apertura
Las reglas del negocio las administra el negocio.
Mauricio Álvarez
Chief Digital Officer
Badamax
|
"Una regla de negocio escrita en el código es una regla que el negocio no controla: cada ajuste depende de que alguien de Tecnología esté disponible. Esta semana la tasa de un reemplazo, la equivalencia entre cargos y los esquemas de comisión pasaron a una pantalla que administra Remuneraciones. Ese es el estándar: nosotros construimos el mecanismo, el área dueña define los parámetros y queda registro de quién cambió qué. Lo mismo con los documentos — mientras una PI se transcribe a mano, el dato depende de quien la tipeó."
|
|
|
|
En este número
Dieciocho frentes de trabajo.
|
01 Atelier · Confirmaciones de PI
02 Atelier · Retroplanning
03 Atelier · Compras y proveedores
04 Helix · Planificación y OTB
05 Helix · Wholesale (B2B)
06 Nexum · Comisiones de venta
07 Nexum · Notas de crédito
08 Nexum · Disponibilidad del servicio
09 Transversal · Presupuesto y Forecast
|
10 Gate · Operación de tienda
11 Gate y Helix · Gestión de Personas
12 Hangar · Ticketera de mantención
13 CockpIT · Roadmap y recepciones
14 Reportería de tiendas y comercial
15 Flare · Marketing
16 Beaver · Directorio Ejecutivo
17 Plataforma de datos y seguridad
18 Proyectos e iniciativas
|
|
|
|
📄
|
No. 01 · Atelier · Confirmaciones de PI
Una PI escaneada ya no se transcribe a mano.
|
El módulo pasó a aceptar los tres formatos en que realmente llega una PI: Excel, PDF con texto y PDF escaneado. En los dos primeros la lectura es exacta; en un escaneo la hace un modelo de visión. De paso se extraen las cláusulas del bloque VERY IMPORTANT, que antes quedaban fuera del sistema.
| El documento se verifica a sí mismo |
| Una PI trae la misma información dos veces: unidades × FOB debe dar el total de cada línea, y las líneas deben sumar los totales que el documento declara aparte. Esa redundancia lo convierte en verificador de nuestra propia lectura: si algo no cuadra, la pantalla bloquea el guardado y señala exactamente qué línea falla. |
| La distinción importa: si el origen es un PDF, el valor se corrige ahí mismo —el error puede estar en nuestra lectura, no en el papel—; si es un Excel, el descuadre es del proveedor y queda como advertencia. |
| Trazabilidad del documento |
| Comentarios por versión, no por PI: una observación sobre 24.500 unidades pierde sentido cuando una revisión posterior las baja a 19.600. Los hilos de versiones superadas quedan de solo lectura, y los comentarios se editan —nunca se borran— con registro de autor, hora y última edición. |
| Cierre con candado: una PI cerrada no admite versiones nuevas ni eliminación; reabrirla es una acción explícita que queda registrada con su autor. Comentar sigue habilitado, porque lo que aparece después del cierre es justamente lo que conviene anotar. La restricción se aplica en el servidor, así que también rige para quien llegue por un enlace directo. |
| Cronología completa: quién la cargó y cuándo, cada versión con sus cambios, cada comentario y cada edición, cada cierre y reapertura — incluidos los ciclos repetidos, que la ficha por sí sola no puede mostrar porque conserva solo el último estado. |
| Registro de correcciones manuales: queda asentado qué campos escribió una persona al revisar y qué venía del documento del proveedor. Sobre un documento bancario esa distinción es información en sí misma; antes solo quedaba el resultado final, sin saber si un valor lo dijo el papel o lo tipeó alguien. |
| Generación de la PI en el formato Excel de Badamax, armada desde los datos guardados con las correcciones incorporadas e identificada como documento derivado. Resuelve un caso que no tenía salida: las PIs que llegaban en PDF no tenían Excel que descargar. |
| Listado organizado por colección, porque se compra por colección y no por documento suelto: se recorre por marca y temporada, y cada nivel muestra sus cifras —cantidad de PIs, unidades y monto—. Dentro hay filtros por proveedor, familia y estado, y los indicadores responden a los filtros, así que la misma pantalla contesta cuánto se le está comprando a un proveedor o cuánto pesa una temporada. |
| Progreso real mientras se lee el archivo: un PDF escaneado tarda unos 30 segundos, así que la pantalla muestra el nombre y peso del archivo, lo efectivamente subido y el tiempo transcurrido contra el estimado. Se distingue una espera normal de un proceso detenido. |
|
|
|
🗓️
|
No. 02 · Atelier · Retroplanning
Ahora la malla se puede cargar de verdad.
|
El módulo estaba publicado, pero fuera de un administrador ninguna celda era editable y la pantalla no explicaba por qué: una celda solo la escribe el área dueña del hito, esa pertenencia vive en una tabla que nace vacía, y no existía pantalla para poblarla.
| Se agregó la pantalla de áreas y responsables, y cuando una celda está bloqueada el sistema dice el motivo: no es tu área, el hito no tiene área responsable, o no integras ninguna. Son tres causas con tres soluciones distintas. |
| El ciclo de hitos pasó de la ruta a la temporada. Antes armar una temporada obligaba a marcar los mismos 24 hitos una vez por ruta; en la data real las tres rutas de W27 coinciden exacto en hito, orden y plazo. El ciclo compra-diseño es de la temporada y lo de la ruta es la excepción: ahora se define una vez y la ruta declara solo en qué se aparta. |
| El alta de entrada pasó de seis campos a tres: entrada y ventana de SAP eran el mismo dato con dos nombres, y el campo de texto libre donde convivían pirámides con incoterms se reemplazó por la pirámide del artículo, que ya tiene catálogo propio en Diseño. |
| Tres correcciones que costaban trabajo real: el semáforo calculaba "hoy" en otra zona horaria, así que cada noche las celdas del día pasaban a ATRASADO tres o cuatro horas antes y el indicador subía solo; un guardado que solo reordenaba columnas dejaba todos los hitos sin área dueña y, como un hito sin dueña se bloquea por seguridad, las cuatro áreas perdían la edición de la malla completa en silencio; y los diálogos de borrado podían decir "se pierden 0 fechas" mientras destruían cumplimientos ya registrados. Además el nombre de la ruta y el encabezado acompañan el scroll, y guardar una fecha ya no mueve la grilla. |
|
|
|
🧾
|
No. 03 · Atelier · Compras y proveedores
Crear OC dejó de nacer deshabilitado.
|
| Nadie podía emitir una orden de compra desde Atelier: el botón nacía deshabilitado y parecía un problema de permisos, pero faltaba la conexión que identifica al comprador contra SAP. Se habilitó esa y otras cuatro que degradaban en silencio: desglose del gastado, cuentas sin presupuesto, editar borrador y duplicar OC. |
| Mantenedor de proveedores listo para revisión: alta y edición desde Compras, con la razón social y el correo ocultos para quien no tiene el permiso — se ve solo el alias público. Es la misma regla que ya aplica el módulo de cotizaciones. |
|
|
|
🎯
|
No. 04 · Helix · Planificación
Un OTB para una compra parcial.
|
Hasta ahora un OTB se armaba sobre la familia-temporada completa. La nueva "OTB por muestra" permite acotarlo a artículos elegidos a mano, que es como se hace una compra parcial.
| Tablero visual por temporadas que relaciona solo el mismo diseño entre una temporada y otra, mostrando con flechas qué continúa y con espacios vacíos qué falta. |
| El plan se genera corriendo el algoritmo de distribución solo sobre esos artículos, con opciones de editar la muestra y recalcular, y guardado automático del borrador. |
| La aprobación de compra internacional quedó operativa en producción. La sección se había publicado la semana anterior pero estaba caída: faltaba cargar la tabla de aprobadores, las acciones no llevaban el token de seguridad y la conexión con Atelier no estaba declarada. Resuelto. También dejó de filtrar por temporada al comparar contra el histórico. |
|
|
|
📦
|
No. 05 · Helix · Wholesale (B2B)
No se mueve el stock que ya está comprometido.
|
| En las transferencias entre el centro de distribución y la bodega de venta, parte del stock puede estar comprometido y no debe poder moverse: la creación ahora valida contra el disponible real de SAP. |
| La vista mostraba solo las transferencias originadas en Helix; ahora se ven también las hechas directamente en SAP, con un distintivo de origen y en modo lectura, porque en esas no hay nada que reenviar. |
| En órdenes se agregó la columna Tipo de cliente (multitienda / multimarca) y la opción "Generar OC para el cliente" para los multimarca, que entrega una orden precargada para que el cliente la confirme y la devuelva. Resuelve el caso de los clientes que no emiten OC. |
| El robot que carga venta y stock de Ripley y Cencosud/Paris quedó al día en las cuatro combinaciones, y se corrigió una falla que lo mataba al escribir su propio registro. Está listo el paquete para dejarlo corriendo en un servidor; falta decidir dónde alojarlo, y mientras corra a mano cada día sin ejecutar es una foto de stock que se pierde para siempre. |
|
|
|
💳
|
No. 06 · Nexum · Comisiones de venta
Las reglas salieron del código a una pantalla.
|
| Los cinco esquemas de comisión pasaron a dos —"Antiguos" y "Cargos Nuevos"— sin que nadie cambie de pago: verificado peso a peso contra junio y julio, $0 de diferencia, nadie entra ni sale. |
| La tasa y la base con que se paga un reemplazo se administran desde Nexum (tres reglas: Vendedor Senior, Subjefe y Jefe de Tienda). Con la regla acordada con el negocio para jefatura, el gasto de reemplazos medido sobre julio baja $2,4 MM al mes, un 32%. |
| Pantalla nueva de Homologación de Cargos para Remuneraciones: qué cargo equivale a qué, quién recibe meta y quién cobra comisión, con historial de cambios y aviso de los cargos de BUK que el maestro todavía no cubre. Antes esto vivía en el código. |
| Se corrigió que el componente por local se pagara el mes completo aunque la persona entrara a mitad de mes, el desempate cuando dos personas ejercen jefatura en la misma tienda, y que los trainees queden igual que el cargo que están ejerciendo. |
|
Hallazgo con plata · Requiere definición
Un traslado mal cargado —una jefatura con la misma tienda de origen y de destino— hacía que una tienda pagara su venta total dos veces: $1,23 MM de más entre junio y agosto, el 91% concentrado en un solo local. Ya hay un control que lo detecta y la fila se corrigió, verificado con dato.
Con un matiz que hay que decidir: corregir el dato sube el gasto en unos $937 mil, porque a la misma persona se le estaba anulando la comisión de su tienda real. Quedan cuatro definiciones del área, incluida si se reliquida junio y julio.
|
|
|
|
🏦
|
No. 07 · Nexum · Notas de crédito
El reporte por tienda y semana, liberado.
|
| El reporte de notas de crédito por tienda y semana —con motivo, monto y cantidad— quedó en producción y entregado al usuario final. La edición anterior lo reportaba cuadrado pero sin pantalla; ya está disponible y esperando su feedback. |
| Se corrigió el filtro de motivo, que se partía en la coma y dejaba fuera el 36% del dato — un motivo con coma en el texto simplemente no se encontraba. |
|
|
|
🔌
|
No. 08 · Nexum · Disponibilidad del servicio
Un módulo nuevo no puede tumbar Finanzas entera.
|
| El lunes el servicio de finanzas quedó reiniciándose en loop y todas las apps que dependen de él dejaron de responder. El despliegue había quedado marcado como exitoso, porque el proceso levanta el contenedor y no verifica nada después. |
| La causa era una cadena de cinco pasos: sin cierta configuración declarada, el módulo de Recepción de facturas quedaba apuntando a sus conectores de prueba, esos conectores se niegan a funcionar en producción, y como el módulo se cargaba sin condición, el arranque del servicio completo se caía con él. |
| La corrección respeta el principio y acota el daño: el resguardo se mantiene —no se emite una recepción contra un documento inventado— pero ahora la consecuencia es que Recepción no sirve dato, en vez de llevarse puesto el resto de Finanzas. Se agregó la prueba que lo habría mostrado antes de desplegar. |
|
|
|
📐
|
No. 09 · Transversal · 7 apps del ecosistema
El Forecast reemplaza al Presupuesto OPex.
|
La compra se decidía contra el presupuesto OPex original. El Forecast es la cifra que lo reemplaza, ya con los ahorros definidos incorporados: ya existía —mismo archivo, misma carpeta— y se veía en el directorio, pero ninguna app podía consultarlo al momento de gastar.
| Ahora el panel donde se decide cuánto se puede gastar muestra las dos cifras, y el Disponible se calcula contra el forecast cuando el año lo tiene cargado. El panel de crear la OC y el de aprobarla cambian juntos: crear contra el forecast y aprobar contra el plan sería peor que no tener forecast. |
| Pestañas Presupuesto Original / Forecast en el módulo de Presupuesto, con la vista compartible por enlace. El selector de años funciona en ambas y avisa cuando el año elegido no tiene forecast — antes, al entrar a un año sin forecast, el usuario quedaba encerrado sin selector para salir. |
| Se corrigió el alcance: el indicador que decide qué referencia usar preguntaba por el año completo y, como el forecast se carga por gerencia, declaraba sobregirada a una gerencia entera contra un presupuesto que no existía. |
| Desplegado en 7 de las 8 apps: Hangar, CockpIT, Atelier, Helix, Crew, Runway y Flare adoptaron el mismo componente compartido, eliminando el código duplicado que cada una mantenía por su cuenta. Nexum queda fuera a propósito, porque su módulo de presupuesto tiene piezas propias y requiere portarlo aparte. |
|
⚠️ Aviso a usuarios de CockpIT
Al crear una OC, esta app armaba su propia consulta de presupuesto y perdía el filtro de gerencia y de código de gasto, así que la fila sumaba todas las gerencias: un código mostraba $4.346 millones cuando el de la gerencia mayor es $2.804 millones. Se estaban aprobando compras contra un presupuesto que no existía. La corrección baja los montos visibles: es la cifra correcta, pero se lee como un recorte, así que conviene comunicarlo.
|
|
|
|
🏬
|
No. 10 · Gate · Operación de tienda
No se devuelve stock que nunca salió.
|
| Notas de crédito y stock de tienda |
| En tienda un retiro descuenta stock al prepararse, y la nota de crédito lo devuelve. Pero se podía emitir una NC de un pedido que nunca se preparó: como no hubo descuento previo, la NC ingresaba inventario que jamás salió y lo inflaba. Bloqueado, y el bloqueo vive en el sistema que tiene la última palabra, no solo en la pantalla. |
| La regla se afinó al criterio real: lo que importa no es que sea un retiro, sino si el stock salió. Sobre las 12.025 referencias de retiro en producción quedan habilitados los entregados (93,6%) y los listos para entrega (1,5%), y siguen bloqueados los 42 sin preparar. |
| Doble reposición al devolver en otra tienda: un retiro entregado en Parque Arauco y devuelto seis días después en Alto Las Condes reponía el stock dos veces —una por la NC y otra por el comprobante de reingreso—. Ahora ese comprobante se emite solo si la NC no repuso stock en una tienda. |
| Un pedido con despacho desde tienda, cancelado por prenda fallada antes de prepararse, registraba la NC de anulación pero no la rebaja, y quedaba un faltante en el inventario del local. Corregido. |
| Quien reemplaza una jefatura durante parte del mes tiene dos mediciones —los días como jefe contra el resultado de la tienda, el resto contra su meta propia— y el reporte mostraba solo una al mirar el mes completo. Afectaba a 13 personas en agosto ($58,5 MM de venta y $128,6 MM de meta que no se veían) y a 31 en julio. Lo reclamó por escrito una subjefa. Corregido y verificado en pantalla con la usuaria. |
| Cuando se cortaba la conexión con la cola de mensajes, se caía el servicio completo —reportes, punto de venta, documentos tributarios y gestión de personas— con un síntoma engañoso: parecía que "se cayó el sistema" y en realidad se había desconectado un componente. Corregido con pruebas de regresión; el mensaje no se pierde, se reentrega al reconectar. |
| La reposición automática se colgaba en producción porque equipos de desarrollo se conectaban a la misma cola compartida y se llevaban los trabajos. Se puso un candado para que solo producción procese esa cola, verificado en el servidor de mensajes. |
|
|
|
🧑💼
|
No. 11 · Gate y Helix · Gestión de Personas
Tres años de historia, en el sistema nuevo.
|
| Se migraron los 3.664 movimientos históricos —3.269 reemplazos y 395 traslados desde enero de 2023— desde el sistema antiguo. Quedan junto a las solicitudes nuevas con un distintivo de "histórico", suman en los indicadores y participan en la detección de conflictos al crear una solicitud. Con eso se retiró la pantalla que leía en vivo del sistema legacy. En la migración apareció que el nombre de un campo estaba invertido en el origen: el "reemplazo" era en realidad el titular cuyo puesto se cubre. |
| Gate ya aplica los movimientos por su cuenta en los sistemas de tienda y de asistencia, sin depender del servicio antiguo, y reintenta cada hora solo lo que quedó fallido. Ese reintento cubre el caso típico: el sistema de tienda salió bien y la persona ya opera en su local nuevo, pero la sincronización de asistencia no — sin el reintento ese desfase quedaba para siempre. Todo en modo simulación hasta definir la fecha de corte. |
| La llave que habilita la escritura y los horarios se manejan desde la misma pantalla, con el mismo control y el mismo vocabulario que las transferencias de inventario. Antes esa llave vivía en la configuración del servidor, así que activarla para el corte exigía un despliegue. |
| Reglas ajustadas con el negocio: el reemplazo es siempre dentro de la misma tienda y quien cubre se elige entre los colaboradores de ese local, forzado en el servidor. El supervisor puede cancelar una solicitud ya aprobada con motivo obligatorio, y si ya estaba aplicada la pantalla advierte que cancelarla revierte los sistemas de tienda y asistencia, nombrando el local al que vuelve la persona. |
| El módulo se montó también en Helix, dentro del grupo Retail, porque es donde los supervisores aprueban. Es la misma aplicación consumiendo el mismo servicio —sin construir nada nuevo por detrás—, con su propia sección de permisos administrable desde CockpIT. |
|
Conviene tener presente
El cambio de cargo pasó a llevar rango de fechas. Al tener fecha de término entra en el proceso de restauración igual que los traslados y reemplazos, así que deja de ser permanente.
|
|
|
|
🔧
|
No. 12 · Hangar · Ticketera de mantención
Ahora se sabe de qué tienda viene cada ticket.
|
Las órdenes de mantención no decían de qué local venían. Y como 241 de 242 tickets llegan por correo y no por la aplicación, la atribución no podía pedírsele al usuario: había que resolverla del lado del sistema.
| Atribución automática cruzando el correo del solicitante contra el maestro de tiendas. Sobre los 242 tickets reales: 191 quedaron atribuidos a 58 tiendas. Los 51 restantes son casillas corporativas —Casa Matriz, centro de distribución, oficinas— que legítimamente no tienen tienda. |
| Asignación manual para lo que el correo nunca puede resolver: 11 tickets de tienda reportados desde casillas corporativas que nombran el mall en el texto, y las 23 tiendas que no tienen correo de jefatura registrado. Lo que asigna una persona nunca se sobrescribe con lo automático. |
| Filtro cadena → tienda con buscador, multiselección y conteos, igual en tablero, lista y archivadas. Jerárquico porque con 58 tiendas una lista plana sería inusable, y porque la cadena funciona como atajo: un clic equivale a sus 49 locales. La selección viaja en la dirección, así que el enlace filtrado se puede compartir. El código de tienda quedó visible y ordenable, porque filtrar por cadena sin ver de qué local es cada ticket habría sido un filtro ciego. |
| Sincronización diaria del maestro de tiendas con re-atribución: cuando el maestro cargue el correo de una tienda que no lo tenía, sus tickets antiguos se atribuyen retroactivamente. Protegida contra vaciados o caídas del origen. |
| La consulta entre sistemas entrega el mínimo necesario: sin RUT, teléfono, geolocalización ni código tributario — quien solo necesita resolver correo → tienda no tiene por qué recibir datos personales de la jefatura. Y la librería común de ticketera quedó extensible, para que cada app muestre sus propios campos sin contaminar el tablero de las otras (un código de tienda no significa nada en la ticketera de Personas o de TI). |
|
|
|
🛠️
|
No. 13 · CockpIT · Tecnología
Un backlog que se puede tomar sin preguntar.
|
| Se habilitó la asignación de responsable en el roadmap, que obligaba a abrir cada ítem a mano para saber de quién era. Con eso el backlog se asigna y se audita por persona, y quedó viable la revisión de fondo. |
| Revisión de completitud de 120 ítems: 47% estaba sin estimación, 38% sin refinar y solo 29% listo para tomar, con gerencias enteras en cero. Quedó en cero sin estimación y dos sin refinar. |
| 27 solicitudes nuevas levantadas y derivadas, todas con contexto, problema, causa raíz cuando es una falla y criterios de aceptación verificables, de modo que se puedan tomar sin volver a preguntar. La familia más pesada sigue siendo notas de crédito y stock en tienda; después vienen Atelier, Helix/Wholesale y finanzas. |
| Dos con impacto directo de negocio: un reporte de cobertura de promotores wholesale por corner —levantado porque un punto en Paris estuvo 14 días sin cobertura y nos enteramos por el reclamo del cliente; hoy una licencia no dispara ningún aviso y el seguimiento se hace en un Excel manual— y un comparativo entre lo que se envía a la plataforma de fidelización y la venta real de la compañía, porque las vistas que alimentan ese envío no cuadran. |
| Cinco entregas del equipo validadas y cerradas, entre ellas que las 528 guías "no vinculadas" del reporte de recepción eran falsos positivos, dos notas de crédito que quedaron con un motivo que sí permite pagarlas, y la orden precargada para clientes multimarca. |
| Recepción de guías · SAP vs RetailPro |
| El reporte mostraba unas 528 recepciones como "no vinculadas". El primer intento de arreglo —cruzar por el folio de la guía— rompió el reporte: de 2.201 recepciones cuadradas pasó a 0, y se revirtió el mismo día. La causa real es que el sistema de tienda reasigna el número de aviso, así que el número original de SAP queda en otro campo; ahora se cruza por ahí, con dos alternativas en cadena y considerando el tiempo entre emisión y recepción. |
| Verificado punta a punta, la palanca real era la frescura del dato: los dos caminos de cruce ya funcionaban y las "no vinculadas" eran guías que todavía no habían llegado. La sincronización pasó a correr cada 3 horas. |
|
|
|
📊
|
No. 14 · Reportería de tiendas y comercial
Seis reportes de tienda, ya fuera de Qlik.
|
| Salida de Qlik · Reportes de tienda |
| Los 6 reportes de tienda ya tienen su información construida en el repositorio de datos y encadenada: se refresca sola cada 30 minutos. Cuadratura contra lo que se ve hoy: venta +0,000%, meta por tienda +0,00002%, meta por vendedor ±0,15% en los meses cerrados. Se armó además un ambiente de revisión para mirarlos sin tocar los de producción. |
| En el camino se encontró que el reporte por hora perdía el 31% del tráfico —una hora con visitas pero sin boleta simplemente desaparecía—, lo que inflaba la conversión en un 47%. Corregido. El tráfico de los días con el contador caído ahora se estima y queda marcado como estimado, en vez de aparecer en cero. |
| El ranking de vendedores llevaba respondiendo error desde el 30 de julio en el canal nuevo, sin que nadie lo notara. Corregido. |
| En la aplicación de Despachos la columna Unidades salía en 0: el bloque que las calcula se había perdido en una reescritura de julio. Repuesto y recargada la historia desde junio. No fallaba — mostraba cero, que es peor. |
| El costo FOB de compra estaba congelado desde el 3 de marzo —cinco meses y medio— y la aplicación recargaba exitosa todos los días. Corregido: 6.654 artículo-colores al día. El costo FOB y la pirámide de mix pasaron a cargarse automáticamente desde SAP y quedan en el maestro de artículos; antes salían de una planilla. |
| El filtro "Gerencia Contable" del EERR estaba mudo desde siempre: miraba las marcas en lugar de las gerencias. Corregido y ya visible, con sus 13 gerencias. |
| En la evaluación de llevar Comercial a la nube, en laboratorio la aplicación pasó de 5,2 a 1,3 GB de memoria (−75%) sacando 65 dimensiones calculadas. El cambio equivalente sobre la app de producción queda por verificar. |
| Hallazgo pendiente de resolver: la venta expresada en pesos de hoy cambia según cómo se elija la fecha (rango contra botón del año), porque el factor de reajuste se ancla al mes de la fecha máxima seleccionada. |
|
|
|
🎯
|
No. 15 · Flare · Marketing
930 mil clientes, segmentados por marca.
|
| En producción el nuevo modelo de segmentación por marca: 18 segmentos que cruzan valor, recencia y frecuencia, sobre 930 mil clientes, con descarga de listas para campaña. Reemplaza el modelo anterior de 11 segmentos y se actualiza solo todas las noches. |
| Se corrigieron tres defectos que ensuciaban las listas: RUT de empresa que entraban como personas (261 casos, $49,8 MM), 7.610 clientes que desaparecían del universo por un filtro de razón social —entre ellos 37 personas, 14 de ellas llamadas Saúl— y 1.017 correos válidos que quedaban apagados. |
|
|
|
🧭
|
No. 16 · Beaver · Directorio Ejecutivo
El EERR, listo y esperando accesos.
|
| La productividad por área quedó consolidada mes a mes con 32 meses de historia, y la tabla del EERR con sus 27 medidas escrita, conectada y validada. Lo que falta son accesos —un usuario de lectura y una regla de red—, no desarrollo. |
| Hallazgo a tiempo: la tabla iba a nacer en una aplicación del EERR que nadie recarga y nadie mira. Se corrigió el destino antes de publicarla. |
|
|
|
🗄️
|
No. 17 · Plataforma de datos y seguridad
Una alarma que mira el dato, no el proceso.
|
| Alarma nueva de frescura del dato — la tercera, y la única que mira el dato en vez de los procesos. Caza exactamente el caso "todo corrió, todo verde, y el dato es de anteayer", que es el modo de falla de los dos incidentes del mes pasado. El calendario de días hábiles se deriva del propio dato; en la prueba sobre 2026, logística pasa de 29 días en rojo a 3. |
| La copia de respaldo en la nube tenía 11 conjuntos de datos con 7 noches sin poder limpiarse —16.752 archivos, 3,1 GB— y siempre en verde. Ahora la limpieza grande se autoriza con una llave que hay que tipear a mano y que nunca puede quedar puesta en la automatización, porque su modo de falla es vaciar el respaldo. |
| Dos procesos nocturnos cayeron tres noches seguidas por una regresión de la semana anterior; corregido el mismo día en que se detectó, y con eso volvió el reporte de notas de crédito. También se cerró un control de seguridad sobre las llaves que permiten borrar historia, que estaba dando verde sin mirar nada. |
| Se construyó una sola puerta para publicar archivos, primer paso del cambio de fondo que permite subir el repositorio a la nube, ya en producción con su control de cuadratura. Y con el ordenamiento de los archivos temporales el repositorio bajó de 25,4 a 23 GB. |
| Se diagnosticó la consulta por una tienda sin tráfico: el sensor dejó de enviar y el dato no existe en el origen. En el camino aparecieron otras tres tiendas cortadas. Es del proveedor. |
| Hallazgo estructural: el monitoreo del proveedor cubre 19 de unos 75 contadores, y ninguno del tipo que se cortó, así que esos cortes no disparan ninguna alarma. Se pidió incluirlos. |
| Quedó medido que entre septiembre de 2024 y enero de 2025 hubo un corte de 147 días en 43 de 71 locales: el 49% del tráfico de esa ventana es estimado. Dicho de otro modo, ninguna comparación año contra año de tráfico de septiembre a diciembre de 2024 es dato medido. |
| Se corrigió que el catálogo de pantallas de Gate no se cargara nunca: había pantallas que no se podían otorgar a nadie que no fuera administrador, y el administrador no las veía para poder darlas. |
| Hallazgo de seguridad: el usuario con que el repositorio de datos lee las bases tiene lectura sobre todas las tablas de 24 bases, incluidas las de sesión del directorio. Es preexistente, no algo que se haya introducido ahora; se pidió acotarlo. |
|
Migración a la nube · Definición pendiente
Se entregó el estado del plan medido bloque por bloque, con las decisiones que quedan del lado de infraestructura. La más urgente sigue siendo la definición sobre datos personales —RUT y correo— antes de exponer esas tablas a la nube.
|
|
|
|
🛒
|
No. 18 · Proyectos e iniciativas
Seis iniciativas de ecommerce en curso.
|
| Productos similares en New Man: quedaron configuradas las relaciones de color de 132 familias de estilo del catálogo S26, para que el cliente vea el mismo producto en sus otros colores. |
| Promociones "Comprar Juntos" en Ferouch: 18 combos activados —camisa más pantalón— con cobertura de 633 combinaciones válidas de producto. |
| Despacho Desde Tienda Express · 46%. El Release 3 quedó completo: 34 de 73 tiendas activas. |
| Integración con Falabella para Ferouch: el piloto de Costanera Center tiene un espacio de bodega activo. La ruta crítica sigue siendo que Falabella active el servicio, y el plazo que manda es el congelamiento de Cyber. Faltan dos bodegas por habilitar. |
| Migración de la tienda a Shopify · 12% de la carta Gantt, con lanzamiento planificado para noviembre. Los temas de cada marca están confirmados y los diseños recién arrancan. Pendiente la documentación de integración y la coordinación con la plataforma de marketplaces. |
| Promesas de entrega · contingencia zona norte: ajustes diarios por restricciones climáticas. Hoy cinco comunas mantienen un día adicional de plazo (Diego de Almagro, Taltal, Tocopilla, Alto del Carmen y Antofagasta). |
| Contabilidad digital y otros frentes |
| Sesiones de trabajo con Contabilidad para definir el flujo de creación de proveedores y su relación con las cuentas contables, con la corrección de la lógica del grupo de proveedores por honorarios. |
| Arrancó la investigación técnica sobre el sistema de tienda en ambiente de pruebas, para entender cómo desarrollar ahí las notas de crédito y los cambios. |
|
|
|
🎯
|
Lo que hay detrás
Cuando el sistema no puede,
que lo diga.
|
Varias de las entregas de esta semana atacan el mismo defecto: el sistema fallaba en silencio. Una celda que no se podía editar sin explicar por qué. Un tráfico faltante mostrado como cero en vez de "sin dato". Un costo congelado cinco meses con la carga en verde. Un despliegue exitoso sobre un servicio que no arrancó. Hoy la celda dice el motivo, el tráfico estimado se marca como estimado, y hay una alarma que revisa el dato y no el proceso. Un error visible se arregla; un error mudo se arrastra.
|
Cuatro titulares del periodo
→ Las confirmaciones de PI se cargan en PDF, incluso escaneado, y el documento verifica su propia aritmética.
→ Las reglas de comisiones salieron del código: las administra Remuneraciones, con historial.
→ El Forecast reemplaza el Presupuesto OPex con los ahorros definidos, y ya está en las apps.
→ Gate se hizo dueño de traslados y reemplazos, con los 3.664 movimientos históricos migrados.
|
|
|
|
Gracias al equipo
Seguimos.
Gracias a todo el equipo por esta semana. Si algo de lo que leíste aquí te sirve —o te falta— escríbeme y lo conversamos.
✉️ malvarez@badamax.cl
|
|
|
Un abrazo,
Mauricio Álvarez · Chief Digital Officer
Una publicación de Badamax Tech
Serie · Lo que entregamos
|
|
|
|