Cómo trabajamos
Las fases del proyecto: análisis, desarrollo, puesta en marcha, seguimiento y traspaso.
Descubre cómo trabajamos
Un programa de transformación que culmina con la puesta en marcha de algo
No es una presentación de diapositivas. Identificamos dónde se producen realmente los atascos en el trabajo, elegimos el sistema inicial que merece la pena desarrollar, lo implementamos en tu hardware y medimos los objetivos que acordamos basándonos en tus datos.
¿Qué cambia y qué no?
La mayoría de los programas de transformación se estancan por la misma razón: empiezan por una tecnología y luego buscan un problema al que aplicarla. Nosotros empezamos en la oficina, en la planta de producción, en las llamadas, dondequiera que se produzca realmente el problema. Antes de desarrollar nada, podemos identificar el paso en el que el día se tuerce, quién está allí cuando ocurre y cuánto cuesta seguir solucionándolo manualmente.
La elección del sistema inicial depende de dos factores: cuánto te cuesta el problema y la rapidez con la que se puede comprobar la solución. Un flujo de trabajo en el que un error sale a la luz en cuestión de minutos es una primera versión mejor que una espectacular en la que nadie se da cuenta hasta pasado un trimestre. Ese orden no es nada romántico, y es la razón por la que el primer sistema suele sobrevivir al contacto con una semana real.
Los cambios en vuestra forma de trabajar son mínimos, y los especificamos antes de firmar. Quién aprueba las acciones que el sistema no puede llevar a cabo por sí solo. Quién revisa el registro de ejecución cuando algo parece extraño. Quién participa en la reunión de revisión en la que comparamos los objetivos con vuestras propias cifras. Tres personas concretas y tres hábitos.
El resultado final es un sistema que funciona. El código, los datos y la documentación son tuyos, y tu equipo puede modificar el sistema sin que nosotros estemos presentes. Si decides que sigamos colaborando después, debería ser porque merece la pena resolver el siguiente problema, no porque la arquitectura haya hecho que nuestra salida resulte costosa.
Principios que defendemos
Resuelve primero el problema adecuado
En primer lugar, observamos el flujo de trabajo real. Si el software no es el cuello de botella, lo indicamos y detenemos el programa antes de pasar a la fase de desarrollo.
Una persona aprueba cualquier cosa que tenga importancia
Los sistemas proponen; las personas deciden. Las acciones que conllevan gastos deben esperar a que se designe a un responsable de la aprobación antes de su puesta en marcha, aunque el equipo aún puede impugnar la norma.
Se ejecuta allí donde se almacenan los datos
El sistema se ejecuta dentro de tus servidores, entorno de tenencia o sitio actuales. Esa restricción inicial determina la arquitectura y no conlleva ningún coste adicional.
Objetivos fijados, medidos en función de tus datos
En cada proyecto se especifican las categorías objetivo, el método de medición y los puntos de evaluación, y la medición se realiza en comparación con tu propia referencia. No incorporamos a tu contrato ninguna cifra de otro cliente, ni publicamos ninguna.
El objetivo es la entrega, no el anticipo
Todo está versionado y documentado para el traspaso. Un contrato de retención sigue siendo una opción que puedes elegir cuando el siguiente problema justifique que sigamos trabajando juntos.
La adopción avanza cuando los operadores pueden ver qué cambia, aprobar lo que es importante y asumir la responsabilidad de lo que se envía.
Qué va a pasar a continuación
Preguntas que suelen hacer los propietarios
¿Se trata de un programa de consultoría?
No. El programa incluye una implementación con un alcance definido y culmina con un sistema de producción que tu equipo puede gestionar, no con una presentación de recomendaciones.
¿Qué es lo que se firma?
Las categorías objetivo, el método de medición y los puntos clave de análisis para ese proyecto. Los valores de referencia se obtienen a partir de tus datos; no publicamos ni prometemos una cifra universal.
¿Necesitamos primero toda la plataforma?
No. En su lugar, podríamos recomendar un sistema acotado. El programa solo está justificado cuando el problema operativo abarca flujos de trabajo conectados.
Dinos dónde se atascan las tareas.
Determinaremos si es necesario un programa o si basta con un sistema acotado.
Habla con nosotros