Hace ya unos días que en Pymes y Autónomos, algo así como nuestro blog padre, plantearon una discusión interesante en la que intentaban dilucidar cual es la mejor opción para una pyme a la hora de escoger un software para gestionar el negocio, si uno diseñado a media o uno estándar. A pesar de que lo han analizado bastante bien, creo que puedo aportar mi granito de arena al tema, así que allá vamos.
Mi opinión personal es que, para la inmensa mayoría de las empresas, la elección debe ser estándar de calle, y creo que debe ser así por varias razones además de las que ya han comentado ellos, de las que destacaría fundamentalmente tres: las características de las pymes españolas, la flexibilidad del software estándar en la actualidad, y la mayor robustez e implantación de este tipo de soluciones.
- El tipo de empresas que tenemos en España: micro-mini-pymes, ése es el tipo de empresa predominante en nuestro país y, en la mayoría de éstas, conceptos como proceso, procedimiento o gestión son términos extraños. El software es una herramienta que nos debe ayudar a llevar mejor nuestro negocio y cuando se recurre a una solución a medida solemos buscar que se adapte a como hacemos las cosas, con lo que en muchos casos el margen de mejora es mínimo. Difícil es que la empresa a la que hayas contratado para desarrollar el software te diga que no, que eso deberías hacerlo de otra manera. El resultado, que la solución se acaba convirtiendo en un problema.
- Las posibilidades de parametrización del software estándar: con la irrupción en el mercado pyme de las soluciones ERP se ha abierto la puerta a sistemas que disponen de importantes opciones de personalización sin que su núcleo, y por tanto la facilidad de actualización y mantenimiento, se vea afectado. El optar por una solución estándar no quiere decir que no se pueda adecuar en cierta medida a nuestras necesidades particulares.
- Constatar qué tal funciona: acudir a un software estándar supone que tendremos muchas más posibilidades de informarnos acerca de cómo está funcionando en otras empresas de nuestro sector de actividad. Podemos ver cuáles son sus clientes, preguntar directamente incluso si conocemos a alguno de ellos y partir de una cierta seguridad antes de comenzar con su implantación. Está claro que cada empresa es un mundo y que lo que le funciona al vecino puede no ser adecuado para nosotros, pero en la mayoría de los casos sí que nos puede servir, al menos como orientación.
Como os decía al principio, mi elección es estándar sin duda, exceptuando casos muy particules en los que nada de lo que existe en el mercado encaja en nuestra empresa, aunque lo cierto es que hay mucho donde elegir. Me gustaría de todas formas saber qué es lo que opináis vosotros y que motivos, a favor o en contra de la elección, podéis aportar, sin duda el tema da para mucho.
Foto | kakaopor
En Pymes y Autónomos | Razones para no usar un software a medida en nuestra empresa
En Pymes y Autónomos | Razones para usar un software a medida en la empresa
Comentarios
Software a medida o estándar en la pyme: estándar sin duda....y si es bajo el modelo saas mejor.. ;)
Un saludo
Sin duda, y bajo mi experiencia, el software a medida puede ser una solución muchísimo mejor que el software \"estándar\" (que de estándar poco suelen tener), pero siempre que cumpla ciertos requisitos:
1. Que no esté basado en una aplicación base \"estándar\", como el vtiger CRM. Son aplicaciones hechas por programadores para programadores, no para usuarios, y suelen ser muy poco flexibles y tienes que adaptarte a su metodología base.
2. Que el/los programadores sean serios, que no pretendan montar algo experimental. Los experimentos para el laboratorio.
3. Que la aplicación se acerque más al mínimo común que al conjunto de las necesidades de cada uno de los elementos a procesar. Si un cliente tiene 4 teléfonos, no hace falta poder guardar 4 teléfonos. Se guarda el número principal y el resto se pone en un campo \"notas\". Mientras menos campos haya, más útil será. Ayudará a que los usuarios introduzcan más datos importantes.
4. Que de verdad esté adaptada al uso que harán los usuarios. Muchas veces el jefe está demasiado alejado del día a día y del uso real que se hará la aplicación, y es posible que no pueda hacer entender al/los programadores cuáles son los requerimientos de la aplicación. Las tareas más repetidas tienen que ser las más rápidas y sencillas. Es buena idea que el/los programadores se reúnan con los usuarios que van a hacer un uso intensivo de la aplicación, y que cuando gran parte de la funcionalidad de la aplicación esté hecha (independientemente de los bugs que haya), haya una reunión de toda la empresa con una presentación de la aplicación, y se discuta sobre cómo adaptarla mejor.
5. Que la calidad del software sea la prioridad número 1. La colaboración de los usuarios es fundamental. Deben notificar directamente a los programadores los bugs que encuentren. Los intermediarios sólo añaden información innecesaria o eliminan información crucial.
6. Que
(¿por qué sale cortado? Sigo...)
6. Que la funcionalidad sea la prioridad número 2. Lo único que debe ponerse por delante de la facilidad de uso de la aplicación es la calidad, y prácticamente nunca están reñidas la una con la otra. NUNCA se le debe dar prioridad a un sistema de menús bonito o espectacular si se puede hacer más fácil de usar.
7. Que la aplicación sea consistente. Mientras menos "personalidad" tenga la aplicación, mejor. Puede ser muy bonito y agradable para unos, pero seguro que será ridículo e incómodo para otros. De nuevo, el mínimo común.
¿Qué tal les parece un modelo intermedio?
Les explico mi modelo de desarrollo. Tengo una aplicación que se puede considerar estándar y bastante pulida en cuanto a funcionalidad. Sin embargo mi modelo de relacionarme con los clientes se parece bastante al que se tiene en el desarrollo a medida.
Mis clientes saben que pueden solicitar todas las modificaciones y ampliaciones que quieran. Si no soy capaz de convencerles en diez minutos de que lo que piden es una mala idea seguramente es porque ellos tienen razón en lo que piden y termino haciéndolo.
En el caso de pequeñas adaptaciones y ampliaciones el cambio es casi inmediato.
Si son cambios significativos con respecto a la forma de trabajar de la aplicación o funcionalidades complejas, meto en el horno la cuestión un tiempo. Primero para ver si la solicitud del cliente era un calentón sin mayor transcendencia y segundo para ir recopilando información y opiniones de otros clientes.
Una vez puesto en el trabajo implico al futuro usuario lo antes posible con el nuevo desarrollo para identificar errores en el planteamiento de la funcionalidad lo antes posible y para utilizarlo como betatester avanzado.
Evidentemente todo se hace sin que la aplicación pierda su coherencia y perspectiva, trato de evitar lo máximo posible los "pegotes".
La verdad es que esta forma de trabajar me da muchas satisfacciones y me ayuda a ajustes los detalles a un nivel bastante complicado de alcanzar en otros modelos de desarrollo. Además cuando uno es su propio jefe es fenomenal para entrar en modo pereza y comodidad.
No cobro por todo este trabajo "extra", lo incorporo sin coste alguno a la versión "estándar" de todos los clientes. Creo que tener esa colaboración por parte de los usuarios es un activo muy valioso, siempre les digo a los clientes "tocahuevos" que son mis preferidos, y les soy sincero.
Como ventaja añadida por mi parte es que aprendo much
(quedó cortado el comentario)
Como ventaja añadida por mi parte es que aprendo mucho, fidelizo clientes y al ser la aplicación también algo suyo en algunos casos me hacen parte del trabajo comercial :)
Lo dicho, creo que es muy interesante un opción intermedia entre estándar y a medida para ambas partes.
@Olav, la situación que planteas es perfecta, si todos los desarrollos a medida funcionaran así y tuvieran ese soporte y respaldo serían la mejor solución, pero creo que la realidad es diferente, y ese es precisamente mi punto, que en el mundo real las cosas no son (generalmente, por suerte hay excepciones) como las describes.
@Antonio, para mí lo que comentas es un estándar, si el desarrollo se adapta para todos los usuarios, estás describiendo un software estándar, aunque en principio hayan sido funciones solicitadas por uno de tus clientes. De hecho creo que es la mejor forma de que un software avance y mejore, incorporando la información y los requerimientos que proporciona el "feedback" de los usuarios.
Un saludo y gracias por los aportes (a todos).
Sería importante también en toda esta puesta de exposiciones que se han formado entre ambos blogs, realizar una medida del coste de la inversión de unos sistemas, otros, cálculos en mejora de productividad y planteamiento de los planes B en el supuesto de caida del distribuidor.
Buena entrada Jose MAría y mejores aportes la de los comentaristas.
Un saludo
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect