Quién decide, quién opera y quién traduce: los tres roles que definen si una implementación de software funciona

La implementación la sufre el que no la decidió

Hay un patrón que se repite en casi todos los proyectos de software que salen mal, y rara vez se nombra en la reunión de inicio: quien firma no es quien opera, y quien opera no fue consultado.

El dueño o el gerente decide, con razón, que la empresa necesita un sistema nuevo. El proveedor hace su trabajo: releva procesos, configura, capacita, entrega. Y a la tercera semana aparece el problema: el contador descubre que el flujo de retenciones no es el que él usaba; el jefe de bodega no participó en la definición de las ubicaciones; el vendedor de ruta nunca supo para qué servía el cambio de modelo de venta.

Ninguno de los tres está equivocado. Simplemente, nadie definió con claridad qué rol juega cada persona antes de que el sistema estuviera encima de la mesa. Cuando los roles no se aclaran, se llenan solos: el proveedor asume decisiones que eran del negocio, la operación asume que la gerencia ya lo pensó todo, y la gerencia asume que el equipo va a adaptarse.

Tres roles que un proyecto de software necesita tener con nombre y apellido

No son cargos: son funciones. En una empresa de veinte personas pueden recaer en dos o tres individuos; en una de doscientas, en equipos completos. Pero las tres tienen que existir, y cada una tiene que saber qué decide y qué no.

El que decide: patrocina, prioriza y desbloquea

Es la persona con autoridad para decir «paramos y corregimos» o «esto no entra en el alcance». Su trabajo no es opinar sobre pantallas; es tomar las tres decisiones que nadie más puede tomar:

• Alcance: qué se resuelve en esta primera etapa y qué queda para después.
• Prioridad: cuando dos áreas piden cosas incompatibles con el cronograma, cuál gana.
• Autoridad: cuando un jefe de área se resiste, quién respalda el cambio.

Un proyecto sin patrocinador activo no se cae por falta de tecnología. Se cae porque nadie resuelve las dos o tres discusiones internas que aparecen siempre en el mes tres. Si la persona que decide aparece solo al inicio y al final, el proyecto queda huérfano justo en el tramo más difícil.

El que opera: conoce el proceso real, no el ideal

Es el contador, el jefe de bodega, la jefa de facturación, el administrador de la sucursal. Sabe cómo se hacen las cosas hoy —con sus excepciones, sus atajos y sus parches en Excel— y es quien puede decir «esto que me estás mostrando no es como trabajamos».

Su participación no es un trámite de validación al final. Es materia prima. La diferencia entre un sistema que se usa y uno que se abandona suele estar en si esta persona fue escuchada durante la definición, o solo informada después.

Y aquí aparece la tensión más incómoda del proyecto: el que opera también es el que tiene más que perder con el cambio. No por mala voluntad, sino porque su experiencia es su capital. Un proyecto bien llevado reconoce eso y le da un papel protagónico —no lo trata como obstáculo.

El que traduce: convierte proceso en configuración

Es la función más subestimada y la que más veces falta. Alguien tiene que entender las dos lenguas: la del negocio («aquí no se factura hasta que bodega confirma») y la del sistema («eso es un flujo de estados con validación previa»).

Esa persona —analista, consultor o el responsable interno del sistema— es la que evita los dos errores clásicos: pedirle al proveedor que «lo haga como el sistema viejo» sin explicar por qué, y pedirle a la operación que «se adapte» sin explicar qué gana.

Cuando el rol de traductor no existe, la traducción la hace el proveedor por su cuenta. Y la hace con la información que tiene, que suele ser la del contrato: suficiente para entregar, insuficiente para acertar.

La confusión más cara: quién tiene la última palabra sobre un proceso

Hay una discusión que conviene tener antes de firmar, y casi nunca se tiene: cuando el software impone un flujo distinto al que la empresa usa hoy, ¿quién decide si se cambia el proceso o se cambia la configuración?

• Si decide el proveedor, la empresa termina adaptándose a un estándar que quizá no le conviene.
• Si decide cada área por su cuenta, el proyecto se llena de excepciones y se vuelve caro de mantener.
• Si decide el patrocinador con información de la operación, hay una respuesta y es defendible.

Lo importante no es la respuesta, es que exista. En los proyectos donde esta pregunta queda sin responder, cada área negocia por separado con el proveedor. Eso no es flexibilidad: es un sistema que a los dos años nadie entiende y que cualquier cambio amenaza con romper.

Cómo se reparte el trabajo durante el proyecto

Una forma sencilla de dejarlo por escrito es separar las tres fases y decir qué espera de cada rol en cada una. No es burocracia: es lo que evita que el proyecto avance con supuestos.

Definición

El que decide fija alcance y prioridades. El que opera describe el proceso real con sus excepciones. El que traduce documenta y valida que lo escrito signifique lo mismo para todos. El proveedor propone y advierte riesgos.

Implementación

El que decide resuelve las discrepancias que aparecen. El que opera prueba con datos reales, no con el ejemplo bonito. El que traduce controla el alcance y evita que el proyecto crezca sin control. El proveedor configura y reporta avance con hechos verificables.

Operación

El que decide define qué se mide y con qué frecuencia. El que opera usa el sistema y reporta lo que no funciona. El que traduce es el canal hacia el soporte —no cada usuario por su lado—. El proveedor sostiene, corrige y acompaña.

La pregunta que revela si los roles están claros

Hay una prueba rápida y muy reveladora. Antes de comenzar, pregunte a tres personas distintas de la empresa: «si mañana el sistema hace algo que no debería, ¿a quién le avisas y quién decide qué se hace?»

Si las tres respuestas coinciden, los roles están claros. Si cada una nombra a alguien distinto —o si alguien contesta «le escribo al del proveedor»—, hay un hueco que va a aparecer en el peor momento: cuando el problema sea real y la decisión urgente.

Qué hace Wide Solutions con esto

En Wide trabajamos con empresas ecuatorianas desde hace 17 años, y hemos visto suficientes implementaciones para saber que el software es la parte resoluble. Lo difícil es la coordinación humana: quién decide, quién opera, quién traduce.

Por eso nuestro modelo de trabajo parte de identificar esas tres funciones al inicio, antes de configurar nada. No porque seamos aficionados a la metodología, sino porque un proyecto con roles claros se implementa en menos tiempo y con menos retrabajo: la operación valida lo que se construye en lugar de descubrirlo al final.

También es una postura sobre el papel del proveedor. Nosotros configuramos, advertimos riesgos y sostenemos el sistema. Las decisiones de proceso son del negocio: nuestra responsabilidad es que se tomen con información, no tomarlas por defecto.

Si el equipo de tu empresa está por iniciar un proyecto de software —o ya lo inició y siente que avanza a ciegas—, vale la pena conversarlo. Puedes conocer cómo trabajamos en Wide o hablar con nuestro equipo.

Preguntas frecuentes

¿Esto aplica a empresas pequeñas donde todos hacen de todo?

Sí, y suele ser más crítico. En una PYME, el dueño tiende a decidir todo y el contador a operar todo; sin roles explícitos, las dos cosas se mezclan y nadie tiene tiempo para el proyecto. Lo mínimo viable: una persona que decide y una que valida con datos reales.

¿El contador debe liderar la implementación?

Debe ser una voz central, porque en la mayoría de las empresas ecuatorianas la información financiera y tributaria atraviesa todos los procesos. Pero liderar no es lo mismo que decidir alcance: eso corresponde al patrocinador. Cuando el contador decide alcance solo, el sistema se vuelve impecable para contabilidad e inservible para ventas.

¿Cuánto tiempo debe dedicar la operación al proyecto?

Más de lo que se planifica. Un error común es asumir que el jefe de bodega «va a sacar un rato». Si su participación no está en su agenda con horas asignadas, no ocurrirá: se priorizará la operación del día, que es la que paga las facturas.

¿Y si el proveedor ya tiene una metodología con roles definidos?

Es una buena señal, pero no sustituye la definición interna. El proveedor puede proponer el marco; los nombres y las decisiones son de la empresa. Si el proveedor llena esos roles con su propio personal por defecto, la empresa pierde la capacidad de decidir sobre sus propios procesos.

Un acuerdo de tres líneas antes de firmar

No hace falta un manual. Alcanza con escribir, en el acta de inicio, tres líneas:

1. Quién decide el alcance y las prioridades (un nombre).
2. Quién valida cada proceso con datos reales (un nombre por área).
3. Quién es el canal hacia el proveedor y quién traduce entre negocio y sistema (un nombre).

Tres nombres, revisados una vez al mes. Es el documento más barato del proyecto y probablemente el que más problemas evita.