¿Tiene sentido montar un software de soporte open source para el servicio técnico o es un caos?

Hace tres años montamos en el taller un sistema de soporte open source con el mismo entusiasmo. Fue genial durante ocho meses, luego se llenó la base de datos y el sistema se bloqueó. Como no hacíamos copias diarias, volaron los registros de servicio de las últimas tres semanas y no encontrábamos qué pieza de qué cliente estaba dónde. Desde ese día nos pasamos a un sistema en la nube ya hecho.

Si vas a instalarlo, levanta el sistema con arquitectura de contenedores aislados, no directamente sobre el sistema operativo. Elige un servidor de al menos cuatro gigabytes de memoria y define una tarea que haga copia automática diaria de la base de datos en un almacenamiento externo. Así, en caso de caída, puedes volver en diez minutos.

Instalar el software lleva medio día, el verdadero tema es lidiar con los conflictos de plugins en las actualizaciones de versión.

Nosotros llevamos dos años usando el sistema open source. Nuestro coste mensual de servidor es de doce euros. Frente al sistema ya hecho hemos ahorrado unos mil ochocientos euros al año, pero tardé unas cuarenta horas en montarlo por primera vez y dejar listas las plantillas de correo.

En Italia, al guardar datos de dispositivos de clientes y registros de contacto, tenéis que cumplir plenamente las leyes de protección de datos personales. Si en los sistemas que alojáis vosotros surge una brecha de seguridad de datos, la responsabilidad legal es enteramente de vuestra empresa.

Antes de empezar haced estas tres comprobaciones: 1) ¿Podréis garantizar una salida de correo fiable con un servicio SMTP externo? 2) ¿Guardáis las copias diarias en otro servidor? 3) ¿Es la interfaz móvil lo bastante rápida para los técnicos?

¿Vuestros técnicos van a meter los registros desde los ordenadores de sobremesa del taller o van a rellenar el formulario desde el móvil estando en el sitio con el cliente? La interfaz móvil de la mayoría de softwares open source es bastante torpe para usarla sobre el terreno.

Correcto.

Pienso diferente. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Ánimo.

hay que ir paso a paso. ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

las soluciones que funcionan a pequeña escala se rompen al crecer aprendí esto tarde... eso es todo, disculpa si me he extendido demasiado.

Resumen breve para nuevos usuarios: Ningún proceso mejora si no se registran datos porque no sabes qué tienes que arreglar.

Espero que le sea útil.

Llevé mucho tiempo con este asunto. Si no lo pones por escrito desde el principio, luego surgen discusiones.

El calendario de pagos debe vincularse a las fases del proyecto no a fechas fijas.

Lo escribo para que no cometan el mismo error. El código sin documentación de instalación, aunque lo tengas, no es tuyo.

Soy una pequeña empresa, os lo cuento desde mi lado. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

El sistema sigue vivo después de la entrega; el mantenimiento es una partida aparte. Esta es mi opinión, no lo escribo como una verdad absoluta.

El año pasado nos pasó casi exactamente lo mismo. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

Si obtienes tres respuestas distintas sobre un tema la pregunta está mal formulada. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

En su momento, nosotros también nos atascamos ahí. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Me quedé tranquilo al leer esta respuesta, así que no solo me pasa a mí. Intentar hacerlo solo es la vía más cara.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Resumen breve para nuevos usuarios: Antes de decidir, mirad qué datos tenéis en la mano.