La semana real, antes de la demostración
Antes de una demostración, escribí la semana normal del negocio. Quién carga el pedido, qué datos pide, quién lo aprueba, qué pasa si la mercadería vuelve a medias o cambia la dirección, y qué mira quien lleva las cuentas al cerrar el día. Si esa lista entra en el producto, el enlatado es un candidato serio. Si para que cierre tenés que cambiar la operación a la forma del programa, anotalo: ese cambio también cuesta, aunque no figure en la cuota.
Pedile a quien vende que recorra la lista con un caso tuyo. Si un paso que te importa no se puede hacer, el producto está pensado para otro proceso. Guardá la respuesta. Una promesa de que después se ve no es una función.
Cuándo el enlatado alcanza
El enlatado alcanza cuando la tarea se parece a la de muchos comercios del rubro. Llevar clientes, facturar, un stock simple por cantidad, una tienda con catálogo y un medio de pago. Te adaptás en lo chico: el nombre de un estado, un campo que no usás, un reporte distinto al de la planilla. A cambio arrancás antes, y las actualizaciones las empuja quien lo mantiene.
También sirve como primer tramo. Usá un sistema estándar para la parte común y dejá para después lo propio de tu empresa. Encargar todo porque algún día vas a querer otra cosa suele atrasar lo que hoy ya se puede ordenar. Si cubre la semana real y te deja sacar los datos, alcanza con usarlo.
Cuándo el proceso es el negocio
El desarrollo conviene cuando la forma de trabajar es el negocio. Un reparto con reglas tuyas de qué salió, quién lo lleva y cómo se cierra si no había nadie. Un presupuesto que pasa a orden de trabajo, a materiales y a la visita, con estados que un módulo genérico no trae. Una plataforma que usan tus clientes y que es lo que vendés. Una web o un panel con un recorrido que una plantilla no contempla.
Conviene también cuando la pantalla y el equipo cuentan distinto. El sistema muestra un estado y la planilla guarda la excepción, porque la pantalla no la acepta. Si esa excepción es el día a día, sumaste una herramienta y seguís operando afuera. Ahí conviene describir el proceso y construir lo que falta.
La primera etapa es una tarea que el equipo pueda usar. El resto se suma cuando esa parte cierra. Cada cambio lo pedís vos, y alguien lo tiene que construir y cuidar. Encargarlo una vez no lo deja mantenido solo.
Quién responde por los datos
El nombre de un cliente, la dirección de una entrega o el dato de alguien del equipo identifican a una persona. La guía de la URCDP explica que tu empresa es responsable del tratamiento cuando gestiona esos datos para sus propios fines. Si le encargás esa gestión a un tercero para que la haga por tu cuenta, ese tercero es el encargado. La guía pone de ejemplo a un estudio contable, un estudio jurídico o un call center. La Ley 18.331 define al encargado como quien trata datos personales por cuenta del responsable. Preguntá si el proveedor trata esos datos por tu cuenta y qué puede hacer con ellos. Seguís siendo responsable aunque el sistema lo opere un tercero.
La misma guía dice que guardar información con servicios por internet, la nube, puede implicar que los datos salgan del país. Si el destino no es adecuado a los estándares uruguayos, puede hacer falta una autorización de la URCDP. La Ley 18.331 prohíbe esa transferencia hacia un país u organismo internacional sin un nivel de protección adecuado, con excepciones, y permite que la URCDP la autorice si hay garantías suficientes, por ejemplo cláusulas del contrato. Anotá dónde están los datos y las copias, y si al irte te los dan en un archivo que otra herramienta lea. Pedí las condiciones por escrito. Esta nota no reemplaza el asesoramiento sobre tu contrato.
La operación igual se documenta
La operación se documenta igual, compres un producto o encargues un desarrollo. La DGI publica que todas las operaciones vinculadas con los impuestos que administra tienen que estar debidamente documentadas. Tu contador te dice si te toca el comprobante electrónico o, si estás exceptuado, el de papel. Si el sistema no lo emite ni le pasa los datos al que sí lo emite, vas a copiar montos a mano. En un desarrollo propio la prueba es la misma: el pedido en pantalla tiene que llegar al comprobante.
Probar con casos de tu semana
Armá tres pruebas con ejemplos de tu semana, sin nombres reales de clientes. Un caso común. Uno con un error, como un dato que falta o un pedido repetido. Y la excepción que más tiempo te come: el retorno, el cambio de dirección o el trabajo partido en dos visitas. Mirá si el enlatado lo resuelve configurando. Si te dicen que eso se desarrolla, pedí fecha y quién lo hace. Lo que no entra en la primera etapa de un desarrollo queda escrito afuera.
Preguntá quién atiende cuando un lunes el sistema no abre. En el enlatado el soporte viene con el servicio, y el rumbo de las mejoras lo marca quien hace el producto. En el a medida tiene que haber alguien que pueda cambiarlo cuando el negocio cambie: un proveedor o una persona de la empresa. Las dos se mantienen. La diferencia es quién marca el próximo paso y qué pasa si esa relación se corta.
Si la parte común cabe en un producto y un tramo es tuyo, mezclá. Enlatado para facturar o para el stock simple, y un desarrollo chico para el reparto, el panel o el paso que hoy vive en mensajes. Pasar el pedido del chat al sistema puede ser ese puente. Tienen que hablarse: si hay que copiar a mano entre los dos, el problema sigue en el medio.