PIPELINEGuías
Introducir software personalizado en el equipo sin resistencia
La parte técnica del software personalizado rara vez es el problema. El motivo real del fracaso de las implementaciones está en las personas que deben trabajar con él, y eso se puede abordar de antemano.
La resistencia al software personalizado casi nunca se dirige contra la técnica, sino contra el temor a más trabajo o el miedo a ser reemplazados. Quien realiza el proceso afectado a diario debe ser consultado antes de la implementación, no informado después, y no debe introducirse nada que exija registro adicional.
01 — Equipo
Cómo lograr que el equipo colabore
- Involucrar pronto, no informar pronto. Quien hace el proceso a diario sabe dónde están las excepciones. Esta información solo existe antes, no después de la puesta en marcha.
- Tomar en serio la resistencia. Casi nunca se dirige contra la tecnología, sino contra más trabajo o contra la preocupación de ser reemplazado. Ambas cosas deben responderse abiertamente.
- No introducir nada que genere más trabajo. Los sistemas que exigen registro adicional se evitan, y con razón.
- Nombrar a una persona como primer punto de contacto. No como responsabilidad, sino para que las preguntas no se pierdan.
- Hacer visible el éxito. Si después de cuatro semanas nadie sabe si ha aportado algo, prevalece el recuerdo del cambio, no el beneficio.
02 — Participación
Qué necesitamos de ti
- Una persona de contacto que pueda decidir — no solo derivar.
- Acceso a los sistemas involucrados, a tiempo y no el día de la puesta en marcha.
- Ejemplos reales del día a día — cuanto más desordenados, más útiles para la prueba.
- De dos a cuatro horas para coordinación, distribuidas durante la duración del proyecto.
- Una respuesta a la pregunta de qué significa el éxito. Sin ella, no se puede evaluar nada después.
03 — Medición
En qué medís el éxito
- Establecer ese único número previamente. Sin valor de partida, no se puede demostrar nada después. Contar durante dos semanas es suficiente para una magnitud fiable.
- Tiempo de procesamiento por caso. La magnitud más directa: cuánto dura el procedimiento afectado hoy, cuánto después.
- Proporción de casos que pasan sin intervención. Esta tasa sube en las primeras semanas típicamente de forma notable cuando se afina — es el mejor indicador temprano.
- Tiempo de respuesta hacia el exterior. Con qué rapidez obtiene alguien que pregunta una primera respuesta vinculante.
- Lo que no deberíais medir: satisfacción en el equipo en las primeras dos semanas. Cualquier cambio se siente al principio peor de lo que es.
04 — Preguntas
Preguntas frecuentes
¿Cuándo vale la pena el software propio frente al software estándar?
Cuando tu proceso es una ventaja competitiva real, cuando el software estándar solo encaja al setenta por ciento y el resto termina en trabajo manual, o cuando los costes de licencia por usuario superan el desarrollo en pocos años. Si solo se trata de comodidad, el software estándar es más barato.
¿Qué pasa si dejamos de colaborar?
Tenéis código, documentación y accesos. Usamos deliberadamente tecnologías extendidas para que un cambio sea posible sin que nadie tenga que reconstruir todo.
¿Cuántos usuarios soporta un sistema así?
Depende de la arquitectura, que planificamos según vuestro crecimiento esperado, desde pocos usuarios en el propio negocio hasta varios cientos en múltiples ubicaciones.
¿Funciona en nuestros propios servidores o en la nube?
Ambas opciones son posibles. Para la mayoría de los negocios una solución en la nube requiere menos mantenimiento; donde los datos no pueden salir del local, lo configuramos en infraestructura propia.
¿Podemos empezar con una hoja de cálculo?
A menudo sí, y es una buena prueba. Si la hoja de cálculo refleja el proceso y solo falla en capacidad multiusuario, permisos o volumen de datos, el requisito está claro y el proyecto es calculable.
¿Qué pasa si durante el desarrollo descubrimos nuevos requisitos?
Es normal y está previsto, porque se trabaja en pasos pequeños. Un nuevo requisito se incorpora al siguiente paso, en lugar de detener todo el proyecto.
¿A quién pertenece el código fuente?
A vosotros, completamente, desde el pago. Está en el contrato. Podéis ir con él a cualquier otro desarrollador, ese es el punto.
05 — Continuar
Páginas relacionadas
- Software individual — Resumen
- Software a medida — Protección de datos
- Software individual — Financiación
- Software individual — Rentabilidad
- Software individual — Hacerlo uno mismo
- Software a medida — Lista de verificación
- Software a medida — Proceso
- Software individual — Errores típicos
- Automatización de procesos
- Integración CRM
- Interfaces API
- Todas las guías
Software individual por región
Siguiente paso
Hablemos brevemente de si esto vale la pena para vosotros.
Una conversación de veinte minutos suele bastar para aclarar si un proyecto tiene sentido. Si no, lo decimos: es más barato para ambas partes que una oferta que nadie necesita.