Este es el problema:
Disponer de sistemas de información unificados aporta mil ventajas pero supone un importante esfuerzo económico y de recursos, así como una transformación en la forma de trabajar del equipo, y esto son riesgos que hay que controlar y minimizar.
EL CASO Y SUS CONCLUSIONES
La información es uno de los pilares fundamentales sobre los que gira cualquier organización empresarial o social y, por ello, es una de las temáticas donde constantemente se ha de poner orden para que la misma fluya de una manera operativa.
Se abordaba en este caso el gran proyecto por el que miles y miles de entidades están pasando o pasarán en los próximo años, que no es otro que unificar las diferentes bases de datos (las de administración con sus clientes o socios y proveedores, las de los comerciales o fundraisers con sus agendas “ultrasecretas”, las de los servicios de atención al cliente, recepción, etc con sus postit imprescindibles, las de recursos humanos con …..”. Para lo que nos ocupa da igual llamarlo CRM, que ERP o un sistema sincronizado, al final se trata de que la información se concentre en un único sistema y que esté al alcance de todos (o de los que decidamos nosotros mediante perfiles de usuarios y permisos).
El primer acierto para dar orden al proyecto es formar un equipo director que conjugue la parte técnica (el informático) junto a la parte operativa (perfil de usuario avanzado y con visión general), a efectos de determinar que es lo que se necesita a nivel muy general y empezar la búsqueda de posibles soluciones existentes en el mercado.
A nosotros nos costó bastante decidirnos pues se trata normalmente de inversiones importantes y no te quieres equivocar. Es importante que encaje en nuestro presupuesto, pero además hay que valorar debidamente que existan empresas u organizaciones de nuestro sector que ya lo utilicen (al final los de un mismo sector hacemos cosas parecidas y eso se nota) y, por último, te da bastantes garantías el que tengan una buena cartera de clientes por tu zona geográfica (a efectos de servicios de asistencia futuros).
Pero los factores de orden más importantes en estos proyectos son los internos y, muy especialmente, los enfocados a solicitar al equipo los requerimientos que van a necesitar que cumpla el sistema (yo quiero que me avise cuando alguien no ha pagado en plazo, yo quiero que me llegue un mensaje si hay un donativo mayor de 300.-€, yo quiero que el listado salga ordenado por fecha de entrega, ……) y las acciones previstas de formación de usuarios para que el sistema se utilice de forma adecuada.
En el primer aspecto, definición de alcance y requerimientos, sólo hay una verdad sagrada: No se puede dar “barra libre” para que la gente pida, pida y pida, por que las personas tenemos por costumbre el pedir, y la sensación de que la informática todo lo puede (y es cierto pero nos solemos olvidar que a un coste muy alto tanto económico como operacional). A nosotros nos fueron muy bien unas jornadas de “mentalización” sobre lo que implicaba el proyecto y donde explicamos al equipo que un proyecto tan ambicioso va por partes y que de inicio no podemos abordar todos los automatismos que nos gustarían y que ya habrá segundas y terceras fases donde ir incorporando mejoras (cosa además totalmente cierta pero con la ventaja añadida de que los usuarios ya tienen experiencia en el sistema y no piden cosas a ciegas sino con bastante más lógica)
¿Dónde ponemos el límite de los requerimientos? Pues en lo imprescindible para la operativa y en todo aquello que se pueda hacer con el estándar del sistema (es decir mediante parametrización y no con desarrollos o programación específica). Esto debería ser un dogma durante esta fase del proyecto, pues cualquier cosa que se sale del estándar supone un incremento sustancial del presupuesto y un problema futuro cuando haya que abordar cualquier actualización o mantenimiento especial del sistema.
Quizá la sorpresa con la que no contábamos fue en el esfuerzo para poner orden en la utilización del sistema por parte de los usuarios. Prepárense porque la sensación es que pasar a compartir la información en un mismo sistema es mucho más costoso a nivel de aceptación personal que, por ejemplo, el paso de la gestión manual a la gestión informática de la información que se produjo en los ochenta y noventa del siglo pasado. Parece que todo el mundo entiende que su información va a ser “maltratada” por el resto de usuarios y tiende a protegerla de forma vehemente.
En este sentido no queda otra que no poner si no “imponer” el orden. La información se ha de rellenar si o si según las normas establecidas (no puede ser que uno ponga el dato del teléfono fijo en el campo del móvil, o de que el poner el código postal del cliente sea una decisión del usuario, …) y además, como la informática todo lo puede, se ha de hacer público quien está usando correctamente el sistema (y , por tanto, ayudando a sus compañeros) y quién no lo está usando correctamente ( y por tanto perjudicando a toda la organización). En el caso que nos ocupa, algún jefecillo que presumía inicialmente de estar por encima de las normas tuvo que dar cursos acelerados del sistema para demostrar que no era el “pardillo” que parecía en un inicio.
Dejaremos los temas de implementación del sistema, los listados e informes, los perfiles de usuarios, la parametrización , etc para otra ocasión, que no conviene asustar.
ACTUALIDAD | Blog