En Fútbol Emotion desarrollamos nuestro propio ERP y plataforma de Ecommerce, que nos ha permitido crecer durante los últimos 9 años. Aquí un hilo con mi visión personal y algunos aprendizajes sobre el peculiar mundo de hacer software interno en cliente final. #abrohilo
En cualquier consultoría externa,o al fichar directivos,va a aparecer el implantar software comercial con el que ha trabajado antes. SAGEs, Navision...Máxima prioridad y plazos ilógicos. Obvio, pues es lo que conocen. A los meses, son heavy users y defensores del producto interno
El control alcanzado sobre el detalle del proceso se vuelve muy óptimo. Se modelan procesos mucho mejor que con soft comercial, y extrema la adaptación a la empresa...
...Pero, como todo es todo posible, se corre el riesgo de caer en personalismos, preferencias sesgadas y crear de forma diferente procesos similares por departamentos si no se ejerce el control suficiente sobre el producto.
Gestionar un ERP no es un tema exclusivamente tecnológico. Hacen falta informáticos con visión empresarial, y gente de empresa con orientación técnica. Sólo mezclar las dos visiones hacen que la cosa sea sostenible.
Es clave identificar a un par de usuarios clave por departamento, que sean capaces de detectar procesos a automatizar, a calibrar las necesidades del mismo, y a evangelizar en el uso de las nuevas herramientas.
Cualquier cambio de la plataforma es mal recibido por el usuario, aunque mejore su día a día. La única forma de evitarlo es implicarles en concebir esa tarea, y colar junto a esa versión una mejora fácil y muy visual que aprecien, aunque no tenga conexión con la feature principal
A las nuevas funcionalidades pueden seguirle periodos de inestabilidad o minicorrecciones. Hay que ir alternando el lanzamiento de funcionalidades entre diferentes departamentos, para que todos se sientan atendidos, y no experimenten demasiados periodos seguidos con incidencias.
Cualquier sistema de cara al público debe ser tolerante al fallo, y debe ser capaz de trabajar offline con una funcionalidad suficiente.
Los mensajes de error no se leen. Eso es así. La información del usuario es muy útil, pero también muy viciada y sesgada, especialmente en el caso de frustrantes fallos.
Cualquier desarrollo debe ser concebido como multiidioma, multimercado, multiIVA... Y con capacidad de poder gestionar mercados de forma igualitaria o diferenciada según convenga, pero sin forzarse a uno u otro camino. Esos cambios se vuelven complejos si no se plantean de base.
¡Cuidado con el orden de multiplicación, redondeo y suma de cualquier valor en software de gestión! Efecto tocapelotas 100% en cualquier integración la pérdida de precisión en casos como la suma de albaranes con descuentos, cantidades, atributos, etc.
"Good enough is the new perfect". Frase escuchada por ahí, que es muy aplicable a los desarrolladores: no hace falta solucionar los problemas de una forma metodológicamente perfecta, sino tener en cuenta su impacto y coste de desarrollo.
Ninguna "bomba" de gran desarrollo o cambio de concepto planteado como urgentísimo acaba siendo razonable. Es fruto de una minicrisis laboral, y del calentón de replantearse todo sin calibrar implicaciones de su parcial propuesta. Los grandes cambios surgen en calma y reflexión.
Hacer partícipes a los usuarios de la complejidad del desarrollo de una nueva funcionalidad y sus implicaciones, ayuda sobremanera a que suavicen la presión con los plazos y se impliquen en tomar buenas decisiones de diseño.
La empresa y su plantilla cambian. Hay que definir procesos sólidos, sin ambigüedades, casi "Poke-Yoke". De lo contrario, se acaba con ambigüedades, para evitar que pueda hacerse mal por el propio concepto. Hay que evitar ambigüedades, o el dato se vuelve inexplotable.
...Y hay que documentar desarrollo y procesos, algo de lo que siempre se rehuye al principio y de lo que nos arrepentimos no haber hecho más.
Pero en la batalla entre metodología de programación vista en la Uni, y la velocidad de evolución de la herramienta, siempre una de las dos acaba siendo la víctima, sobre todo hasta que el equipo va creciendo. Vamos madurando las formas de crecer, evitando caer en burocracias.
El soft propio debe llegar hasta donde debe: ser el núcleo del sistema,sin extralimitarse o reinventar la rueda.Sobre él deben conectarse herramientas que salgan del core de lo que representa. Así se obtiene el control y la BBDD central es 100% explotable en cualquier herramienta
En ese ecosistema, debe tenerse claro qué sistema es el "dueño" de cada tipología de dato, y que sea fuente de la información del Business Intelligence y reportes. Intentar replicar en varios sistemas un mismo dato siempre acaba en tener varios datos levemente diferentes.
Imprescindible tener a una persona con el control transversal de la aplicación. Un "product-owner" muy preocupado por el proceso, métricas, y que interactúe con soltura comunicándose con usuarios de cada área. Y reforzar a esa persona para que permanezca mucho tiempo en el equipo
Es altamente gratificante ver el impacto real que evolucionar un software tiene en una empresa y en las formas de trabajo en sus personas. Los desarrolladores de consultoras jamás experimentarán ese sentimiento de pertenencia.
Hasta aquí algunas reflexiones de cómo hemos hecho que el motor de una empresa que factura 30M€ sea software propio, creado por una sola persona y evolucionado por otras tantas. Lo hicimos, pese a las voces de todos de que era ilógico, porque no sabíamos que no se podía hacer.
Por cierto, si eres desarrollador, y buscas dirigir tu carrera a la creación de software en cliente final, a menudo lanzamos puestos de empleo para evolucionar las herramientas de nuestro ecommerce en Zaragoza. Puedes consultarlos en: futbolemotion.com/es/empleo/tecn…
