Dónde se rompe la gestión de proyectos dentro de una organización

1. Niveles: empresa, departamento, proyecto

El problema. Las reglas se fijan arriba y se ignoran abajo, o cada proyecto inventa las suyas. Quién aprueba, qué tarifas aplican, cómo se registran las horas: cada proyecto responde distinto.

Cómo lo resuelve ApprovedFlow. Cada regla es un ajuste con una sola herencia: valor de la empresa, departamento, proyecto. Un departamento sustituye a la empresa, un proyecto al departamento, y un bloqueo en cualquier nivel detiene el de abajo. El jefe de proyecto ve cada ajuste con su origen, así sabe qué heredó y qué cambió.

2. Recursos compartidos entre proyectos

El problema. El mismo ingeniero está en tres proyectos. Cada jefe lo planifica al 100 %. Nadie ve la sobrecarga hasta que las fechas se retrasan.

Cómo lo resuelve ApprovedFlow. Una persona en una tarea lleva dos cifras: su parte de las horas de la tarea y la parte de su jornada que le dedica. El plan calcula sus días con ambas, limita a todos a las horas previstas de la tarea y muestra lo que aún no está asignado. Una tarea que crece reparte de nuevo a las personas según sus partes; una persona que reduce su tiempo nunca reduce la tarea en silencio.

3. Equipos dispersos y personas que nunca inician sesión

El problema. Consultores, personal de proveedores y representantes del cliente hacen trabajo real en el proyecto pero no abrirán otro sistema. Sus aprobaciones y avances llegan por correo y se pierden.

Cómo lo resuelve ApprovedFlow. Un contacto tiene un rol en el proyecto sin cuenta. Recibe su tarea por correo, la actualiza o la aprueba con un enlace firmado, y la decisión queda en la tarea con su nombre. Si se registra después, el mismo rol lo acompaña. Para el equipo que sí inicia sesión, Mis tareas muestra solo su propio trabajo, con un cronómetro que rellena la hoja de horas.

4. Varias sedes, calendarios y zonas horarias

El problema. La sede trabaja de domingo a jueves, la sucursal de Londres de lunes a viernes, la obra de El Cairo tiene sus festivos. Un plan hecho sobre un calendario está mal en los otros.

Cómo lo resuelve ApprovedFlow. Cada sucursal tiene su semana laboral, su horario, sus festivos y su zona horaria; una persona puede tener su propio horario. El planificador mueve las tareas por días laborables en el calendario de quienes trabajan en ellas. Un recordatorio llega a cada persona dentro de su propio horario, nunca a las 3 de la madrugada.

5. Seguir lo que realmente pasó

El problema. El avance es una sensación. Las horas viven en una hoja, el estado en un chat, el plan en una herramienta que nadie actualiza.

Cómo lo resuelve ApprovedFlow. Las horas se registran en la tarea, a mano o con cronómetro, y suben a la fase y al proyecto. El avance se propone a partir de las horas registradas frente a las previstas. El plan, las horas y el estado son un solo registro, así el panel muestra lo hecho, no lo dicho.

6. Aprobación del cliente con prueba

El problema. «El cliente lo aprobó» es una frase en un hilo de correos. Un mes después nadie la encuentra y la factura se discute.

Cómo lo resuelve ApprovedFlow. Una tarea, un entregable o una hoja de horas va al aprobador que indica la cadena: el jefe de proyecto, el jefe de departamento o el cliente. El cliente aprueba en pantalla o respondiendo al correo; la decisión, la versión del documento y la fecha se guardan con el trabajo. Un entregable que el cliente rechaza vuelve con sus comentarios en la misma tarea.

7. Facturación y cobro

El problema. El trabajo aprobado y la línea de factura son dos mundos. Finanzas factura tarde, o factura lo no aprobado, y el cobro es otra persecución.

Cómo lo resuelve ApprovedFlow. Las horas aprobadas y los hitos de proveedor completados aparecen en la pestaña Finanzas del proyecto con su coste a tarifas fijadas. Desde ahí se prepara la factura del trabajo aprobado y se sigue hasta el cobro. El dinero y el trabajo que lo respalda quedan en la misma página.

8. Desviación: el plan frente a la realidad

El problema. El plan decía 40 horas; se gastaron 60; nadie replanificó, así que la fecha de fin es una ficción.

Cómo lo resuelve ApprovedFlow. El motor de tiempo muestra las horas previstas frente a las registradas y el total esperado al ritmo actual, por tarea y acumulado. Cambiar la duración de una tarea recalcula sus horas y mueve sus dependientes por sí solo, con el resultado en su sitio y un deshacer. Las líneas base se guardan a propósito y se conservan, así la desviación se mide contra una base real.

9. Gestión del cambio

El problema. Los cambios de alcance llegan del cliente como un documento Word. Se acuerdan de palabra, se hacen y nunca se presupuestan ni se planifican.

Cómo lo resuelve ApprovedFlow. Una solicitud de cambio es un documento en el proyecto o la tarea, con versiones y su cadena de aprobación. El jefe de proyecto aplica su impacto al plan con el mismo planificador, así las tareas nuevas, las fechas movidas y las personas añadidas salen de la solicitud en vez de sorprender al presupuesto.

Los proveedores en la misma imagen

La orden de compra de un proveedor, sus hitos, sus pagos por porcentaje y las horas de su personal están dentro del proyecto, en la moneda del proveedor y en la moneda base de la empresa. Pagar un hito es una solicitud, una aprobación y un registro, no una conciliación a fin de mes.