MS Dynamics ya está aquí … un «killer»

ms_dynamics_logo_271

Hace tiempo que tenía ganas de escribir algo sobre la estrategia de Microsoft en sus productos ERP, ya que creo que es un caso digno de estudio respecto al concepto de producto y estrategia de distribución, … al final me ha salido este post

Los amigos de Redmond han llegado a este mundo de las aplicaciones de gestión empresarial a través básicamente de la adquisición de productos de terceros. No me detendré nada en la historia pero si quiero citar a Navision y Axapta como dos productos de bandera que desde hace unos años son marca Microsoft.

Hasta no hace mucho, en que unificaron la marca (no producto), la oferta de Microsoft era muy confusa: varios productos que se solapaban en funcionalidad y cliente objetivo, con una historia detrás, distintos por áreas geográficas y empresas (partners) que lo mismo te implantaban uno que otro.

Actualmente, tras la unificación de marca citada y sin que se haya eliminado la confusión completamente, conviven con un nombre comercial genérico común – MS Dynamics – varios productos, de los cuales sólo tres se pueden implantar en España: MS Dynamics NAV (antes Navision), MS Dynamics AX (antes Axapta) y MS Dynamics CRM (que no es un ERP).

Los tres son productos distintos y y el CRM no está integrado con los otros dos. Puede llamar la atención el que de toda la gama (de un total de siete), sólo tres se pueden implantar en España pero es que el resto son productos sin tradición en el mercado europeo y sin implantadores que puedan asumir una instalación.

El plan (road map) estratégico al que se ha comprometido Microsoft es que todos converjan en un único producto antes del 2014, lo que es ciertamente remarcable y un compromiso fuerte en el sentido de que es muy raro (por no decir inaudito) que una empresa de software se atreva a ser tan concreta en un periodo de tiempo tan largo. La táctica asociada a esta estrategia es que cada cambio de versión de cada uno de los productos, en una especie de migración conjunta coordinada, suponga un paso hacia el producto final.
Mi humilde opinión es que algunos llegarán antes que otros y que al final del camino lo que se tendrá es un producto con distintos sabores (similar a lo que apunta el nuevo Vista).

Aunque no se tenga el producto final, sí que se aprecia en las versiones de los productos actuales y en los avances de las que vienen, que el concepto genérico bajo el cual Microsoft está construyendo su(s) ERP(s) es el de que sean un componente más de la herramienta de trabajo del usuario. Es una visión centrada en el usuario y que concibe el entorno de trabajo con todas las distintas aplicaciones trabajando de forma integrada, el usuario pase de estar trabajando con el ERP a estar redactando un memorando o analizando información con su hoja de cálculo sin que se de cuenta prácticamente.

En esta concepción se entiende muy bien la última reorganización de Microsoft en tres unidades de negocio (Platform, Business y Entertainment) y donde la Business Division agrupa los antiguos grupos Information Worker (Office), Business Solution (los ERPs) y Unified Communications (Exchange).

El punto clave de esta reorganización en lo que a los ERPs respecta, y en mi opinión una muy inteligente jugada, es incluir a Office y a Exchange en el paquete, ya que permite utilizar a Office – la omnipresente (legal o ilegalmente, para el caso da igual) aplicación ofimática – como caballo de Troya o cuña para meter el ERP en el escritorio de trabajo del usuario, llegándose incluso a que el interfaz gráfico de los ERPs actuales, sea indistinguible del de Outlook.

Para reforzar aún más esta macrointegración de herramientas ahora el nuevo Sharepoint 2007 forma parte de la familia Office, con lo que ahora, bajo el mismo paraguas, todo integradito, tenemos la ofimática, el ERP, la mensajería, un entorno colaborativo, un portal, un workflow y un gestor documental.

Desde el punto de vista de un gestor de IT que no se quiera complicar la vida demasiado, éste es un escenario aparentemente ideal (antes de que nadie me salte al cuello anticipo que esa es otra discusión, por eso enfatizo lo de aparentemente).

* * *

Respecto a la distribución, Microsoft se apoya en su red de partners para comercializar e implantar MS Dynamics. Toda empresa que quiera ser partner debe invertir una pasta en formar gente, certificarla y asumir un compromiso de mantener actualizados sus conocimientos, además de un nivel de ventas determinado.

Esta estrategia crea un ecosistema muy particular del que destacaría lo siguiente:

  • El negocio en sí mismo que es ésto de los partners para Microsoft, basado en los fees por formación y certificación que se han de pagar sí o sí para ser partner.
  • Los partners pueden ampliar, bajo ciertas restricciones, las funcionalidades del producto base. Ésta es una de las claves fundamentales del éxito presente y futuro de MS Dynamics, ya que todas las verticalizaciones (funcionalidades sectoriales) y adaptaciones a problemáticas muy específicas son realizadas por la extensa red de partners que son los que están a pie de pista con los clientes, con lo que el crecimiento de la cobertura funcional es altísimo.
  • Estas verticalizaciones, además, proporcionan suculentos ingresos por ese concepto a los partners (hay que considerar que una verticalización primero se vende como un desarrollo al primer cliente que la quiere y después se vende como licencias a los que la quieren después). Microsoft certifica, si se han verificado las condiciones metodológicas y técnicas, que ese desarrollo se puede estandarizar y lo homologa como solución vertical.
  • El partner que realiza una verticalización homologada por Microsoft (y siempre intentan que así sea) están obligados a poner a disposición del resto de partners el desarrollo, fuentes incluidos. Este hecho, en un entorno de competencia feroz entre partners, crea un curioso sistema de coopetition, que a mi juicio es muy peculiar y que está marcando cualquier proceso de selección de ERP donde se considere a MS Dynamics. Ni que decir tiene que el partner recibe un porcentaje muy alto de las licencias de la verticalización.

Puede gustar más o menos pero el universo MS Dynamics ha llegado, está aquí con miles de clientes y lo ha hecho para quedarse … y ganar muchos más.

Los proximos años apuntan muy interesantes: ¿Qué hará SAP?, ¿Oracle sobrevivirá o se lo comerá HP o IBM?, ¿y los otros ERPs no tan extendidos pero no despreciables,… sobrevivirán?, ¿y los ERP Open Source, ….son los grandes olvidados en este festival?, …

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

Presentación en el IGC 2006

Os dejo la presentación que hice el 30 de mayo en el Internet Global Congress de Barcelona sobre Implantación de herramientas BPM.
Implantación de herramientas BPM


Como anécdota quiero decir que fue la acción comercial más rentable que he hecho nunca. Con algo más de 30 minutos de charla (más la preparación claro) conseguí dos clientes nuevos.

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

10 razones para externalizar… o no

Ha vuelto a caer en mis manos un informe de hace unos años sobre «las 10 razones más frecuentes por las que las compañías externalizan» (Top 10 reasons Companies Outsource).

El artículo lo confeccionó, en 1998, el «Outsourcing Institute» a partir de una encuesta de la que no he podido encontrar los detalles técnicos de su elaboración, aunque he comprobado que ya no se puede encontrar en su site. (Si a alguien le interesa una copia que me mande un correo electrónico o sino ahí está papá google).

Me ha parecido interesante (y también morboso, confieso) revisitar el informe para ver qué cosas que se decían entonces se pueden seguir diciendo hoy. Y ciertamente me he encontrado que estas 10 razones aún están en vigencia (unas más que otras) aunque con algunas puntualizaciones

La primera razón aducida es la de reducir y controlar los costes operativos o literalmente tal como lo pone en el informe reduce and control operating costs.
Poco habría que decir en teoría sobre esta razón. Al fin y al cabo si firmas un contrato cerrado (tal servicio tal coste), parece que te puedas olvidar de revisar el presupuesto de IT más de dos veces al año. La realidad, me parece a mí, no es tan simple. Si hay un SLA que se queda corto, una nueva línea de negocio que surja, … dile al proveedor que te mejore sin coste el SLA a ver que te contesta.
Las grandes firmas que proveen de servicios de externalización siempre te proponen ahorros medios del 10 al 20% a tres o más años. La conclusión a la que llego es que esta razón parece seguir siendo válida (si nos creemos lo del 10-20%) pero siempre que:

  • el proceso de definición de la externalización se haga teniendo muy en cuenta al resto de las áreas de la compañía
  • que haya flexibilidad de renegociación de SLAs y se tenga un especial cuidado en la definición de estos SLAs, que al fin y al cabo van a ser los indicadores de gestión del servicio… o sea que ojo al proceso de negociación del contrato.

Otra pregunta que se puede hacer es si vale la pena «la movida» que supone una externalización incluso alcanzando ese «teórico» 10 a 20%.

Segunda razón: mejorar la focalización de la compañía o Improve Company Focus… no me acaba de gustar esta traducción.
Qué duda cabe que es deseable que todo el talento de la compañía se concentre en los procesos que aportan directamente valor al cliente y el resto dejárselo a especialistas para los cuales el cliente soy yo, y que se apliquen el cuento a ellos mismos.
Si aplicamos este razonamiento hasta el final, toda la cadena de valor de un determinado ámbito de negocio se transformaría en una sucesión de empresas que sólo se concentran en las tareas o procesos que aportan valor a sus clientes.
Este sería un buen punto de partida para quien se esté planteando la externalización de alguna área de la empresa para determinar qué actividades son, en principio, externalizables.

Tercera razón: Conseguir acceso a capacidades de la mejor clase o Gain Access to World-Class capabilities.
Se entiende que a bajo coste (ya que como nos dice el refrán «pagando San Pedro Canta»), y es aquí que para resolver la ecuación «bueno a bajo coste» puede que nos debamos ir a soluciones que o 1)implican cruzar límites geográficos (me viene en seguida a la cabeza las factorías de desarrollo de software de la India), 2) llevan a compartir infraestructuras (por ejemplo un centro de proceso de datos bunkerizado) que no estarían al alcance de cada una de las empresas usuario por separado.

Cuarta razón: liberar recursos internos para otros propósitos o Free internal resources for other purposes.
Esta razón la relaciono con la segunda (los recursos liberados los dedico a tareas que aporten más valor a la compañía) y quizá se pueda utilizar como factor de motivación del personal: desvío el «trabajo sucio» a los externos y me quedo con el «trabajo interesante» para los míos.

Quinta razón: la de acceder a recursos que no se tienen o Resources are not available internally.
Valga todo lo dicho para la tercera razón (Conseguir acceso a capacidades de la mejor clase), pero puntualizando que los que esgrimieron esta razón intuyo que daban más importancia al factor «bajo coste» que al factor «bueno» de la ecuación mencionada.

Sexta razón: Acelerar beneficios de reingeniería o Accelerate reengineering benefits.
Reconozco que en este punto he tenido que leer detenidamente el detalle del informe para entenderlo. Resulta, si lo he interpretado bien, que es algo así como «limpiando donde más sucio está es como verás mejor la limpieza».
Dicho más formalmente, externalizar es una forma de que la compañía se aperciba de los beneficios que la reingeniería de procesos puede traer ya que generalmente se externalizan las áreas que no son estratégicas o core y que por tanto, al haber sido históricamente relegadas frente a las estratégicas, son las más ineficientes y productivas, y claro está, donde más fácil y visible es obtener mejoras.
Yo además añadiría que externalizar una función implica, como paso previo, examinar en detalle su organización y procesos, lo que ya en sí mismo ayudará en la identificación de oportunidades de mejora.
Esta es una de las razones que me parecen algo desfasadas tras estos cinco años, no porque no sea actual la necesidad de mejorar los procesos de las compañías, sino por la utilización del concepto «reingeniería de procesos». Supongo que hay que entender que cuando se hizo el informe aún estaba de moda dicho concepto por lo que tocaba decir algo al respecto.

Séptima razón: la función externalizada es difícil de gestionar o está fuera de control o Function difficult to manage/out of control.
Me sorprende que esta razón la pueda esgrimir abiertamente alguien al que le están pagando para gestionar, directa o indirectamente, la función «conflictiva». La razón en sí, no me sorprende: simplemente ocurre. En mi experiencia profesional he conocido áreas a punto del derrumbe y que han sido salvadas, in extremis pero no sin sufrimiento, por su externalización a tiempo.
De todas formas que nadie piense que externalizar una función significa despreocuparse de ella ni mucho menos, puede que no tengas que estar en el día a día, pero en el «semana a semana» si deberías.

Octava razón: reducir la necesidad de inversión en capital o Make Capital Funds Available (la he traducido de otra forma que me ha parecido más clara).
Esta sí me parece una razón claramente vigente. Para ser flexible, ¿es preferible «pagar por usar a medida que lo necesito» o «comprar para tener y poder usar»?. Ejemplos se nos pueden ocurrir muchos: ¿es mejor comprar un servidor de correo más grande o ir contratando niveles de utilización de un ordenador del proveedor de servicios externalizados?, ¿se justifica incorporar en plantilla un técnico en un entorno técnico determinado o es mejor pagar por horas de un técnico de un proveedor de servicios?, …
Además suele haber otros motivos que no son de índole operativa, que hagan que pueda ser preferible «gastar» que «invertir». Se me ocurren motivos fiscales, razones contables, de presentación de información financiera,…

Novena razón: Compartir riesgos o Share Risks (he dudado en traducirlo como así tengo a otro a quien echarle la culpa)
Puede parecer que al utilizar la infraestructura y personal del proveedor de servicios compartes (yo diría que casi le traspasas) el riesgo asociado. Esta razón puede ser engañosa, ya que en efecto, puede parecer que ya que el proveedor de servicios se compromete con un acuerdo de nivel de servicio, si le pasa algo a sus infraestructuras, ya se espabilará. Cuidado con esto ya que, por ejemplo, poco consuelo podrás obtener de cobrarle la multa por incumplimiento del SLA si no has podido servir a tus clientes durante 2 días.
En otra clave añadiría que esta razón también se podría interpretar como «así hay otro al que le puedo echar la culpa si pasa algo», pero claro esta interpretación no se puede decir abiertamente, pero… ¿a que la han pensado?

Décima razón: una externalización puede suponer una entrada de contado o Cash Infusión.
Se alega en el informe que en algunos procesos de externalización se puede llegar a recibir capital, contante y sonante, como consecuencia de la venta de activos del área externalizada al proveedor del servicio. De todas las razones, ésta es la que me parece más discutible, incluso extravagante, y en todo caso, seguro que muy restringida a casos particulares. Lo que parece de sentido común es que aunque el proveedor del servicio te pague por los activos que absorba, ya se los cobrará de una forma u otra,…¡si no vaya negocio!.
Supongo que se referirá a que en algún caso específico puede ir bien una inyección de cash para la compañía, aunque luego se devuelva con creces al proveedor del servicio (algo así como una financiación encubierta).

Conclusión
Una vez repasadas la 10 razones, me sorprende constatar que, en estos tiempos donde el usuario es Dios, ninguna de ellas haga referencia a los usuarios de los servicios de IT. No aparecen expresiones equivalentes a la tan en boga hoy en día de «incrementar la satisfacción de los usuarios» o esa horripilante frasecilla de «mejorar la experiencia del usuario».

Lo que he intentado transmitir al hilo de estas reflexiones es que cualquier combinación de estas razones puede justificar, a priori, acometer un proceso de externalización pero siempre se deberán tener en cuenta los diversos factores y condicionantes que hemos ido repasando para cada una de ellas y que a modo de resumen citaría como los más importantes 1) prestar atención al proceso de negociación del contrato, y 2) considerar al resto de áreas de la empresa

En fin, repasar este viejo informe (pero vigente con matices) espero que haya servido como ejercicio de reflexión para aquellos que se estén planteando alguna externalización, que si hemos de creer a las encuestas y estudios que circulan son ya una mayoría entre las mesnadas directivas.

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