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.

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

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 y 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.

- 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 (en breve se publicará un artículo sobre Windows SBS 2008) 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 año 2: formalizando contratos y reuniones

Switch to our mobile site