Atrapado por tu proveedor

 

Locked!

Es frecuente en el ámbito de los sistemas de información de gestión, el externalizar determinadas actividades o servicios como por ejemplo, por citar los más habituales, el mantenimiento correctivo y evolutivo de la aplicación (ERP, CRM, etc.) o la operación de las infraestructuras que soportan esas aplicaciones.

En el caso del mantenimiento correctivo y evolutivo parece lógico que sea el integrador que implantó la aplicación en cuestión el que luego se encargue de su mantenimiento, es decir  de implementar los cambios que en el ciclo de vida de toda aplicación son necesarios para que evolucione, tanto tecnológica como funcionalmente. Y si dicho integrador tiene las capacidades para ello, pues también se le suele encargar de la operación de las infraestructuras pues así la empresa, además de aprovecharse de las sinergias de ambas actividades, se ahorra los problemas típicos de responsabilidad compartida (el echarse las culpas el uno al otro cuando algo falla, dicho de forma menos elegante)

En esa situación, insisto que bastante frecuente, sucede también lo que los sajones, siempre tan ocurrentes a la hora de poner nombre a las cosas, llaman el miedo al Vendor Lock-In. Es decir, miedo a quedar (atrapado) en las manos del proveedor y que si la empresa quiere cambiar, por mal servicio por ejemplo, no pueda o los costes y riesgos lo hagan poco aconsejable.

Este Vendor Lock-In se puede manifestar en las siguientes situaciones:

  • Con el Producto: El proveedor es el dueño del producto, si cambias de proveedor tienes que cambiar de producto. Con el impacto que eso supone en la organización. Es lo que sucede en determinados modelos SaaS (Netsuite, Sales Force, EuHReka, SAP Business ByDesign, etc.)
  • Desarrollos y extensiones: Cuando sólo el proveedor (porque fue él el que lo desarrolló) tiene el conocimiento de verdad (no lo que está documentado) sobre los desarrollos y modificaciones/personalizaciones que se le hicieron a la aplicación en el momento de su implantación.
  • Datos: Cuando la empresa cliente tiene acceso restringido a las infraestructuras y depende del proveedor para que le entregue sus propios datos. Ocurre, en grado menor, cuando se externaliza la operación de las infraestructuras del sistema y por supuesto en modelos SaaS. Un caso extremo sería en un modelo de externalización de las operaciones o BPO, por ejemplo la nómina, donde el control último de qué datos hay en el sistema lo tiene el proveedor.

Es obvio, y de aquí este artículo, que las compañías deben intentar evitar esta dependencia extrema de sus proveedores y aunque cada caso tendrá sus particularidades y debería ser tratado de forma individualizada – se aceptan peticiones 🙂 – me atrevo a reflexionar en voz alta y exponer, para su debate, una serie de buenas prácticas al respecto.

 

(1) Negocia cuidadosamente las condiciones de salida en el momento de la venta del servicio.

Como le leí a no me acuerdo quien, la mejor manera de acordar los términos y condiciones de una separación es cuando te llevas bien con la otra parte. Y, creedme, hay pocos momentos donde te vas a llevar tan bien con tu proveedor como cuando está tratando de venderte algo. Este consejo también es aplicable a contratos prematrimoniales y a la constitución de una start up con más de un socio.

 

(2) Elabora un plan de riesgo desde el primer momento

No te asustes. Detrás de ese rimbombante nombre, básicamente hay dos cosas de sentido común:

  • Identifica los riesgos, es decir los elementos que te atarían a tu proveedor o harían más difícil su sustitución. Una check list inicial sería:
    • Software de base, producto, desarrollos  (fuentes) sobre los que no tengas el control y/o acceso directo
    • Conocimiento que no tienes: configuraciones, desarrollos, características de la instalación, …
    • Acceso a tus datos, posibles restricciones, si se comparte infraestructura con otras compañías, contraseñas, etc..
    • Compensaciones y condiciones de salida por rescisión de contrato
  • Para cada riesgo identifica medidas para mitigarlo
    • En el caso de desarrollos tener la propiedad intelectual de los mismos o al menos un compromiso de disponibilidad de los fuentes y objetos en caso de ruptura
    • En el caso de productos, tener preferencia sobre productos abiertos y si son cerrados que haya la máxima disponibilidad de otros proveedores que lo conozcan. No es lo mismo que el producto sólo lo conozca su fabricante/implantador a que lo conozcan e implanten muchos integradores
    • Con respecto a configuraciones y parametrizaciones, es en la fase de implementación cuando hay que adquirir el conocimiento sobre cómo se ha montado y se va a comportar el sistema, y dónde hay que tocar si se quiere que se comporte de otra forma.
    • Con los datos no se juega. Este punto es particularmente crítico en el caso de externalización de la infraestructura tecnológica y no digamos ya en un modelo SaaS. Es imperativo tener bien atado, a nivel técnico, plazos y costes, como se van a recuperar los datos en caso de finalización del servicio.

 

(3) Ten previsto que todo va a cambiar

Incluir en el contrato con el proveedor, en la medida de lo posible, la opción de poder renegociar o revisar las condiciones o términos de separación. Un entorno cambiante puede hacer obsoleto cualquier acuerdo inicial.

 

(4) Gestiona la simetría de las condiciones de rescisión del contrato

No es lo mismo que el proveedor rescinda el contrato y te dé, por ejemplo 3 meses para que te vayas, que al revés. En este tipo de contratos, el esfuerzo y coste (no sólo monetario)  que supone a una empresa cambiar de proveedor puede ser mucho mayor que el del proveedor si pierde el cliente.

He vivido alguna situación, de la que no voy a exponer aquí sus detalles obviamente, donde en el contrato no se especificaba para nada el tiempo de preaviso que debía dar el proveedor si rescindía el contrato unilateralmente (en caso contrario sí se especificaba). Automáticamente, en ese caso, se aplicaban, por simetría, las condiciones de si era el cliente el que rescindía el contrato. Pues resulta que si para implantar la aplicación se tardó, digamos, 12 meses,  el tiempo de preaviso previsto era de 3 meses. Os podéis imaginar el problema enorme que tendría la empresa cliente si, en un caso extremo, el proveedor le da los tres meses a la empresa y ésta tiene sólo ese tiempo para poner en marcha un sistema equivalente.

Una buena regla es que el tiempo de preaviso por parte del proveedor sea al menos el tiempo que se tardó en poner en marcha el sistema más el tiempo estimado  en buscar un proveedor y en cerrar un contrato con él.

 

(5) Prepárate ya durante el proyecto de implantación de la aplicación

Todo lo anterior no lo dejes para el final. Durante el proyecto de implantación tienes ya que actuar: empezar a negociar los términos del servicio posterior, asegurar que tu equipo conoce el sistema hasta donde quieras tener el control, asegurar la propiedad intelectual o el acceso a desarrollos, etc. Es durante la implantación cuando mejor se pueden ir identificando los riesgos y construyendo las medidas que te permitirán controlarlo.

 

Me encantaría conocer vuestras opiniones o experiencias. Estáis invitados a exponerlas en los comentarios. Gracias

 

CapEx, OpEx…debate a superar

Antonio Valle, desde el congreso que el IT Service Management Forum está celebrando en Barcelona,  lanzaba una serie de tweets de aquellos que encienden debates en los profesionales de las TIC… e inspiran posts como este 🙂

CapEx como algo bueno vs OpEx como algo malo … innovación y gasto (OpEx), lo nuevo no tiene porqué considerarse como inversión (CapEx) siempre, … son reflexiones interesantes y que dan mucho de sí, no lo dudo… pero mi posición es que los profesionales de las TIC no debemos dejarnos arrastrar a estos terrenos “financieros”.

No debemos gastar ni una neurona en entrar en debates de si las TIC son una inversión o un gasto, o si se puede innovar con gasto, … en mi opinión es un debate terminológico y en un terreno de juego donde los profesionales de las TIC no tenemos mucho que ganar y sí mucho que perder (y a la historia me remito), y que proviene más de una necesidad metodológica contable (o de otra índole más prosaica)  que de una necesidad propia del terreno TIC.

Pues frecuentemente, el que un coste en TIC te lo quieran poner los financieros en CapEx (inversión) o en OpEx (gasto)  responde más a una estrategia fiscal,  o de reporting interno,  … en definitiva de dar los números de una determinada manera, que de un criterio contable estrictamente. Por ejemplo, en un caso real que conozco de primera mano, los costes de una implantación de un ERP se imputaron una parte en CapEx y otra en OpEx, simplemente para llegar a cumplir un determinado ratio financiero que imponía la empresa matriz.

Lo que propongo pues, es que, en la ecuación beneficio=Ingreso-Coste, no nos tenemos que dejar situar en el término Coste (que es al fin y al cabo lo que supone la discusión CapEx vs OpEx) y buscar llevar el debate al término Ingreso… o beneficio, valor,… como se le quiera denominar. Y soy consciente de que ese movimiento no es trivial. Y no lo es porque tenemos entonces que entrar a demostrar con números, a cuantificar, los beneficios que aportan las TIC’s.

Cuantificar, no sólo en términos de reducción de costes de operaciones (donde entonces volvemos a irnos al otro lado de la ecuación) sino de mejora de eficacia (no de eficiencia que entonces caemos otra vez), de posibilitar oportunidades de mejora del servicio o experiencia de nuestros clientes, de incrementar el alcance de nuestros comerciales por darles mejor información y más rápidamente, de poder facturar más por servicios de más valor, por ser más competitivos al ser más rápidos y ágiles que la competencia en servir nuestros productos, … Pero, ¿cómo se cuantifica eso en euros?

 

Encuesta % presupuesto IT sobre ventas

¿Son importantes las TIC para la competitividad de las empresas?, ¿son sólo un “gasto inevitable” o una “inversión necesaria”?… grandes preguntas a las que no siempre se les dan grandes respuestas.

Sin grandes pretensiones, he creado una encuesta para conocer de forma rápida y estimada que es lo que se están gastando las empresas en TIC, pero no de forma absoluta – que dificultaría la comparación – sino en forma relativa, concretamente en relación a las ventas.

Podéis contestar a la encuesta aquí

Dejaré pasar un tiempo prudencial antes de abrir el debate en otro post sobre lo que se puede concluir de los resultados. Muchas gracias por participar.

Y el resultado en tiempo real (bueno con 5 minutos de retardo) es este:

Despliegues grandes en Amazon EC2

16

En Agile Testing explican su experiencia en un gran despliegue en EC2 de Amazon.

Las grandes lecciones a retener, según esta experiencia son:

  • Prepárate para los fallos, es más, considéralos algo positivo en el sentido de que te ayudará a diseñar mejor
  • Automatiza totalmente el procedimiento de despliegue (este le gustará a Abiquo)
  • Diseña para el escalado horizontal (es decir a base de incrementar el número de máquinas/instancias y no aumentando la potencia de las mismas – enfoque vertical)
  • Establece objetivos claros y medibles
  • Prepárate para identificar rápidamente cuellos de botella y eliminarlos
  • No esperes que por muchas pruebas que hagas funcione a la primera.

Este es sólo un resumen, vale la pena leer el artículo original si estás interesado en el cloud computing.

Longjump lleva su plataforma a casa del cliente

longjump-platform

Interesante movimiento de LongJump (proveedor de PaaS Platform as a Service) del que me entero por el blog de Phil Wainewright.

La compañía de California ofrece ahora su plataforma para que pueda ser utilizada en las propias instalaciones de sus clientes. Los talibanes puristas del concepto SaaS se llevarán las manos a la cabeza escandalizados, pero yo creo que es un movimiento muy inteligente por parte de LongJump ya que les permite oponer un potente argumento a los detractores del cloud computing cuando objetan aquello de ¿y que pasa si tu proveedor SaaS te deja tirado?.

Movimiento que además, como ya se comentó aquí mismo, va en línea con los deseos de sus potenciales clientes.

¿Qué le pedirías a tu proveedor de cloud?

En una reciente encuesta de IDC se preguntó a los encuestados qué atributos valorarían más en sus proveedores de servicios Cloud y la respuesta se puede ver en el siguiente gráfico:

Atributos a reclamarle a un proveedor de cloud

 

Como era de esperar precio y calidad (SLA) son los más valorados. Del resto de atributos me llama la atención el cuarto más apreciado, el que hace referencia a que sea posible mover a las propias infraestructuras la aplicación desplegada en la nube del proveedor. Me llama la atención, primero y obviamente porque es diferencial (el resto de atributos podrían serle reclamados a cualquier proveedor, sea cloud o no) y segundo porque creo que la clave no es que la aplicación sea transportable a las propias infraestructuras sino que sea transportable a cualquier otra nube también.

Esta cuestión, la de la portabilidad entre nubes, es en mi opinión uno de los retos, junto con la seguridad y la integración, que antes deben afrontar los proveedores de servicios en la nube si quieren que este concepto despegue.

 

GMail sustituye a Exchange

google-microsoft-buddiesMe entero por Diversity el excelente blog de Ben Kepes, que Microsoft ha perdido frente a Google un contrato para proveer de correo electrónico a todos los estudiantes australianos de la región de Nueva Gales del Sur. Y no me extraña que lo haya perdido:

Microsoft deal involved a AU$33 million contract and took four years to go live. The Google rollout is planned to cost just $9.5 million and should be live by the end of 2008.

Simple y llanamente: CUATRO – 4 veces antes y 4 veces más barato.

Más información en la fuente directa de MIS Australia.

Google por dentro

googleisevilGoogle es una compañía que me tiene fascinado hace tiempo, sobre todo por su capacidad increíble de crear nuevos productos y lanzarlos exitosamente.

Detrás de esa maquinaria parece ser que hay una tecnología, dicen que prodigiosa, soportada por una infraestructura colosal pero de la que Google ha revelado muy poco.

He leído un documento firmado por David F. Carr (a este Carr no lo conocía antes) donde, basándose en fuentes diversas (algunas de Google pero no todas), ha recopilado una serie de datos sobre esta misteriosa infraestructura que me parecen muy interesantes, no sólo desde el punto de vista técnico sino también porque se vislumbran los atípicos criterios que dirigen su estrategia.

El documento se puede encontrar aquí y recomiendo su lectura, aunque para los que no tengan el ánimo suficiente he preparado un picoteo de los puntos más interesantes.

Como ideas para recordar me quedaría con:

  • Google tiene una capacidad de proceso sin parangón conseguida mediante un enfoque diferencial de como deben ser sus procesos y sistemas de información.
  • La infraestructura de IT se considera un componente estratégico de la compañía.
  • Todo en esta vida es imperfecto. Es mejor gestionar la imperfección que pretender que todo sea perfecto.

Algunos ejemplos para ilustar estas ideas:

  • Google, según ciertas estimaciones, corre sobre 450.000 (!) “servidores” agrupados en miles de clusters en docenas de centros distribuidos en Dublín, Virginia y California. Recientemente ha adquirido un nuevo centro en Atlanta y está construyendo uno nuevo en Dallas del tamaño de dos campos de futbol (americano supongo). Esta inmensa granja de servidores está formada por elementos de bajo coste (PCs de gama baja) corriendo en un linux tuneado, con lo que disponen de escalabilidad ilimitada y lineal. El concepto de grid computing llevado al extremo.
  • Este hecho se menciona como un elemento crucial en el despegue de la compañía ya que le permitió crecer con poca inversión en infraestructura (otras puntocom empezaron con costosísimos servidores a prueba de fallos, algunas no llegaron ni a amortizar el primer año). Alguien ha llegado a decir que Google tiene una ventaja competitiva en costes de 1 a 3 con su competencia (a mí me parece exagerado este ratio).
  • Como anécdota, se menciona que el principal problema que tienen es poder refrigerar esa inmensa fuente de calor (se dice que han optado por procesadores AMD en lugar de Intel por eso).
  • Google compra, no alquila, hardware. El CFO dice que “creemos que tenemos una ventaja competitiva por construir y poseer nuestra propia infraestructura”
  • Google ha desarrollado la capacidad de desplegar rápidamente centros de datos “empaquetados” en armarios (racks) estándares de 20 o 30 pies, es decir tienen una movilidad muy valiosa tácticamente, que les permite poner un centro de datos, donde haya acceso a fibra, de un día para otro.
  • Todo el diseño de la infraestructura está regido por el principio de que cualquier componente fallará en algún momento. Si a este hecho se añade el que todo el hardware es de gama baja, se necesita que el sistema deba ser tolerante a fallos continuos, lo que consiguen a base de redundancia y sistemas de corrección automática de errores (que han sido desarrollados por Google y constituyen uno de sus secretos tecnológicos mejor guardados)
  • Si hace falta se reinventa la rueda, o mejor dicho, se inventan un tipo de ruedas que no tiene nadie. ¿A quien se le ocurre en estos tiempos construir de cero un sistema de gestión de ficheros (el Google File System), un sistema de gestión de base de datos (Google Big Table), un sistema de gestión de trabajos en batch (global work queue), para correr procesos distribuidos en paralelo (Map/Reduce Framework)? … ¡pues a Google!
  • No me extenderé aquí pero los detalles técnicos, para los que nos gustan ese tipo de detalles, son impresionantes – es como replantearse todos los fundamentos de diseño de software. Cuando alguien lanza una búsqueda en Google desencadena una serie de acciones en su sistema que impresiona. Tampoco voy a entrar en detalles aquí, pero cuando lo lees acabas creyendo oir el silbido de los chorros de bits circulando a toda pastilla.

Pero no todo es tan estupendo:

  • Hay dudas sobre el coste de mantenimiento de todo esta parafernalia de cientos de miles de PCs funcionando de forma distribuida por el planeta
  • Yahoo y Microsoft , más o menos usando los mismos argumentos, dicen que ese modelo sólo es aplicable a un negocio de operaciones muy uniformes y repetitivas. Ellos tienen más variedad y por tanto ese modelo es parcialmente válido – sólo en sus lineas equivalentes (buscadores). Me sale la duda ahora de si para el resto de servicios que ofrece Google (blogspot, gmail, calendar, etc.) también usan ese modelo de infraestructura.
  • El modelo no es adecuado a sistemas de negocio que no admiten errores, de hecho su ERP es Oracle Financials. En el resultado de una búsqueda no pasa nada (ni siquiera lo notas) si el resultado que debía salir en 5º lugar en realidad debería salir el 8º. Si introduces un asiento contable no hay margen para un error de ese calibre.

Para los que quieran más, hay otro artículo que describe también las interioridades de la tecnología de Google. Se puede encontrar aquí.

Para los que se han aburrido y no se quieren ir con mal sabor de boca, visiten el hermano especular de Google: elgooG

Leche y tecnología

trazabilidadHoy es portada de todos los periódicos: Nestlé retira leche infantil en España, Italia, Francia y Portugal por estar contaminada con tinta del etiquetado.
Ya han retirado 30 millones de litros sólo en Italia y me viene a la cabeza inmediatamente la pregunta de ¿cómo van a retirar toda la leche contaminada?. Para empezar ¿cómo saber cuál es la leche contaminada? …y ¿dónde está ahora? … porque no van a retirar toda la leche de forma masiva, ¿no?, eso supondría enormes problemas a muchas empresas: la propia Nestlé, los distribuidores, los transportistas, los puntos de venta, … está claro que es preferible hacer una retirada selectiva, pero ¿cómo? – ¡pues con la tecnología!, ¿cómo si no toda esa leche va a ser localizada?

He aquí que tenemos que hablar del concepto de trazabilidad, definida por la Asociación Española de Codificación Comercial AECOC como: “aquellos procedimientos preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y la trayectoria de un producto o lote de productos a lo largo de la cadena de suministros en un momento dado, a través de unas herramientas determinadas”. Destaco aquí la palabra herramientas porque es lo que me da paso a entrar en el tema del post: ¿cómo puede ayudar la tecnología en la resolución de este carajal?.

Para explicarlo en un plan peliculero, imaginemos lo siguiente:

Situaros en las oficinas de Nestlé en Esplugues, Barcelona. Suena el teléfono del director de sistemas. Lo coge y se queda lívido: es el presidente que le explica que en Italia han detectado leche para niños con potenciales problemas de toxicidad y que necesita para ya que se identifiquen todas las partidas con potenciales problemas para su retirada. “¡Ah! bueno, sólo es eso” piensa aliviado el director de sistemas. “Enseguida Sr. presidente, déjeme hacer algunas gestiones y en menos de una hora le enviaré un correo electrónico con un report completo”.

Dicho lo cual se sienta en su cómodo sillón y una rápida sucesión de imágenes pasa por su mente: los briks siendo etiquetados, cada uno con su código EAN (qué monos que quedan), empaquetados y cargados en palets con su correspondiente etiqueta RFID, registrándose automáticamente su salida de fábrica y cada una de las entradas y salidas en los sucesivos almacenes intermedios, así hasta llegar a su punto de venta final.

Y todo ello generando una ingente cantidad de información en bases de datos distribuidas a lo largo y ancho de su cadena de suministro extendida, pero sincronizadas e integradas entre sí… información, que convenientemente procesada por su sistema, le permitiría dar el dichoso report a su presidente… sólo tiene que introducir el código EAN de una de los briks potencialmente tóxico y su sistema le dará todos los briks del mismo loteo partida, los lotes/partidas fabricados en el mismo proceso, la planta donde se hizo, si está en tránsito en qué camión o barco y dónde, el código de proveedor de la tinta, quien había faltado al trabajo ese día, … ¡todo!. Y pensó: “bueno, antes de enviar el report aún me da tiempo a una partidita al solitario”

Bueno, sí es de película pero de ciencia ficción claro.
O explicado más en serio:

  • Técnicas de ingeniería de la información: mediante la definición de estructuras de datos que hagan posible la identificación y seguimiento individualizado de cada producto como por ejemplo EAN (European Article Number) o EPC (Electronic Product Code), ambos estándares de codificación universal que identifican unívoca e individualmente cada producto (en el caso de la leche de marras, cada uno de los tetrabrik)
  • Sistemas de información clásicos: desde infraestructuras básicas como servidores, líneas de comunicaciones, bases de datos, etc. hasta aplicaciones específicas (las hay incluso gratis), pasando por herramientas de integración EAI con sistemas de gestión empresarial o ERPs.
  • Sistemas de seguimiento automatizado de mercancías: desde el clásico código de barras hasta las aplicaciones más sofisticadas utilizando tecnologías RFID.

Problemas ocultos en la externalización de las TIC

En un post anterior ya comenté, al hilo de la revisión de un ya viejo informe (¿viejo 7 años?), algunos de los problemas, que en mi opinión, nos podemos encontrar en la externalización de las TIC.

En una etapa profesional anterior me tocó liderar algún que otro proyecto de implantación de externalización de las TIC (ITO por Information Technology Outsourcing se le llamaba a este tipo de proyectos) por lo que he podido experimentar (quizá sufrir sea una palabra más indicada) personalmente alguno de los problemas anteriormente citados y alguno más … los ocultos

Éstos problemas ocultos, generalmente son derivados, no de dificultades de los cambios organizativos o tecnológicos intrínsecos a estas movidas, sino de lo complejas que son a veces las organizaciones y relaciones humanas (it’s the Change Management, stupid!)… y son el objeto de esta entrada:

Efecto solidaridad vengativa: Ocurre con frecuencia que en un proyecto de externalización algunos puestos de trabajo devienen redundantes (eufemismo para decir que las personas que los ocupaban se van a la calle), y se crean nuevos, casi siempre ocupados por personas de la empresa de servicios adjudicataria del proyecto (de eso se trata, ¿no?).
La reacción de los que se quedan frente a los que llegan es frecuentemente de hostilidad, se creen que han de vengar a sus ex-compañeros y se aprovechan de la más mínima ocasión para quejarse y decir aquello de “esto es un desastre, antes estábamos mejor, … nos hacían más caso, … no resolvéis, …”

Efecto tú no eres de la empresa: Los recién llegados son vistos como externos, que no entienden las necesidades del negocio, que son meros proveedores, a los que se les puede tratar como eso: p… proveedores. Este hecho dificulta el intercambio de información, las relaciones del día a día, la confianza, etc.

Efecto todo está definido y queda registrado: Una condición imprescindible para que un proyecto de externalización de las TIC sea controlable y funcione, es que toda actividad y cambio sea registrada y siga unos procedimientos muy bien especificados. El resultado es que los usuarios se quejan de burocratización, lentitud, para todo hace falta llenar un formulario, etc.

Efecto ya no se puede mangonear como antes: Los empleados de la empresa que presta el servicio TIC externalizado no son tan fácilmente controlables como lo eran los ex-empleados que ocupaban esos puestos anteriormente (en base a relaciones informales o por línea jerárquica pura) . Se acabó aquello de “mírame el PC de mi hijo que no funciona” – caso inocente – o en un caso real que conocí (y que no era tan inocente) “borra todo rastro de ese e-mail que le envié a fulanito hace tres meses no vaya a ser que llegue una inspección judicial por la demanda que nos ha puesto el cliente ACME”

En conclusión, no todos los problemas de las externalizaciones vienen por los cambios tecnológicos y operativos. Hay que gestionar el cambio en las personas

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies