Una de las últimas adquisiciones de G2 en materia de juegos didácticos ha sido Lean Lens, un juego creative commons desarrollado por Andrea Darabos y Bazil Arden en 2014 y que presentaron en las jornadas CAS2014 que se desarrollaron en Barcelona el año pasado.
El juego es una representación en forma de obra de teatro en la que hasta 9 grupos de personas interpretan diferentes escenas de la vida cotidiana de las TIC, desde las conversaciones con Negocio para discutir nuevas funcionalidades en la web hasta la resolución de correctivos afectando a diferentes partes de la aplicación. En cada una de las escenas intervienen diversos roles (el Stakeholder, el developer, el tester, el project manager, el tecnico de soporte, etc.) e incorporamos un rol especial en cada grupo que hace las labores de observador. El observador tiene como misión analizar cómo se desarrolla la escena e identificar los diferentes tipos de waste que se generan durante la actividad, de forma que posteriormente se discute con el equipo y se llega a un consenso sobre los derroches identificados.
Cuando se han escenificado todas las escenas, los observadores rellenan el “Mural del Waste”, que hace patente la presencia de los 8 tipos de derroche en cada una de las etapas de la cadena de valor de las TIC, al tiempo que se plantean las diferentes soluciones y formas de mejorar el escenario propuesto.
El juego facilita la comprensión de los diferentes tipos de derroche, la colaboración en equipo y sobre todo demuestra cómo un Mural del Waste puede convertirse en una herrmaienta importantísima (y visual) a la hora de potenciar las actividades de mejora continua dentro de las organizaciones.
Algunos de los comentarios que surgieron en esta edición de Lean Lens con el itSMF España en el Curso de Verano fueron
Lo que estamos representando aquí es tan familiar que le podríamos poner nombre y apellidos a cada post-it que estamos pegando en el Mural del Waste
Pero… ¿Vamos a mejorar ya, o nos quedamos mirando esto como si nada?
Nos ha parecido tan evidente y tan típico lo que estabamos representando que nos da la sensación de que nos vamos a repetir mucho al poner los derroches en el Mural del Waste
Una mañana intensa en la que hemos aprendido mucho; los alumnos se han llevado nuevas técnicas para hacer aflorar las ineficiencias en su organización y para apalancar los planes de mejora continua y yo… pues yo me he llevado un paquete de mejoras a plantearle a Andrea sobre el juego y un paquete de experiencia adicional para mi mochila.
Hace unos días se comenzó una discusión en el foro de LeanSpain titulada “Muda en la Sanidad, 1-2-3 responda otra vez” en la que diversos participantes han hecho un breve resumen de la percepción que tienen sobre las ineficiencias en los hospitales. Uno de los participantes nos refería a una entrada que había escrito en su blog hace ya algún tiempo llamada “Muda en los hospitales”.
La lectura de este hilo junto con el post de José Iglesias me hizo pensar un poco en las diferentes perspectivas con las que vemos un servicio y, sobre todo, en cómo este caso me servía para ejemplificar algo de lo que siempre acabo hablando cuando me toca exponer Lean Service Management™: el consumo Lean.
Normalmente, cuando haces un taller de análisis Lean (un Value Stream Mapping, un estudio de derroches o cualquier otra actividad que sirva para ayudar a una organización a dar sus primeros pasos en la aplicación del Lean Thinking) convocas a un pequeño grupo de personas que vivan la ejecución de las actividades en su día a día (en terminología Lean, aquellos que viven el Gemba) y en la medida de lo posible convocas a los consumidores de eso que estás analizando. En el momento en que el equipo se comienza a plantear los derroches o las situaciones de ineficiencia, pronto comienzan a salir ideas que mejoran “el cómo se hace”.
Pero si nos fijamos bien en la lista de Mudas que se plantean en el hilo o en el post de José, las mudas que estamos explicando son… ¡¡ de consumo !!. Ninguno (creo) de los que estamos en el foro somos médicos, ni trabajamos en un hospital.. las ineficiencias las hemos explicado desde nuestro punto de vista: el de consumidor del servicio… pero si le hubiésemos preguntado a una doctora o a un enfermero, posiblemente nos hubiera dado una lista de mudas totalmente diferente: las mudas de producción, no las de consumo.
Eso es lo importante cuando hablamos de aplicar Lean al mundo de los servicios: en los servicios se produce un acople entre la producción y el consumo; hay un acto de co-producción y por lo tanto una representación clásica de VSM no sirve, puesto que la experiencia del cliente es tanto o más importante que la producción del servicio en sí mismo.
En el mundo de servicios tenemos dos flujos de valor que confluyen y que hay que tratar de forma sincronizada: el flujo de la producción y el flujo del consumo. Si estos flujos no están acoplados, tenemos una situación negativa cuya resolución es fundamental.
Imagina que vas a un hotel. Llegas y la atención en recepción es impecable, te atienden rápido, te informan de los servicios y te dan tu habitación justo como tú la querías: cama doble, vistas a la ciudad, silenciosa… Entras en la habitación y está todo como debe y justo cuando te sientas en la cama, ¡Una pata de la cama se parte y la cama cae al suelo!
Llamas a recepción, en un par de minutos llega el chico de mantenimiento y en poco tiempo te han sustituido la cama (para no hacerte cambiar de habitación; ya habías desmontado la maleta). Se disculpan efusivamente por el inconveniente y te invitan a cenar al restaurant del hotel para compensarte por el mal rato. Al poco rato, alguien te llama para preguntarte si el problemilla se ha solucionado y saber si te han atendido correctamente. Les das 5 sobre 5 puntos en la encuesta de satisfacción.
A la mañana siguiente, cuando te vas a ir, te quedas con el tirador de la puerta en la mano; tienes que bajar a desayunar, así que vuelves a llamar a recepción pidiendo ayuda. Casi antes de colgar se presenta otro chico de mantenimiento que repara la situación en menos de un minuto, se disculpa y te da un cupón de descuento del 50% para la próxima visita que hagas a la ciudad.
Cuando estás haciendo el check-out, el recepcionista te pregunta amablemente si el incidente de la puerta se resolvió adecuadamente y tú lo vuelves a puntuar con 5 sobre 5, ya que se resolvió rápido, te trataron bien y te compensaron por la espera.
Según sales por la puerta, coges el cupón de descuento, lo rompes en 8 pedazos y lo tiras a la papelera mientras piensas “no vuelvo a pisar este antro nunca más”.
Pero ojo! las encuestas te dan por cliente muy satisfecho, ya que has puntuado dos veces con 5 sobre 5, siempre que has tenido un problema te han atendido excepcionalmente bien y todo ha sido muy rápido; ¡Que viva el SLA!
¿Te suena este tipo de situaciones? ¿Lo has vivido, o quizás lo estás potenciando e tu organización?
Lo lamentable es que esta forma de medir la satisfacción del cliente es una Best-Practice en el mundo del ServiceDesk, y deberíamos pararla inmediatamente. Deberíamos dejar de preguntar si la atención (puntual, por incidente) ha sido buena y comenzar a preguntar por el servicio.
¿Cómo haremos las encuestas el día que seamos tan pero que tan buenos, que no tengamos incidencias? ¿A quién le preguntaremos?
Como mínimo, como dice Charlie Betz ( twitter@CharlesTBetz), deberíamos tener una alerta al respecto, algo como un “Repeat Caller Incident” que nos permita saber que un cliente está sufriendo repetidas incidencias, aunque sean de diferente tipo, durante su encuentro con el servicio y de esa forma hacer lo posible por retenerlo (y medir la aparición de este tipo de situaciones para poder gestionar esta situación de manera global)
El servicio no es el soporte.. el soporte es una característica que ponemos cuando el servicio no es perfecto; debemos poner foco en medir (evaluar, analizar, reportar y mejorar) la calidad del servicio.
Esta entrada es una traducción adaptada y reflexionada de un comentario de Aale Roos (twitter@Aalem) en el grupo de Facebook Back2ITSM.
Este fin de semana salí con la familia a comer al campo, junto con otras cuatro familias del colegio de las niñas; dimos un fantástico paseo por el campo, hicimos un poco de Geocaching y al final fuimos a comer un poquito de carne a la brasa… un día agradable y entretenido en que la familia se lo pasó de perlas y yo desconecté un mucho de la tensión del día a día del trabajo.
A la hora de comer dejamos fluir la conversación entre temas de todo tipo: los “padres” hablamos de futbol, de la crisis, del tiempo… Delante de mí en la mesa estaban sentados Fernando (que se dedica a la inyección de plásticos en una fábrica) y Luis (mecánico, con su taller de barrio donde repara todo lo que se le ponga en las manos); en un momento en que estábamos hablando del taller, de repente yo le hice una pregunta a Luis:
--Oye Luis, dime una cosa: los Toyota, ¿qué, son buenos?
Luis comenzó a asentir con la cabeza, pero antes de que le diera tiempo a decir nada, Fernando (que tiene un Toyota) me dijo:
-- Yo soy socio de la OCU y tengo un informe que dice que los Toyota son los coches que menos averías tienen de todos. Por eso me compré uno. Son buenísimos!
-- Y que lo digas! – dijo Luis – son un coche que se estropea muy poco, pero además, es que se nota que están bien hechos. Las piezas que más se rompen, son accesibles y se sustituyen con facilidad. En un Seat o en un Renault te las ves negro para cambiarlas, pero en un Toyota están ahí, fáciles de acceder, con espacio… una gozada!
-- Hmmm… Interesante… – Yo movía la cabeza interesado…
-- Y otra cosa que tienen – siguió Luis – es que están bien diseñados. A veces ves un coche por dentro y piensas “El tipo que diseño esto, no ha arreglado un motor en su vida”. Por ejemplo, los Seat tienen muchísimos problemas eléctricos. ¿Sabes por qué? Porque ponen las piezas donde no deben: hay sensores que están cerca del radiador, o cables que pasan por donde el motor más se calienta… y con el tiempo se estropean. En un Toyota lo ves, y no pasa así: todo está donde debe estar.
-- Ah! - Dije yo – Eso es porque tienen un enlace directo desde el taller hacia el ingeniero para mejorar los diseños continuamente!
Y Luis me terminó de rematar:
Y no sólo eso! Además, cuando se produce una avería los mecánicos se preguntan ¿por que? y no una sino varias veces! Imagínate que me vienes con tu coche con una avería: se ha roto algo y yo te cambio la pieza.. si no me pregunto por qué se ha roto, a los pocos meses vendrás de nuevo a que te arregle la misma avería y encima te cabrearás conmigo porque no te lo he hecho bien.
Hace años hice un curso de Toyota y ahí nos decían que hay que preguntarse por qué pasan las averías y así resolverlas para siempre. Y si es un tema de diseño, podemos decírselo para que arreglen el diseño. Eso no lo tienen las otras marcas!
Imagínate cómo se me quedó el cuerpo.. que Luis, el mecánico de barrio que me arregla el Skoda un día y arregla un Tuareg al otro, dándome clases de Lean! Que gustazo!
Y claro… inmediatamente viene la aplicación en el mundo Lean Service Management: tienes conectado el taller con la fábrica en tu casa? Se enteran los equipos de Arquitectura y de Desarrollo de las causas de las incidencias? Hacen algo con ello?
Si.. ya se… ITIL también habla de Incidencias, Problemas y Cambios, así que podemos usar ese vocabulario también: ¿Tienes Gestión de Problemas en tu casa? Si quieres salir en el informe de la OCU como “Best-In-Class Service Delivery”, ya tardas…
PD: El hecho de tener muy pocas averías, hace que el Toyota tenga un coste de propiedad reducido. Además, hace que el coste de la garantía (para el fabricante) sea menor, y que el coste de mantener una red de talleres gigante y sobredimensionada sea eliminado.
Llevo varios meses trabajando con diversas empresas que se encuentran en una situación de outsourcing con múltiples proveedores. Cada una tiene sus características, sus situaciones especiales, si carácter; pero eso sí, hay algunos detalles que son factor común. Uno de estos puntos en común es la dificultad que tienen para gobernar los contratos con proveedores de servicios que están trabajando en diferentes áreas.
Cuando una empresa se plantea externalizar parte del trabajo que se realiza debe tomar una primera decisión: ¿por dónde pasamos las tijeras? ¿cómo “troceamos” el modelo de provisión de servicios al cliente interno para asignar partes de este trabajo a terceros? Básicamente, hay tres respuestas a esta pregunta:
Opción 1: trocear por servicios – Se le asigna a un proveedor la entrega de un servicio completo, extremo a extremo, hacia el cliente interno. Es una práctica muy poco (o nada) empleada en IT, pero sí que se ve en otras áreas de negocio, donde se le llama Business Process Outsourcing o BPO.
Opción 2: trocear por funciones – Se le asigna a un proveedor la ejecución de una función (un grupo de personas con un cuerpo de conocimiento específico). Esto es lo más habitual en el entorno de IT, y así vemos a terceros realizando “Gestión de Infraestructuras”, “Gestión del puesto de trabajo”, “Gestión de Aplicaciones”, etc.
Opción 3: combinar las dos anteriores con un reparto regional – Cuando la empresa está localizada en múltiples sedes o en diferentes países, se puede realizar una aproximación en la que se asigna una función o un servicio por región geográfica (por ejemplo, la “Gestión del puesto de trabajo” para la región de “Sur de Francia”)
Una vez tomada la decisión, viene la siguiente fase: la creación de los contratos; aquí ya se empieza a diversificar el asunto, y normalmente serán los responsables de las diferentes funciones (del área TI interna) quienes definan los requerimientos para estos procesos de externalización, resumiendo en pliegos o RFPs las necesidades y las primeras guías de cómo se va a gobernar la ejecución del contrato (aparecen los primeros indicadores, los primeros borradores de niveles de servicio y de SLAs, etc)
Si nos fijamos bien, en este momento del proceso comienzan a sentarse las bases de lo que será en el futuro el “nuevo modelo de prestación de servicios” de IT a su cliente (a.k.a. “el negocio), y aquí es donde comienzan a sentarse las bases de los futuros problemas de gobernabilidad: lo que en una primera fase fue la definición holística de un modelo ahora se ha traducido en una contratación por partes y de ahí viene el título de este post: es necesario mantener una visión sistémica del conjunto y es necesario transmitir esa visión sistémica a la contratación por partes.
¿Nunca has tenido la sensación de que gobernar tu departamento de IT se parece a una partida de Whacka-Mole?
Básicamente, la sensación viene producida porque cuando aprietas en un sitio, el problema sale por otro lado… y la razón simplemente es que, a pesar de que en la superficie los contratos con tus diferentes proveedores sean inconexos, por debajo están conectados; entre ellos, con nosotros, con los clientes, con las personas; formando una intrincada red de túneles por las que se mueven los topos, los enanos, los problemas, el dinero y siempre aparecen por donde menos te lo esperas.
Es por esta razón por la que debemos adoptar una visión sistémica, de sistema, de todo lo que ocurre en este entorno.
Yo creo que el mejor ejemplo que se puede dar para entender esto es poner un caso simple: una empresa que tiene un equipo interno de Sistemas (que se encarga de la gestión y administración de las infraestructuras, sistemas operativos, máquinas, middleware como las bases de datos o los servidores web, comunicaciones…), un proveedor externo que se encarga del soporte al usuario y otro proveedor externo que se encarga de la gestión de aplicaciones.
Aquí vemos un sistema formado por 3 componentes (a gran escala) que colaboran entre sí para entregar un conjunto de servicios TI al cliente y que se ven regulados por una serie de contratos. Veamos cómo son estas reglas de juego (simplificadas en aras de que se comprenda bien el ejemplo, claro!)
EQUIPO
RESPONSABILIDAD
OBJETIVOS
SISTEMAS
Mantener las infraestructuras en marcha con los niveles adecuados de capacidad y disponibilidad
Disponibilidad de los Sistemas
Rendimiento de los sistemas
SOPORTE
Atender las incidencias y peticiones de los usuarios
Resolución de incidencias en plazos
Ejecución de peticiones en plazos
GESTION APPs
Mantener y evolucionar las aplicaciones de negocio
Cumplimiento de plazos y presupuestos de desarrollo
Ante esta situación, si pretendemos gobernar el sistema mediante el uso de indicadores y SLAs nos encontraremos con que:
A pesar de tener una correcta disponibilidad y rendimiento de los sistemas, los usuarios pueden estar completamente descontentos (es necesario incorporar una figura que vele por el servicio extremo a extremo, independientemente de las 3 funciones que tenemos en el ejemplo)
El proveedor de soporte… ¿cómo nos factura por el servicio? Evidentemente, es justo que a mayor carga de trabajo nos pueda facturar más; sin embargo, la mayor carga de trabajo puede ser generada en otras de las funciones (que, en el caso de Gestión de Aplicaciones es otro proveedor al que no le interesa lo más mínimo reducir la carga de trabajo de Soporte)
El proveedor de desarrollo, ¿qué objetivos tiene? Cumplir plazos y ajustarse al presupuesto. Simplemente eso.
Así, en este ejemplo vemos rápidamente que la tarea del CIO será hacerse con un martillo y comenzar a golpear enanos que le irán creciendo eternamente… cambiará 1, 2… hasta 7 veces de proveedores y seguirá con el martillo porque la causa no es una incompetencia del proveedor, sino un sistema diseñado para fallar. Apretará al de soporte, pidiéndole que resuelva en plazos y el de soporte hará hasta que los números se lo permitan. El de desarrollo cumplirá plazos y presupuestos, pero a costa posiblemente de producir desarrollos de baja calidad que llenarán al SAU de llamadas o que malgastarán los recursos de sistemas hasta tener que ampliar máquinas una y otra vez. Ahorraremos en un sitio, pero los costes se irán a otro lado.
¿Y todo esto por qué? Porque los objetivos individuales van en contra de una visión de conjunto. Al tener objetivos individuales en cada contrato, estamos rompiendo la visión de sistemas y estamos primando la creación de silos verticales. Además, no nos engañemos: el objetivo de cada uno de los proveedores de servicios será siempre, salvo contadísimas excepciones, “barrer para casa”, así que o imbuimos la visión sistémica desde el principio, en el propio diseño de “por dónde paso las tijeras” y añadimos esa visión en los contratos y en la operativa diaria, construyendo equipos focalizados no en el cumplimiento de indicadores parciales sino en la entrega real de valor al cliente, o estaremos toda la vida dándole golpetazos con un martillo a los enanos que nos crecen por todas partes. Por ejemplo, podríamos:
Hacer co-responsable al proveedor de desarrollo de las implicaciones de su software en soporte y en sistemas.
Hacer que el proveedor de soporte sea co-responsable de la mejora continua de las aplicaciones y los sistemas.
Hacer que el equipo de sistemas sea co-responsable en la definición de arquitecturas y estándares para apoyar al equipo de desarrollo.
Hacer que todos tengan responsabilidad sobre indicadores globales de servicios extremo a extremo.
Establecer responsabilidad transversal de la entrega de servicios entre las diferentes funciones.
Establecer, como decía Walter en una de las presentaciones del itSMF Catalunya 2011, un único indicador: satisfacción del cliente. Perder un poco el foco en el cumplimiento de SLAs y poner el foco en lo que nos importa: el cliente
Ya lo decía Jim Womack en una de sus últimas conferencias: EL problema es que el poder y el control se ejerce verticalmente, cuando el valor al cliente fluye horizontalmente. ¡¡Gestionemos la horizontal!!
Desde que comencé a trabajar en asuntos relacionados con ITSM, allá por el año 96, ya aparecían problemas a la hora de clasificar correctamente los tipos de solicitudes que llegaban a un CAU. Con la entrada de ITIL V2, recuerdo que enseñaba en los cursos de formación la Gestión de Incidencias y luego aclaraba que “aunque la teoría dice esto, en realidad recibimos muchos tipos diferentes de llamadas”, asunto que provocó un artículo en este mismo blog titulado Una Queja no es una Incidencia.
Con la llegada de ITIL V3 apareció de la nada un nuevo proceso llamado “Gestión de Peticiones”, que nos permitía romper aquel flujo único en dos, cosa que desde el principio ya fue aceptada positivamente, ya que separábamos lo que podríamos entender como Demanda Valor de lo que sería Demanda Fallo, pero cuando vas a la vida real te chocas con dos asunto básico: (a) un mismo flujo no sirve para todos los tipos de peticiones y (b) no es tan fácil saber, en el momento en que tienes al usuario al teléfono y apenas un par de minutos para atenderlo y registrar, si lo que el usuario quiere es una incidencia o una petición.
Las diferentes aplicaciones de ITIL en las que he trabajado (nótese lo premeditado de no utilizar la palabra implantación) han lidiado con este problema de diferentes formas, muchas veces en función de lo estandarizado que se tuviese la lista de peticiones o de las capacidades de las herramientas para soportar flujos, ordenes de trabajo, plantillas, etc.
Más tarde comencé mi viaje por el mundo del Pensamiento Lean, en el que fui a parar a la lectura del libro Lean Solutions de Jim Womack y Daniel Jones. En este libro se describe una forma de canalizar las peticiones del consumidor en lo que se denominan pathways de tal forma que se pueda estandarizar, optimizar y priorizar el trabajo en cada uno de estos caminos [cosa que nos resolvería el punto (a)]
Por otra parte, el estudio de una de esas obras poco difundidas pero de gran valor que es el libro Guide to the Universal Service Management Body of Knowledge (USMBOK) me llevó a ver que el planteamiento que se realiza en USMBOK es el de recibir todas las peticiones de consumidor, sean del tipo que sean, en una entidad llamada Service Request, que se clasifica según diferentes tipologías, entre ellas:
Peticiones de servicio procesadas automáticamente por el motor de transacciones
Peticiones de servicio derivadas de que una de las de tipo 1 ha fallado (incidencias)
Peticiones de servicio procesadas con intervención humana, pero no del tipo 2
Peticiones de servicio que solicitan la modificación del servicio (Petición de Cambio)
Esta aproximación nos resuelve el punto (b) ya que todo es una Service Request que luego es fácilmente reclasificable entre los diferentes tipos. Por otra parte, ayuda a implementar el concepto ITIL V3 de CSI Register (que USMBOK incorporaba previamente como Project Incubator) y permite ver toda la demanda agregada (cosa crítica ya que todos los diferentes tipos de demanda compiten por los recursos finitos de la organización proveedora de servicios).
Así, si unimos todo esto en un modelo único, lo que obtenemos es que hay diferentes formas de canalizar una Petición de Servicio hacia la organización proveedora de servicios, y diferentes tipos de petición que se pueden realizar. Por otra parte, la organización proveedora puede recoger todas estas peticiones y canalizarlas a través de diferentes flujos de actividad para su realización. Esto, aunque es de sentido común y podría parecer obvio, choca con estándares oficiales y de-facto que plantean flujos únicos para el tratamiento de las peticiones, mientras que la combinación Lean + USMBOK nos lleva a un tratamiento detallado y unificado de la demanda, tal y como podemos ver en los siguientes gráficos.
Puede parecer complicado, pero es una forma de incrementar el detalle de nuestra gestión de una forma gradual (incorporando nuevos tipos de petición con sus correspondientes pathways) que nos permitirá luego aplicar las técnicas Lean de mejora continua a elementos más pequeños y atómicos como es una petición concreta. Con una definición de la gestión al nivel de “Gestión de Peticiones” no tenemos la granularidad necesaria como para poder mejorar ni plantear objetivos de nivel de servicio ni criterios de comparación… ¿Te imaginas haciendo un benchmark del tipo “cuánto tiempo tardas en resolver peticiones” o “qué coste tienen las peticiones en tu organización”? ¿Y del tipo “cuánto tiempo tardas en proporcionar un equipo a un nuevo empleado” o “cuánto te cuesta el alta de un usuario”?
Hay otras maneras de hacer las cosas, no dejemos que las best-practices nos impidan pensar. Recordemos la máxima de la familia Atreides en Dune (un guiño cariñoso a Luis Moran)
El camino fácil dirige, inevitablemente, al estancamiento
Esta semana he aprovechado un viaje a Madrid para leerme en el AVE el último libro que ha publicado Rob England AKA The IT Skeptic. Se trata de Basic Service Management, una introducción a la Gestión de Servicios en 50 páginas, escrita en un idioma coloquial, simple y sin emplear tecnicismos, en la que se plantean las bases de la Gestión de Servicios (ojo… no de la Gestión de Servicios TI, sino de forma genérica para cualquier tipo de proveedor de servicios). Presenta una imagen global de lo que significa este arte y aporta punteros que señalan a los diferentes cuerpos de conocimiento, marcos de referencia o simplemente artículos y bibliografía que permitirán al lector profundizar en aspectos concretos.
Aparte de su fácil lectura nada indigesta, es de resaltar que la orientación que presenta Rob en este libro es “de cosecha propia”: hay un fuerte componente de USMBOK (Universal Service Management Body of Knowledge)combinado con pizcas de ITIL®, de COBIT™, alguna referencia a Lean, a la Quinta Disciplina, a Kotter, al marketing de servicios, al product management… en definitiva, es un resumen de todo lo que ha leído el autor combinado con todo lo que ha desarrollado él en los últimos años y aderezado con su experiencia personal; si hubiera escrito ese libro yo, lo hubiera titulado como el lema de este blog: Conocimiento Adquirido
La aproximación que propone al lector es fundamentalmente pragmática: escoge lo que te guste de este libro, haz un análisis de si realmente te vale la pena y usa sólo aquello que represente un beneficio en tu organización.
Para terminar de redondear la propuesta, el autor mantiene un portal en http://www.basicsm.com/ donde podemos encontrar orientación adicional, material de descarga, foros, recomendaciones, plantillas y un fantástico paquete de checklists para ayudar en la gestión de los servicios.
Realmente es un libro que vale la pena para todo aquel que:
a)Quiera conocer de qué va esto de la Gestión de Servicios, sin necesidad de ser un especialista. b) Quiera tener una visión global de la Gestión de Servicios y deba orientar su empresa/organización hacia la provisión de servicios c) Tenga que explicar aspectos de la Gestión de Servicios en lenguaje simple, llano, de la calle, a no iniciados.
combinado con pizcas de ITIL®, de COBIT™, alguna referencia a Lean, a la Quinta Disciplina, a Kotter, al marketing de servicios, al product management… en definitiva, es un resumen de todo lo que ha leído el autor combinado con todo lo que ha desarrollado él en los últimos años y aderezado con su experiencia personal; si hubiera escrito ese libro yo, lo hubiera titulado como el lema de este blog: Conocimiento Adquirido