Diario de un proyecto

Diario de un proyecto tecnológico

En este artículo voy a explicar de forma cronológica todos los pasos seguidos durante un cambio tecnológico muy importante del cual he sido actor principal.

Todo responsable de departamento de tecnologías de la información puede verse inmerso en un cambio tecnológico grande en su empresa, por este motivo voy a explicar mi experiencia personal en un proyecto.

Concepto de proyecto

La idea del proyecto consistía en hacer un cambio tecnológico en 3 áreas distintas: área de sistemas, ERP+CRM y herramientas de movilidad. A partir de este esquema lógico voy a explicar cronológicamente los pasos seguidos y las decisiones tomadas con sus discrepancias o opiniones.

Gráfico resumen 3 áreas cambio tecnológico

En este diario se pretende explicar cada una de las siguientes etapas del proyecto:

Gráfico de resumen de las etapas de un proyecto tecnologico

Diario cronológico eventos

Agosto año 1: Inicio proyecto

- Se inicia el proyecto.

- Durante las primeras semanas de agosto el departamento de gerencia me transmite las necesidades de hacer un cambio tecnológico en la empresa para poder cumplir los objetivos de consolidación y expansión de la empresa, para los próximos 5 años.

- Se empieza durante este mes a recabar todas las necesidades o requerimientos de la empresa, en todos sus departamentos. La realización de

- Se decide empezar a buscar en el mercado productos que puedan encajar con las necesidades de la empresa. En esta búsqueda nos centramos principalmente en 2 áreas: encontrar productos que gestionen ERP y CRM, y productos que gestionen las herramientas de movilidad para 3 departamentos: reparto, ventas y servicio técnico.

Septiembre año 1: Búsqueda de productos CRM y ERP

- Empezamos la búsqueda con productos que gestionen CRM, para cumplir las necesidades del departamento comercial, que son una parte fundamental del negocio de la empresa. En esta búsqueda contactamos con empresas que distribuían los siguientes productos CRM: MS Dynamics CRM, Salesforce, CRM on-demand, Sugar VTiger.

- Empezamos a tener contacto con empresas que suminstran estos productos. Hay que puntualizar que antes de llegar yo a la empresa, ésta tenía instalada VTiger(CRM gratuito) pero dejó de funcionar sospechosamente de la noche a la mañana y se quedó en el olvido durante muchos meses. Nos centramos entonces en productos más robustos, vimos como Sugar era otro CRM gratuito y otros de pago como Salesforce, CRM on-demand o MS Dynamics CRM.

- Salesforce nos ofreció 1 mes de prueba del producto, cosa que aprovechamos para definir exactamente las necesidades de la empresa con un CRM, ya que Salesforce es un CRM vía Internet, como software como servicio (SaaS), es decir pagas una cuota por usuario y mes. Dicho queda que la cuota nos pareció abusiva, fué una de las causas de su descarte final. Usando Salesforce pudimos definir unos requerimientos finales para el CRM incluso cómo debería ser la interface de usuario para que los comerciales se sintieran cómodos. Cabe destacar que Salesforce es una herramienta muy parametrizable y adaptable a los requerimientos del usuario (en próximos artículos explicaremos este producto con más detalle).

- Nos entrevistamos con empresas que parametrizaban a tu gusto tanto Sugar como Vtiger, pero las descartamos debido a la gran dependencia con el partner y a que el estándar de estos CRM no se ajustaba a nuestras necesidades reales.

- Nos centramos entonces en otro producto de oracle, CRM on-demand, otro CRM de software como servicio, aunque daban la opción de tenerlo on-premise, es decir instalado localmente. Este CRM era muy parecido a Salesforce y también totalmente parametrizable, sus costes eran un poco inferiores a Salesforce. Lo añadimos a la lista de opciones.

- Entre medias de Salesforce y CRM on-demand, contactamos con varios partners de Microsoft a través de su web para poder reunirnos y ver el producto de MS Dynamics CRM. Al final fueron 3 partners los que nos visitaron. Durante varias reuniones llegamos a la conclusión que no tenía sentido separa el CRM del ERP , ya que el CRM debía de acceder a mucha información que poseía el ERP . Una de estas consultorías (partner de Microsoft) que nos visitó nos recomendó según nuestras necesidades el uso del módulo del CRM integrado dentro del ERP MS Dynamics NAV.

- Empezamos entonces una nueva etapa, la de unir dos necesidades ERP y CRM en una sola solución integrada. Empezamos a explorar el mercado en busca de ERP y nos topamos con los siguientes: MS Dynamics (AX y NAV), SAP (All-in-one y Business One), Sage (X3 y Logic Class), Nexus, ERP Marinos y otros que se pusieron en contacto directamente con nosotros (en próximos artículos explicaremos estos productos con más detalle).

Octubre año 1: entrevistas con partners de ERP

- Empezamos con reuniones con muchos partners, para poder localizarlos nos fuimos primero a la web de Microsoft, SAP y Sage, y escogimos partners certificados y locales, aunque algunos de ellos su sede principal estuviera fuera.

- Empezamos realizando las entrevistas de conocimiento básico del producto, mediante presentaciones y demostraciones. Vimos claramente que la opción de unir ERP+CRM en un único producto integrado, era la decisión más correcta.

- El ERP Marinos de la empresa Inology nos pareció un buen producto, pero creemos que no se ajusta a las necesidades de nuestra empresa, principalmente porque es un producto muy estándar, aunque se puede parametrizar bastante, no sería suficiente e implicaría costosos desarrollos. Este producto lo consideramos bastante caro. Cerca de 130.000€ su implantación.

- El ERP Nexus de la empresa SIE, es el actual ERP que tenemos en la empresa. Decidimos darle un voto de confianza y analizar las nuevas versiones (7.0 y 8.0) para ver si encajaban con las necesidades de la empresa. Ciertamente que el producto en la versión 8.0 ha evolucionado mucho, sobretodo visualmente, aunque el trasfondo sigue siendo el mismo y con las mismas limitaciones. Descartamos seguir su evalución.

- Durante este mes vimos también presentaciones de otros ERP más “humildes” que por respeto tratamos de igualdad con los otros. Obviamente no cumplían ni por asomo las necesidades básicas de la empresa ni eran parametrizables.

- En este mes empezamos a ver principalmente las soluciones de Microsoft y de SAP, probablemente las dos empresas con soluciones ERP más grandes del mundo. Empezamos con el mayor partner de SAP en España, la empresa INSA, que nos propusieron inicialmente la solución SAP Business-one. Hicimos unas sesiones para ver la demo del producto y otras para darles los requerimientos de la empresa. Nos presentaron una primera propuesta que analizamos.

- Nos entrevistamos con 8 consultorías que ofrecían sus servicios para implantar ERP de Microsoft, MS Dynamics NAV, vimos varias demos del producto, tanto en su perfil clásico como el orientado a roles. Nos pareció un muy buen producto.

Noviembre año 1: entrevistas con partners de ERP, definición área de sistemas y partners de movilidad

- Seguimos durante este mes entrevistándonos con los partners tecnológicos relacionados con el producto MS Dynamics NAV. Junto con estos partners empezamos también a definir cómo tenía que ser el área de sistemas para poder soportar las nuevas necesidades estructurales de la empresa.

- En el área de sistemas se empezó a discutir sobre posibles esquemas, al final se decidió por apostar por la virtualización y se analizaron dos productos: HyperV y VMware. En el área de sistemas se apostó por un esquema con consolidación (virtualización) y disponibilidad (ver artículos de virtualización en este blog). Es importante destacar el tema de disponibilidad, ya que para obtener porcentajes altos de disponibilidad la inversión se dispara, con lo cual, partiendo de nuestro negocio y analizando los escenarios posibles en fallos de disponibilidad se decidió optar por una solución en relación disponibilidad-precio-beneficios. Se escogieron 2 máquinas fisicas para soportar 5 máquinas virtuales con alta disponibilidad, por 1 cabina de fibra de almacenamiento, por 1 dispositivo de backup de librería, por 1 firewall de Cisco para gestionar VPNs, y varios switchs de core y de acceso. El presupuesto en esta área asciende a cerca de 60.000 euros.

- Empezamos a atacar también el tema de las herramientas de movilidad. Definamos primero este concepto. Se pretende dotar a varios departamentos de la empresa, como por ejemplo reparto y servicio técnico, de una herramienta de movilidad para gestionar el día a día de su trabajo. Para un técnico por ejemplo, para gestionar todos sus partes de trabajo y toda la información que necesite. En concreto, nos entrevistamos con 4 empresas: Antay Mobile Solutions, JSV, ExpandIT y un partner de Microsoft que ofrecía Mobile Solutions (en próximos artículos explicaremos estos productos con más detalle).

- Vimos diferentes demos de estas herramientas de movilidad, todas ellas eran muy parecidas aunque hubieron 2 que resaltaron por encima de las otras: Antay Mobile Solutions y ExpandIT. Estas dos soluciones ofrecían productos muy potentes, cubrían prácticamente el 90% de nuestras necesidades, y el otro 10% en gran medida se podían parametrizar sin muchas complicaciones. Estas dos herramientas daban también un valor añadido como las localizaciones automáticas (gestión de flotas por ejemplo) o la gestión de planificación de averías para el servicio técnico, muy destacado.

Diciembre año 1: reflexión

- Llegados a este momento, con muchísima información en las 3 áreas del proyecto: área de sistemas, ERP+CRM y herramientas de movilidad, nos dedicamos a una reflexión interna. Teníamos ante nosotros la decisión de hacer una primera selección de productos y de partners. Debíamos notificar qué partners serían finalistas y cuáles quedaban descartados. Óbviamente este es un momento complicado, es muy díficil descartar a una empresa y darles motivos, ya que siempre ellos te lo debaten, están en su derecho, yo haría lo mismo. Alguna de estas empresas no se lo tomó bien y solicitó más reuniones para poder demostrar que eran válidos para dirigir el proyecto. La decisión estaba tomada, y debíamos seguir avanzando y quemando etapas de decisión.

- Decidimos escoger 5 partners finalistas: 3 de ellos ofrecían MS Dynamics NAV, 1 ofrecía SAP Business-One y otro SAGE Logic Class. Todos ellos ofrecían herramientas de movilidad (las escogidas fueron 3: Antay Mobile Solutions, JSV y ExpandIT, descartando las herramientas de Microsoft, que posteriormente han sido descatalogada) y ofrecían presupuestos para el área de sistemas dentro de las premisas marcadas.

- Llegó Navidad y con ello algún detalle de los partners, es lo bueno de ser el responsable.

Enero año 2: reuniones con partners finalistas

- Llegado nuevo año procedimos a reanudar las reuniones con los partners finalistas para empezar a proporcionales más información acerca de nuestros requerimientos funcionales. Realizamos un documento donde se mencionaban todos los requerimientos funcionales de la empresa, sin entrar en mucho detalle, ya que muchos de ellos se consideran confidenciales, y creemos que sólo serían revelados a los 2 partners finalistas para poder concretar y presentar un presupuesto final.

- En esta segunda fase de reuniones pretendíamos analizar con detalle el partner, no sólo como trabaja y qué productos y/o servicios ofrece, sino también cómo son las personas que están detrás del partner, cómo es la empresa en sí y qué valor añadido nos puede dar.

- Durante este mes conseguimos definir ya cual era el esquema del área de sistemas, definir la mayoría de los requerimientos funcionales en el área de ERP y CRM, y definir también cómo tenía que funcionar las herramientas de movilidad, todo este trabajo fué gracias también a la experiencia de todos los partners finalistas.

Febrero año 2: nueva visión dentro de la empresa

- Sabemos que las empresas estan vivas, la nuestra no es una excepción, en nuestro caso se están profesionalizando todas las áreas, por este motivo también se me contrató a mi. La empresa decidió añadir un nuevo actor al proyecto y a la empresa. Se contrató a una persona que haría las funciones de “controller”. Esta persona es un experto en implantación y gestión de procedimientos, y tiene muchos años de experiencia en implantaciones de proyectos tecnológicos. Esto provocó un giro de 360º al proyecto…

- Esta persona detectó que el análisis de requerimientos funcionales que había realizado yo los últimos meses no era suficiente para concretar presupuestos con los partners. Razón tiene, es un análisis previo o superficial. Gracias a su experiencia y conocimientos durante este mes nos dedicamos a realizar un análisis de requerimientos profundo, el mismo que realizan todas las consultorías durante la fase de análisis antes de abordar cualquier proyecto. Haciendo esta etapa queríamos que los presupuestos fueran cerrados y sin desviaciones significativas, que es uno de los mayores riesgos en un proyecto tecnológico.

- Esta persona también quiso dar otro enfoque al proyecto, basado en sus vivencias personales, sugirió la entrada de una nueva empresa para añadir a la lista de finalistas. Esta empresa desarrolla software a medida.

Marzo año 2: software a medida vs. software estándar parametrizable

- El título lo dice todo. Durante los últimos días de Febrero y las semanas siguientes de Marzo, empezamos una discusión interna muy grande. ¿Debíamos hacer un proyecto a medida o desarrollar un proyecto con un estándar parametrizable? Esta hipótesi nueva ocasionó grandes disputas internas, reuniones interminables, algún que otro rifirrafe y sólo consiguió enriquecer el conocimiento de los presentes y el de la empresa, la decisión final debía ser consensuada (ver artículo software a medida vs. software estándar).

- ¿Cuál fué mi postura? Como responsable de tecnologías de la información de la empresa, basándome en las reuniones con los partners de los últimos 8 meses, los requerimientos funcionales de la empresa y mis conocimientos tecnológicos, creía y creo que es un error realizar un proyecto de software a medida, si existe ya en el mercado un producto estándar parametrizable que cubra las necesidades. Aquellas necesidades que no cubran deberán desarrollarse. ¿Cuál es el coste de estos desarrollos? ¿Es superior al coste de desarrollar un producto 100% a medida? Muchos interrogantes y algunos difíciles de responder. Pero en esta decisión no solo pesaba el tema tecnológico, habían otros aspectos fundamentales que valorar: relación con el partner, costes proyecto inicial y anual, coste proyecto para expansión empresa a nivel nacional, …

- En el plano tecnológico no había dudas, una solución a medida no era lo ideal. Principalmente porque provocaba una alta dependencia del partners, muchos costes ocultos provocados por el hecho de ser a medida (cualquier cambio implica un coste). Me permito el lujo de poner un listado de cosas a tener en cuenta para decidirse por un producto a medida o por un estándar parametrizable:

  • Relación con el partner:
    • SW a medida: más estrecha al tratarse de un cliente importante y desarrollo muy acotado y definido por la empresa
    • SW Estándar y parametrizable: se parte de un estándar probado y testado. La relación es más fluida. Se estrecha al tratar los desarrollos a hacer (verticalizaciones).
  • Dificultad de encontrar otro partner que gestione el proyecto en caso de problemas (mala relación, desaparición del partner, …)
    • SW a medida: dificultad alta. Software a medida difícil de gestionar por el tamaño y el diseño, normalmente no siguiendo uno estándares.
    • SW Estándar y parametrizable: dificultad baja. Existen decenas de partners capaces de gestionar el software.
  • Costes ocultos provocados por cualquier cambio que se proponga
    • SW a medida: no son conocidos a priori. Irán apareciendo en función de las nuevas necesidades de la empresa.
    • SW Estándar y parametrizable: muchas mejoras no tendrán coste ya que vienen integradas en el software estándar pero que actualmente no se usan.
  • Integración con otras herramientas (Ejemplo: herramientas de colaboración, portales web, office, telefonía IP, herramientas de movilidad, …)
    • SW a medida: nula. No existe la integración nativa con otras herramientas. Esto implica un coste elevado al querer relacionarnos con otras herramientas. Tarde o temprano esto sucederá.
    • SW Estándar y parametrizable: normalmente tiene integración con la mayoría de herramientas conocidas existentes. Ejemplo el ERP MS Dynamics NAV tiene integración nativa con: Offic, con Sharepoint, con portales web, herramientas de movilidad, …
  • Gestión y explotación de la información:
    • SW a medida: limitada, previamente acotada en el análisis. Normalmente el software a medida sólo se puede explotar información con informes, que implican sobrecostes al proyecto porque se tienen que desarrollar.
    • SW Estándar y parametrizable: muchos de estos estándares llevan incorporadas herramientas muy potentes de gestión de explotación de la información. De fácil uso y los usuarios pueden generan informes de muchas maneras, y sobretodo obtener informes dinámicos (tienen trazabilidad).
  • Costes de crecimiento/expansión en usuarios:
    • SW a medida:  no hay costes de licencias, el software es a medida y normalmente propiedad de quien lo crea. Las limitaciones en crecimientos quizá existan en el área de sistemas.
    • SW Estándar y parametrizable: existen unos costes de licencias inaludibles. Aunque es cierto que existen aplicaciones web para limitar estos costes (portales de acceso al trabajador), aunque estas soluciones eviten los costes de licencias implican un acceso a funcionalidades muy básicas del software. Si se quiere el acceso a todo implica un desarrollo y un coste elevado.
  • Conocimientos del sector de la empresa por parte del partner: es un punto importante decidir en función del conocimiento del partner del sector de nuestra empresa. Sus consejos siempre son bienvenidos. Nos pueden proporcionar un know-how importantísimo al proyecto.
  • Duración del proyecto:
    • SW a medida:  normalmente la duración es mucho mayor que un software estándar. Y muchos de estos proyectos nunca se acaban porque al ser a medida siempre se quiere algo más.
    • SW Estándar y parametrizable: duración acotada inicialmente. Siempre hay desviaciones provocadas por un mal análisis de los requerimientos en la etapa de análisis hecha por el partner y la empresa nada más empezar el proyecto.
  • Otras consideraciones: inversiones capaces de hacer el partner en software, capacidad del partner para proponer mejoras, capacidad tecnológica del partner, compromiso fidelización del partner, recursos humanos del partner, partner consolidado en el mercado, grado de implicación del partner, importancia de la empresa para el partner,…

Abril año 2: decisión final y negociaciones

- Después de muchas reuniones, muchas horas de disputas, intercambio de opiniones, … Se tenía que dar un paso al frente. El proyecto estaba en una fase absoluta de bloqueo, principalmente porque dentro de la empresa se habían creado dos grupos: unos defendía el software a medida como mejor solución y otros el software estándar parametrizable. Al final, yo como responsable di un paso al frente, acepté que la mayoría de gente defendía la solución del software a medida (principalmente por un tema puramente económico de costes de licencias en expansión de usuarios) y presenta una primera propuesta de proyecto.

Diagrama proyecto tecnologico

- Se decidió proponer un proyecto tecnológico con partners diversificados. Con esta decisión se pretende satisfacer a toda la opinión de la empresa, vamos es una decisión correctamente política. En la parte tecnológica se intenta que quién gestione el área de sistemas sea una empresa especializada y no el mismo partner que desarrolla el software a medida. En la parte de movilidad, se cree conveniente escoger un partner con una herramienta estándar parametrizable que cubre el 95% de las necesidades de la empresa y nos permite tener a una empresa con más de 10 años en el sector de movilidad.

- Esta decisión tiene algunos puntos interesantes que a continuación me gustaría comentar:

  • Partners diversificados: se pretende qué cada uno haga lo que sabe hacer. Veremos si hace sucede.
  • Diversificación de riesgo: se pretende que si el partner a medida falla, limitar el máximo el error en el proyecto. Esperemos que esto no suceda.
  • Dificultad de entendimiento: es evidente ver, que al tener 3 partners distintos la comunicación y gestión será complicada. Existe el riesgo que unos se culpabilicen a otros cuando haya problemas. Intentaremos desde nuestro departamento ser los gestores de estas relaciones.
  • Dificultades tecnológicas en integración: debemos definir perfectamente todas nuestras necesidades y que los partners hagan lo mismo, para evitar problemas de integración entre los 3 niveles del proyecto. Un caso sería tener problemas de integración de las herramientas de movilidad estándares con el ERP a medida. Debemos evitar estos problemas con un buen análisis inicial.

- Las últimas 2 semanas de Abril las dedicamos a negociar con cada uno de los 3 partners escogidos. Intentamos ajustar todos los presupuestos, con diferentes técnicas de negociación, aunque no hace falta, en los tiempos que vivimos los partners necesitan proyectos de forma urgente y se adaptan a lo que haga falta. La parte más complicada de ajustar fué el área de sistemas, ya que muchos precios tenían ya descuentos del fabricante que son difíciles de rebajar aún más. Revisamos el tema del software, las licencias de Microsoft principalmente (ver artículo en este blog), para no dejarnos ninguna y analizar con detalle si podíamos ahorrarnos alguna.

Mayo año 2: nunca digas se acabó

Teníamos decidido que el partner responsable del cambio en la movilidad tenía que ser un partner especializado, por las muchas ventajas que eso conlleva, principalmente porque es una herramienta testada anteriormente y tecnológicamente validada. Pues bien, debido a que el ERP+CRM debe de ser un proyecto a medida, al no existir los conectores entre ERP+CRM y las herramientas de movilidad, esto conlleva un sobrecoste. Este sobrecoste y el coste de licenciamiento de la movilidad estándar provocó un cisma en gerencia. Nuestro proyecto de expansión no podía permitirse el lujo, en los tiempos que corren, de gastarse unos cuantos euros en licencias. Por este principal motivo, se decidió que las herramientas de gestión TAMBIÉN serían desarrolladas a medida por el mismo partner que desarrolla el ERP+CRM.

Si os fijáis, las decisiones son muy parecidas a las que se tomaron tiempo atrás, cuando se descartó el ERP Estándar por uno a medida. Como es obvio, yo como responsable del proyecto en la parte tecnológica, no estaba de acuerdo antes, ni lo estoy ahora. Creo que es un error desarollar una herramienta de movilidad desde cero, porque este sector es muy especializado, y existen problemas en las comunicaciones que se tendrán que solucionar de una forma u otra. Veremos con el tiempo si el partner escogido está o no a la altura de la empresa.

Durante este mes estuvimos discutiendo cómo abordar las decisiones en movilidad, pero también seguimos erre que erre con el proyecto del área de sistemas (infraestructura). Se daba por cerrado este capítulos meses atrás, pero nada de nada. La compañía seguía recortando gastos por doquier, y fué prácticamente imposible defender mi propuesta de infraestructura (valorada en unos 49.000€), frente a otra propuesta de mínimos (valorada en unos 34.000€). Para que tengáis una idea os presento las dos propuestas a grosso modo:

- La propuesta adecuada, valorada en 49.000€, constaba principalmente de 2 servidores HP Proliant ML380 con 18GB RAM cada uno, con una cabina de almacenamiento MSA2310i (iSCSI) con 9 discos de 300GB y 2 de 1TB y 2 switch Procurve 2610. También se compraba un nuevo firewall para mejorar en seguridad y para gestionar VPNs, y un dispositivo de backup nuevo, Autoloader HP Storage Works LTO4. La principal ventaja de esta estructura era la de montar una granja de 2 servidores físicos con 7 servidores virtuales mediante VMware. Creo firmemente en esta estructura, permite a la empresa una continuidad de negocio adecuada a las necesidades, permite el arranque por parte de nuestro departamento TI de nuevos proyectos como VDI, Blackberry server, página web clientes, …

- La propuesta de mínimos, valorada en 34.000€, constaba principalmente de 2 servidores HP Proliant ML350 con 20GB RAM cada uno, con 6 discos cada uno de 146GB a 15K. 2 switch Procurve 2610. También se compraba un nuevo firewall para mejorar en seguridad y para gestionar VPNs, y un dispositivo de backup nuevo, Autoloader HP Storage Works LTO4. En este escenario de mínimos se elimina la cabina y la virtualización con VMware, se virtualizarán 3 servicios con HyperV (reducción costes licencias), y principalmente se consigue una reducción drástica en licenciamiento de Windows al comprar Windows SBS 2008 (nos ahorramos 6.000€), ya que este software (ver artículo sobre SBS) lleva consigo licencias de: Windows Server 2008, Exchange 2007, SQL Server 2008, WSUS y Sharepoint 3.0. Este escenario de mínimos tiene muchas desventajas como: tener un paquete de licenciamiento de Windows rígido (limitaciones del SBS), poca disponibilidad ni continuidad de negocio si cae algún servicio.

Estas dos propuestas fueron presentadas y discutidas durante 2 semanas, incluso se solicitó a los partners del área de sistemas que debatieran y defendieran estas propuestas. Al final se votó, linda democracia (¬¬), y se decidió por 4 votos a 2, que se escogía la opción de mínimos, valorada en 34.000€. Segundo fracaso mío en la empresa. Digo fracaso, porque durante estos últimos meses he sido incapaz de defender mi proyecto, he sido incapaz de poder explicar concisamente y convencer a personas con un conocimiento nulo (gerencia), casi siempre todo se reducía a costes. Esta palabra me tiene frito. Es un mal en muchas empresas, el departamento TI se ve como un GASTO y no como una INVERSIÓN. Mi idea de proyecto se basaba en la propuesta adecuada (49.000€), porque quería alinear al máximo el departamento TI con la empresa. Quería que este departamento pudiera proporcionar nuevas soluciones a la empresa y a la vez interviniera en todos los flujos de negocio y departamentos posibles, quería al fin y al cabo, demostrar que SI existe un ROI (retorno de inversión) en estos proyectos.

Durante este mes, también se empezaron a desarrollar los calendarios del proyecto, se hicieron también dos reuniones para ir avanzando en el proyecto del CRM, primer prototipo que queremos lanzar para potenciar el departamento comercial. En estos calendarios se marcaron ya fechas concretas o hitos a conseguir por parte de nuestros partners y por nuestra parte. Los objetivos son:

  1. Poner en marcha la nueva área de sistemas (infraestructura) en Julio
  2. Poner en marcha el CRM en Agosto
  3. Poner en marcha las herramientas de movilidad en Septiembre-Octubre
  4. Poner en marcha el nuevo ERP en Enero

Junio y Julio año 2: formalizando contratos y reuniones

Los dos siguientes meses se definieron como meses de reuniones intensas para cerrar por un lado los contratos y para empezar ya a tomar requerimientos para el CRM. Vamos a explicar estos dos conceptos:

- Formalización de contratos: este es un aspecto muy importante de un proyecto tecnológico. Se tiene que tener claro que el partner es eso, un partner, y lo importante es la empresa. Se tienen que definir 2 contratos: contrato del proyecto y contrato de protección de datos. El primer contrato se basa principalmente en detallar todo lo posible, todas las tareas que tiene que hacer el partner durante el proyecto que iniciaremos, cuanto más detalle mejor. También se añaden una cuantas cláusulas importantes. La fundamental y la que crea más controversia en el partner son las sanciones en caso de incumplimiento de contrato, en este aspecto hay que insistir y llegar a un punto de acuerdo.

- Requerimientos CRM: empezamos a hacer bastantes reuniones para recopilar información sobre cómo tenía que ser el CRM y cómo debía de funcionar. En meses anteriores había recopilado una gran cantidad de información sobre diferentes productos CRM, esto ayudó a poder diseñar el CRM de forma más estándar. El objetivo inicial era tener un prototipo de CRM para el mes de Agosto, y durante el periodo vacacional poder hacer pruebas de funcionamiento y mejora con algún comercial de la empresa.

Agosto año 2: subvenciones, vacaciones y sin CRM

El mes de agosto suele ser un mes difícil, mucha gente tiene vacaciones y es complicado poder programar cosas. Esto y que los requerimientos del CRM empezaban a causar algún dolor de cabeza, provocó el primer retraso del calendario, nuestro objetivo (para mi punto de vista no realista) de conseguir un prototipo de CRM en Agosto se fué al traste. Deberíamos esperar hasta Septiembre para poder empezar a ver alguna que otra pantalla del futuro CRM.

Otro tema importante son las subvenciones. Una vez que en febrero empezamos a concretar presupuestos, desde gerencia se me pidió el reto de buscar subvenciones para el proyecto. Después de muchos días buscando y buscando, encontramos una subvención accesible para nuestro proyecto. Primero decidimos obtener información del préstamo ICO para empresas, para poder financiar el coste del proyecto sin intereses (podéis obtener más info en este link: Plan ICO). Encontramos mediante el CIDEM una subvención, dicha subvención agotaba el plazo de inscripción a finales de Febrero, esto provocó a que nos movieramos de forma muy rápida para intentar poder obtener algo. El CIDEM lanzó el plan INNO Empresa 2010, por el cual para proyectos de innovación tecnológica con importe superior a 100.000€ se pueden llegar a subvencionar un máximo del 50% de costes de servicios profesionales y de hasta un 15% de software/hardware. Este plan de subvenciones se gestiona a nivel de comunidad autónoma y existe un límite de importe. En nuestro caso partimos de un presupuesto de 140.000€ de los cuales solicitábamos casi 50.000€ de subvención. Debíamos ahora esperar hasta Septiembre para recibir la confirmación o denegación de las subvención y los importes.

Septiembre año 2: prototipo de CRM y subvención aceptada

Durante las primeras 2 semanas de septiembre empezamos a tener reuniones cada 2-3 días y empezamos a analizar ya el primer prototip de CRM. En dicho prototipo vimos ya cómo serían las futuras aplicaciones, su estilo visual, y cómo se usarían, la usabilidad de los usuarios. Cabe destacar que el CRM presentado no partía de cero, como inicialmente pensaba, la empresa de software a medida tenía ya para otro cliente un CRM hecho, cogieron este CRM y lo adaptaron al máximo a nuestras necesidades concretas. Yo pensé: “ya empezamos…”. Se paga por un software específico y se empieza usando uno de otro con adaptaciones, lo normal en software a medida para acortar plazos. Empezaron las primeras discusiones interesantes, sobre cómo tenía que ser el CRM, el responsable comercial de la empresa, el verdadero experto, empezó ya a dibujar cómo quería que fuera el producto, acotando ya su funcionamiento y configuraciones. A finales de mes obtuvimos ya el primer prototipo productivo del CRM, se empezó a montar en él la estructura de flujo de negocio que queríamos e incluso se probó en varios comerciales (pasado 1 mes estos aún no habían dicho nada referente al producto, señal que les interesa mucho a ellos y al responsable).

A finales de mes recibimos una llamada, era del CIDEM autonómico (en cada comunidad autónoma tiene un nombre, en Cataluña se llama Acc10.cat). Nos comunicaban que habían aceptado nuestro proyecto para ser subvencionado, y nos enviaron una documentación donde se nos informaba que se destinarían casi 40.000€ de subvención. Esta subvención no se da por adelantado sino se siguen los siguientes pasos:

1) Inscripción de la solicitud

2) CIDEM acepta o deniega la solicitud

3) A final de año se presentan las facturas del proyecto por el valor especificado y se presentan una serie de documentos explicativos

4) CIDEM acepta y valida estos documentos y entrega la documentación

En nuestro caso, ahora tocaba centrarnos en el desarrollo del ERP y CRM, y dejar este tema aparcado hasta Diciembre.

Octubre año 2: primeros módulos del ERP

Paralelamente al CRM empezamos a diseñar el futuro ERP. Durante los meses de Agosto, Septiembre y Octubre, se hicieron muchas reuniones internas en la empresa, para empezar a darle forma al futuro ERP. De estas reuniones internas se obtuvieron los diseños del futuro ERP para cumplir con los requerimientos específicos de la empresa. Esta informción se transifrió a la empresa de desarrollo de software y empezaron a proporcionarnos los primeros módulos del ERP para hacer nosotros pruebas: módulo de clientes, módulo de proveedores, módulo de contabilidad, módulo de seguridad, y algunos más. Obviamente como en el CRM, estos módulos no eran desarrollos específicos para nosotros, eran módulos de otros proyectos de esa empresa, adaptados a nuestras necesidades. Este punto a mi me empezó a molestar, porqué excusandose en el tiempo, el 1 de Enero del año 3, el ERP debe de estar en funcionamiento con sus módulos básicos para trabajar el día a día, ahorran en costes de desarrollo y nos desarrollan módulos del ERP adaptados. Por una parte mejor, ya que significa que dichos módulos han sido testados anteriormente por otros usuarios y empresas, y seguramente funcionen correctamente (habrá que verlo). Durante este mes se hizo también un paso importante en el proyecto, la primera migración de datos.

Todos sabemos que una migración de datos nos es sencilla. En nuestro caso partimos de un ERP con un gestor de bases de datos, SQL Server. Gracias en parte a mis problemas con este ERP, la migración ha sido bastante sencilla, la estructura de la base de datos no es complicada de entender, aunque esté mal distribuida y mal diseñada (el ERP en cuestión es Nexus). Hemos conseguido volcar las tablas de clientes, proveedor, artículos de forma satisfactorias, y más adelante haremos la migración definitiva.

Noviembre año 2: herramientas de movilidad y aplicaciones satélite

Un hecho es evidente, la fecha de 1 de Enero como fecha clave de inicio del proyecto cada vez está más cerca, y el proyecto lejos. Tenemos una ventaja en este sentido, hay muchos módulos como SAT, que no tiene poqué arrancar el 1 de Enero en su totalidad, ni muchos otros departamentos como reparto. Nuestra intención es arrancar el 1 de Enero (temas contables y fiscales) con el ciclo de facturación funcionando, con proveedores, clientes y artículos migrados, y con los ciclos básicos de funcionamiento de la empresa, principalmente los circuitos del día a día de la empresa. Esta labor no a sencilla, ya que heredamos una estructura y unos circuitos muy dañinos, y que por suerte los podremos eliminar de raíz.

Debido a la limitaciones de nuestro ERP, existen una gran cantidad de aplicaciones satélite (= aquella aplicación aparte del ERP que interactua con su base de datos, principalmente desarrolladas con .NET o Access) que se diseñaron para poder mejorar los circuitos de la empresa. Por ejemplo, generación automática de facturas/albaranes de venta de las PDAs de distribución, o listados de llamadas de clientes, etc. Estas aplicaciones son el día a día de la empresa, y son vistas por los trabajadores como parte del ERP, para mi son vistas como parches o chapuzas innecesarias.

Durante este mes tuvimos varias reuniones para explicar estas aplicaciones satélite en detalle, con ejemplos de listados en papel, y con diseño UML, para así facilitar la integración de estas aplicaciones en el futuro ERP (todas las aplicaciones deben de desaparecer, pero se integran como parte del futuro ERP aquellas que sean útiles). Mi acometido principal era crear un manual por cada aplicación, donde explicar con lenguaje UML el funcionamiento y diseño, para así poder facilitar las tareas a la empresa desarrolladora del software a medida.

Otro tema importante es la movilidad. Para el día de arranque del ERP, la movilidad debe de estar operativa. En nuestro caso la movilidad orientada al departamento de distribución-preventa. Dicho departamente se encarga de realizar los pedidos de los clientes. Por este motivo es importante que estén operativas las nuevas herramientas de movilidad para este departamento. Imaginemos que debemos de introducir 200 facturas diarias a mano con sus correspondientes detalles de línea… un infierno! Por este motivo este circuito debe de estar disponible para el arranque del ERP. En el futuro dotaremos al departamento de distribución de muchas más funcionalidades en movilidad, para que dispongan de mucha información y así puedan tomar decisiones.

Switch to our mobile site