Cisco Domain Ten: Dominio 5: Catálogo de servicios y administración (e informe técnico gratuito)

Hoy, es momento de analizar el Dominio 5, la estructura Cisco Domain TenSM, que considera el Catálogo de servicios y la administración. En esta publicación, me gustaría ejemplificar el rol importante y central que tiene el catálogo de servicios en la transformación del centro de datos, y analizar también algunos de los desafíos, consideraciones y deliberaciones clave que debería enfrentar a medida que especifica los requisitos, y la evolución constante del catálogo de servicios de TI. También le señalaré un informe técnico gratuito de nuestros expertos en servicios de Cisco.

Cisco Domain Ten: Presentación del Dominio 5: Catálogo de servicios y administración

Como la automatización y el autoservicio son un enfoque principal en el diseño y la evolución del centro de datos moderno, y como la noción de “Autoservicio” es integral para la definición de la nube (consulte por ejemplo la definición de NIST), no debería sorprender que “Catálogo de servicios y administración” es uno de nuestros diez dominios de la transformación del centro de datos y la nube. Si piensa en eso, el concepto de ofertas bien especificadas, diseñadas y construidas es la forma en la que la mayoría de las organizaciones ampliaron la oferta de ingreso en el mercado, por eso es lógico que (con el tiempo) TI debería adoptar un enfoque empaquetado de los servicios de TI. Mientras que el concepto de catálogo de servicios de TI existió durante unos años, sin lugar a dudas no era común cuando comencé a trabajar en TI (muestro mi edad aquí ). Si le interesa la evolución histórica del concepto de un catálogo de servicios de TI, mi colega, Rodrigo Flores, escribió una excelente publicación en el blog sobre “Servicios para el lugar de trabajo. Una breve historia personal del catálogo de servicios y su evolución”. Recomendaría leerlo si no está muy familiarizado con la historia aquí.

Hoy me gustaría analizar en este blog las consideraciones clave que debería tener en cuenta cuando especifique y diseñe un catálogo de servicios. No diré aquí que estas son las consideraciones más importantes; sin embargo, desde mi punto de vista, son algunos de los desafíos más interesantes o algunos de esos que a veces se olvidan, cuando, como ocurre muchas veces, la búsqueda de la evaluación técnica de “qué herramientas del catálogo de servicios elegiremos” surge a partir de la prioridad empresarial de “qué servicios necesitamos para llevar a cabo nuestro negocio, cuáles son los impactos y las oportunidades”, etc.

(1) El propósito de un catálogo de servicios

No nos olvidemos de esto. El propósito de un catálogo de servicios es permitir el pedido de servicios sencillos para los clientes o usuarios finales. Se trata de hacer que resulte más sencillo hacer negocios con TI. No es solo un ejercicio de diseño de la interfaz gráfica de usuario (GU) ni se trata de exponer cada opción de servicio que tiene en mente (o todo lo que los clientes/las personas interesadas pueden solicitar). (Consulte los siguientes elementos).

(2) Convencer a las personas interesadas

Si todavía no tiene un catálogo de servicios, deberá convencer a las personas interesadas de que debería presentar uno. Al igual que con cualquier cambio organizacional, el gurú de la administración líder es John P. Señala Kotter, si a veces no queda claro. “10 pasos hacia un catálogo de servicios de TIde la semana de información analiza los desafíos de la adopción y de otro tipo que posiblemente deba enfrentar cuando busque un enfoque del catálogo de servicios.

(3) Identificar claramente la audiencia objetivo

Debería ser claro en esto. Mientras que puede apuntar usuarios de TI expertos con el catálogo de servicios, el objetivo real de un catálogo de servicios en la nube es permitir que los usuarios no técnicos exploten el servicio de TI de manera automatizada y como autoservicio. Diseñe el catálogo para que requiera conocimiento de los “Números de unidad lógica” (LUN) y números semejantes así restringirá el catálogo a los expertos de TI.

(4) ¿Qué servicios deberían estar en la cartera?

Antes de incorporar servicios a una herramienta del catálogo, asegúrese de especificar y validar los servicios que requiere el usuario final/cliente/persona interesada. ¿Existe un caso de negocios para cada servicio? ¿Se utilizarán con suficiente frecuencia como para justificar la inversión en el empaquetado? ¿Serán rentables o le ahorrarán dinero? Asegúrese de que la implementación sea factible. ¿Qué opciones debería haber en el servicio? ¿Es demasiado complejo? Si no son lo suficientemente sofisticados, los usuarios finales seguirán solicitando paquetes de trabajo personalizados (lo que evitará que los suyos escalen y le representen más gastos operativos). Ya hablé sobre la necesidad de estandarizar los componentes de la infraestructura en mi blog sobre el Dominio 1, para cumplir con la promesa de la nube. Asimismo, aquí con la definición de servicio, debe estandarizar la definición de sus servicios en bloques de creación que se repiten.

(5) ¿Quién administrará la cartera de servicios?

No me refiero al administrador de TI aquí. A medida que desarrolle más servicios, le recomendaríamos que considere agregar/designar un “administrador de productos de servicios” formal para su equipo, que impulse la definición de los servicios y su evolución, y que sea responsable de garantizar que el diseño y la creación del equipo de ingeniería satisfacen las necesidades y cumplen con las expectativas del usuario final.

(6) Qué herramienta del catálogo de servicios se debe usar: El Portal del usuario

Bien, hablaré sobre la elección de la herramienta 🙂 La elección de la herramienta para el Portal del usuario es lo que puede estimular e interesar realmente a los técnicos. Analicé el Portal del usuario en mi blog sobre el Dominio 4. Indicaré aquí que un catálogo de servicios no necesita una herramienta (aunque claramente una buena, ayuda). Puede implementar un catálogo de servicios en papel. Podría definir los servicios en la nube elegidos y obtener algunos de los beneficios de productividad y costos de la nube, sin una herramienta. Por supuesto que los procesos manuales tienen límites, y existe un mayor margen de error. No obstante, una buena herramienta del catálogo de servicios no le permite obtener más beneficios y más rápido. Sin embargo, no se olvide que es la relevancia del mercado [proveedor de servicios] y la relevancia de la persona interesada [negocio/empresa/organización], y el valor, que empaque de manera adecuada en la cartera de servicios que brinda en la nube: la mejor herramienta del mundo con definiciones de servicios que los clientes/las personas interesadas no deseen utilizar se convertirá rápidamente en “software de estantería”.

Como herramienta de elección, recomendamos el Portal de la nube de Cisco, parte de la Automatización inteligente de Cisco para la nube. Esta evolucionó desde nuestra adquisición de newScale. newScale ya era una de las empresas de catálogo de servicios líderes cuando las adquirimos hace unos años, e invertimos sustancialmente en más desarrollo desde entonces, para que sean mejor y se integren perfectamente con Cisco Process Orchestrator, para brindar una solución completa para la automatización y el autoservicio de la nube.

Podría seguir escribiendo sobre este tema. Los expertos en servicios de Cisco están listos para ayudarlo con estos desafíos. No debe superarlos todos solo. Tenemos la experiencia a mano, a nivel global, para permitirle a usted y a su equipo que el diseño y la evolución del catálogo de servicios tengan éxito.

Espero haberlo convencido de que los catálogos de servicios y su diseño son un tema fascinante, desafiante y muy valioso para que invierta. El catálogo de servicios tiene un lugar central en la transformación del centro de datos y la nube, y por lo tanto en nuestro modelo Cisco Domain Ten. Si le interesa leer más sobre las consideraciones de diseño, consulte nuestro informe técnico gratuito “The Need for Service Catalog Design in Cloud Services Development” (La necesidad de diseño del catálogo de servicios en el desarrollo de servicios en la nube) de nuestros expertos en servicios de Cisco, y manténgase en contacto cuando necesite ayuda con la especificación y el diseño. Nuestro equipo de servicios de Cisco ha “estado presente, lo ha visto y lo ha hecho” y está preparado para ayudarlo.

Share
Stephen Speirs

Stephen Speirs is part of the Cisco Advanced Services Product Management team, working on Data Center and Cloud Services. This team is tasked with developing major new professional service offerings for Cisco, and in particular around cloud computing adoption. Working with customers and partners worldwide, Stephen has over 20 years industry experience in IT, Data Centers and Service Provider Network Management. Stephen is based in Cisco's offices in Scotland, near Glasgow, and was "acquired into" Cisco in 2000 through the acquisition of Atlantech Technologies Ltd. Before joining Cisco Services, Stephen was senior manager, product management, in Cisco's Network Management Technology group, where he brought to market the multi-award winning Cisco MPLS Diagnostics Expert product. Stephen has a BSc (1st Hons) in Applied Physics from the University of Strathclyde, an MSc in Digital Systems engineering from the University of Heriot Watt, and an MBA from the University of Strathclyde Graduate Business School.