Lo que nos preguntan antes de trabajar juntos

Viveo SRL es una empresa argentina de desarrollo de software que construye sistemas de gestión para operaciones reales: industria, agroindustria, minería, logística, salud y comercio. Trabajamos de dos formas: con productos propios que ya están en producción —mantenimiento industrial, tarjas y jornales, punto de venta, roster de personal, laboratorio, trazabilidad— y con desarrollos a medida para operaciones que ningún sistema de mercado resuelve bien.

Estamos en Tucumán, Argentina, y trabajamos con empresas de todo el país. La mayoría de nuestros clientes son del NOA —ingenios y fincas cañeras, industria, minería y distribución— pero el trabajo es remoto salvo el relevamiento inicial y las puestas en marcha, donde ir a la operación sirve más que cualquier reunión.

Industria y agroindustria (ingenios azucareros, fincas cañeras, plantas productivas), minería y energía, salud y distribución farmacéutica, logística y transporte de personal, y comercio y servicios. Cada uno de nuestros sistemas nació dentro de una operación de esos rubros, no en un pizarrón.

Con las dos, pero el encaje es distinto. Una PyME suele arrancar por un producto ya construido —punto de venta, gestión comercial, stock— porque le resuelve el problema desde el primer mes. Una empresa mediana o grande normalmente llega con un proceso que ningún sistema de mercado cubre y ahí el camino es el desarrollo a medida o la integración entre lo que ya tiene.

Las dos cosas. Tenemos sistemas propios que ya están funcionando y se implementan sobre una base construida, con la configuración que necesita cada empresa. Y hacemos desarrollo a medida cuando el proceso es demasiado particular para forzarlo dentro de un producto. En la práctica muchos proyectos son mixtos: un producto nuestro como base más los módulos específicos de esa operación.

El enlatado impone su forma de trabajar: la empresa adapta el proceso al sistema. El software a medida hace el camino inverso. La diferencia no se nota en las funciones obvias —facturar, cargar stock— sino en las particulares: el circuito que sostiene tu margen y que ningún producto de mercado contempla porque no le sirve al resto de sus clientes. Ese es el punto donde el enlatado empieza a convivir con planillas paralelas.

Depende del alcance, y esa respuesta se vuelve concreta recién después del relevamiento. Lo que sí es fijo es cómo lo trabajamos: no cotizamos un proyecto cerrado de un año. Definimos el primer alcance útil —lo que más duele y más rápido devuelve valor—, lo presupuestamos con precisión y recién con eso funcionando decidimos el siguiente paso. Así el presupuesto se compara contra algo que ya está andando, no contra una promesa.

La primera versión útil se mide en semanas, no en meses: siempre buscamos que algo entre en producción temprano, aunque cubra una parte del proceso. Un sistema completo lleva más, pero el error clásico es esperar un año para ver la primera pantalla. Si tu proveedor actual te pide eso, es una señal.

Los datos son siempre de la empresa y se pueden exportar en cualquier momento. La propiedad del código depende del acuerdo: en desarrollos a medida se define por contrato y puede quedar del cliente; en nuestros productos, la empresa tiene licencia de uso y nosotros mantenemos el producto. Lo importante es que quede escrito antes de empezar, no después.

Es lo que recomendamos. Casi todos los sistemas que hoy tenemos en producción empezaron cubriendo un solo circuito. Arrancar por el problema más caro tiene dos ventajas: se ve el resultado rápido y el equipo se acostumbra a usar el sistema antes de que sea crítico para toda la empresa.

Cuando tu proceso es estándar y hay un producto de mercado que lo cubre bien: contabilidad, sueldos o facturación pura no justifican construir de cero. También cuando la empresa no tiene a nadie que pueda dedicarle tiempo al proyecto, porque un sistema a medida se construye con la gente que conoce la operación. Si es tu caso, te lo decimos antes de empezar.

Con una conversación donde vos contás cómo funciona hoy la operación y nosotros preguntamos. De ahí sale un relevamiento: dónde está la fricción, qué decisión depende de un Excel y qué sistemas ya existen. Con eso proponemos un primer alcance con su presupuesto. Recién después se escribe código.

Sí, y no es un extra opcional: los procesos cambian y el software tiene que cambiar con ellos. Todos nuestros sistemas en producción están bajo mantenimiento continuo, con corrección de errores, ajustes por cambios normativos y evolución de funcionalidad. Un sistema sin mantenimiento se vuelve el próximo sistema viejo que hay que reemplazar.

Es el requisito, no un deseo. Varios de nuestros sistemas los usan operarios en el campo, cajeros en hora pico y encargados de depósito con un lector en la mano. Eso obliga a interfaces que se aprenden mirando y a pantallas pensadas para el dispositivo real —tablet, celular, terminal— y no para el escritorio del gerente. La puesta en marcha incluye acompañamiento hasta que el equipo trabaja solo.

Sí. Es parte habitual de la puesta en marcha: importamos maestros —artículos, clientes, personal, activos— y el histórico que tenga sentido conservar, desde Excel, Access, MySQL o el sistema que estés usando. La migración se valida contra los números que la empresa ya conoce antes de dar el sistema por arrancado.

Sí, sin problema. Trabajamos con información operativa y comercial sensible —costos, personal, clientes— y el NDA es un trámite normal antes del relevamiento.

Sí, y suele ser el punto de partida. La mayoría de las empresas con las que trabajamos ya tiene un ERP o un sistema contable que funciona bien para lo suyo; el problema es lo que queda afuera y termina en planillas. Integramos por API, por base de datos o por archivos según lo que el sistema exponga, para que el dato se cargue una sola vez.

Los que tienen que hacerlo, sí. Un punto de venta en hora pico o una carga en el campo no pueden depender de la conexión: esos sistemas operan localmente y sincronizan cuando la red vuelve. En cambio un tablero de gestión o un portal de pedidos no necesitan modo offline. La decisión se toma por caso, mirando dónde se usa el sistema.

Sí. Tenemos un gateway propio de facturación electrónica que resuelve la integración con los web services de AFIP/ARCA —firma del ticket de acceso, sesiones, homologación y producción— y lo usan todos nuestros sistemas que facturan. También informa trazabilidad de medicamentos al Sistema Nacional de Trazabilidad de ANMAT.

Lo habitual es la nube, porque baja el costo de infraestructura y el mantenimiento queda de nuestro lado. Cuando la operación lo exige —conectividad mala, política interna de datos o un requisito regulatorio— también instalamos en servidores del cliente. Es una decisión de contexto, no una postura.

Sí, por la Cloud API oficial de Meta con plantillas aprobadas, no por números personales ni automatizaciones que se caen. Desarrollamos nuestro propio gateway de mensajería, que encola, envía, reintenta y registra el estado de cada mensaje, y lo comparten los sistemas que necesitan avisar algo: un turno asignado, un cambio de última hora, un comprobante.