viernes, 24 de abril de 2015

Definiendo Capacity de Arquitectura

Hace poco en una empresa me pidieron que les ayude a definir la capacidad de arquitectura que necesitaban para poder hacer frente a las necesidades de la organización. Como no es la primera vez que surge la necesidad de definir la capacidad, voy a tratar de explicar cuál es mi experiencia y conocimiento sobre el tema.

¿Qué arquitecto?
Antes que nada, para definir cuantos arquitectos necesita una empresa hay que preguntar a que llaman arquitecto.
En una organización podemos encontrar varios tipos  de arquitectos distintos, arquitectos empresariales, de dominio, de segmento, de solución, de software, de un lenguaje en particular, de una tecnología en particular… Como ven el menú es variado.
Dependiendo del tipo de industria y cultura de las empresas, la tendencia a futuro es contar cada vez con más arquitectos “dueños” del conocimiento y utilizar proveedores de servicios en implementar las definiciones de arquitectura.
Por tal motivo, los roles de arquitecto empresarial y de solución se imponen como preponderantes para el éxito de las soluciones informáticas del futuro. Dependiendo de la madurez de la organización, podríamos encontrar arquitectos de dominio y de segmento, pero definitivamente los arquitectos de software, lenguaje o de una tecnología en particular estarían del lado del proveedor de servicios.
Ahora bien, retomando el tema, deberíamos decir: ¿Cuántos arquitectos empresariales necesito? ¿Cuantos arquitectos de solución? ¿Cuantos arquitectos de segmento? ¿Cuantos arquitectos de dominio?
En este post me gustaría hace foco en ¿Cuantos arquitectos de solución? Más adelante hablaremos de los otros arquitectos.

Participación del arquitecto
Un ciclo de entrega de soluciones típicamente tiene las fases de Idea, Inicio, Definición, Diseño, Construcción, Testing, Deploy y su posterior Operación.
Claramente, el primer esfuerzo del arquitecto de solución se da en la fase de inicio, donde es parte de entender el alcance, el contexto y los principales stakeholders, luego es el principal responsable de la fase de definición donde sería el diseño de alto nivel sale a luz, finalmente, en la fase de diseño debería adoptar un rol de ser fuente de consulta de los analistas que hacen el diseño técnico detallado.
En algunas empresas los arquitectos, están presentes en todas las fases, convirtiéndose en una especie de PM técnico. Este tipo de práctica, hace que el arquitecto pierda su principal foco que es conseguir el mejor diseño posible alineado con las prácticas de arquitectura empresarial y empiece a preocuparse por temas de implementación, como si se habilitaron las reglas del firewall, si están los accesos para todos los usuarios, etc.
Otra práctica que no  es recomendable,  es que el arquitecto de solución este diseñando muchas soluciones al mismo tiempo, es preferible ajustar los programas de proyectos, para asegurar la participación de arquitectura de forma escalonada y evitar que se convierta en un cuello de botella por todas los diseños que es estén encarando a la vez.
Una regla que se suele utilizar para el dimensionamiento de los arquitectos de solución, es emparejarlos con el de PM, si un proyecto tiene un PM, entonces tiene que tener un Arquitecto de Solución, si hay proyectos con menos complejidad y un mismo PM puede tener 2 proyectos en forma simultánea, el  Arquitecto de Solución podría estar diseñando 2 soluciones de forma simultánea.
 
Conclusión
  • ·       La cantidad de arquitectos de solución que se necesita, depende de la cantidad de proyectos, su complejidad y su calendarización
    ·         La regla del PM puede servir para determinar la cantidad de arquitectos de solución
    ·         El tiempo que dura la fase de definición, donde se concentra el mayor esfuerzo del arquitecto de solución, es de entre 15% y 25% del total del proyecto, dependiendo de la complejidad e impacto en la arquitectura.
    ·         Calendarizar los proyectos para asegurar la optimización del arquitectos de solución (en realidad, debería hacerse para todos los recursos críticos).
    ·         Si tenemos 100 proyectos, no necesitamos 100 arquitectos de solución, necesitamos un mago, porque no hay organización que pueda llevar adelante tal cantidad de proyectos de forma exitosa



jueves, 9 de abril de 2015

¿Qué es Arquitectura Empresarial?

En la semana del 20 de abril vamos a estar presentando Arquitectura Empresarial en "expoteleinfo" Santa Cruz, Bolivia.

Les dejo una introduccion al tema que desarrolle para las sesiones. Abrazo

Introducción

En los últimos años las áreas de tecnología informática (TI) hicieron frente a un fuerte incremento de aplicaciones y tecnologías necesarias para soportar al negocio dentro de una organización.
Las tecnologías avanzan rápido y el negocio quiere aprovecharlas antes que sus competidores. TI está obligado a innovar, pero a la vez,  a mantener todos los sistemas heredados, lo que genera:
·         Sistemas con una complejidad inmanejable y costosos de mantener
·         Sistemas heredados que obstaculizan la capacidad de responder al mercado de una forma oportuna y rentable 
·         Información de Misión Crítica  desactualizada
La arquitectura empresarial (AE) nació a fines de los años 80 con el objetivo de abordar esta problemática.

Analogía con arquitectura urbana

La forma más sencilla para entender el valor que aporta AE es comparándola con la arquitectura urbana. En una ciudad, cada sistema de una empresa, equivaldría a un edificio particular. Así como la arquitectura urbana no pretende regular todos los detalles de cada edificio, AE  tampoco regula todas las decisiones de diseño de cada aplicación. Las regulaciones se limitan a aquellas que promueven una evolución sustentable,  maximizando la integración,  la seguridad y  procurando un correcto dimensionamiento de los servicios comunes. Los servicios comunes de una ciudad, como los hospitales, la red vial o el servicio de agua corriente, equivaldrían en AE  a centros de servicio compartidos, infraestructura de comunicaciones o middleware SOA.

Frameworks de Arquitectura Empresarial

Actualmente las organizaciones que deciden implementar AE suelen adoptar alguno de los cuatro frameworks más utilizados en el mundo, Zachman, TOGAF, FEA y Gartner. Si bien existen diferencias entre ellos, a la hora de implementar AE, se utiliza de cada uno lo que mejor se adapta a las necesidades. Los cuatro conciben a la organización desde el negocio hasta la infraestructura tecnológica,  incorporando la visión de múltiples stakeholders con perspectivas diferentes.

¿Quiénes adoptan AE?
                        

AE es altamente recomendable para organizaciones que por su dimensión, distribución geográfica, compra o fusión necesiten determinar una dirección clara en cuanto a procesos, aplicaciones, datos y tecnología. Existe la creencia de que AE es necesario sólo en grandes empresas. Sin embargo, la práctica de AE es una oportunidad para que el negocio ponga foco en: Planificación Estratégica, Operaciones, Automatización y Tecnología. ¿Por qué deberíamos  privar a cualquier organización de estos beneficios?

martes, 21 de octubre de 2014

ITIL: Superheroes de TI

Muchas organizaciones tienen 'Superhéroes de TI', personas que parecen saber todo sobre los sistemas, al que todos llaman cuando hay un problema, que conoce el nombre de todas los empleados de la organización, que computadora tienen y hasta su fondo de pantalla!!!
Este comportamiento es común en organizaciones que recién comienzan o que experimentan un crecimiento vertiginoso, donde cada empleado, tiene que usar «muchos sombreros» para  hacer las cosas dentro de presupuestos ajustados. Pero cuando las organizaciones empiezan a crecer…  el ‘Superhéroe' empieza a convertirse en un obstáculo.
Para acompañar al negocio, las organizaciones requieren cada vez más servicios de TI  y de mayor complejidad. Lo que antes hacia una persona, ahora es más difícil!!! Los Superhéroes  de TI son seres humanos, se toman vacaciones y se enferman. Los súper poderes no están disponibles 24 x 7!
Para acompañar este crecimiento y  evitar el síndrome del superhéroe, es necesaria la adopción de un marco de trabajo de mejores prácticas, ITIL, el marco de trabajo  para la gestión de servicios de TI más difundido en el mundo.

martes, 7 de enero de 2014

Cloud Business: Negocios en el aire

Les dejo una nota que escribimos junto con Clara Comar y Daniel Castares en la revista Perspectivas sobre el desarrollo de negocios en la nube.

A la hora de ofrecer nuevos productos y servicios, el negocio de la nube abre un amplio abanico de oportunidades para las empresas de telecomunicaciones. Y, a la par, el reto de un cambio profundo en la organización y sus procesos. Uno a uno, todos los desafíos en el horizonte, más una posible ruta para el vuelo. 

Introducción

Una de las claves del éxito en los negocios es identificar las oportunidades y fortalezas internas, y aprovecharlas para superar los desafíos externos. Las empresas de telecomunicaciones (Telcos), con su naturaleza en constante evolución y adaptación, tienen sobrada experiencia en el asunto. Las telefónicas ya lo demostraron en los 90's, cuando aprovecharon sus tradicionales redes de transmisión de soporte interno como plataforma para ofrecer productos individuales al cliente final. Entonces, para acompañar el proceso, debieron modificar su organización tradicional y su metodología de gestión para
adaptarlas a las nuevas necesidades del mercado.

En la actualidad, la posibilidad de ofrecer servicios en la nube presenta un escenario tan desafiante como aquel de hace dos décadas. Para que las Telcos ingresen efectivamente en el negocio de soluciones con base online, no alcanza con comprar hardware y software en grandes cantidades. Es necesario enfrentar un profundo cambio organizacional y de procesos de negocio. Hoy como ayer, la respuesta puede encontrarse dentro de las propias compañías, más precisamente, en el conjunto de mejoras prácticas de la industria: BPF de Frameworx (antes eTom). Pero antes, resulta vital tomar conciencia de los desafíos organizacionales y de procesos corporativos que implica subirse a la nube. Es tiempo de comenzar.

Desafíos en la organización
A la hora de salir a ofrecer servicios en la nube, uno de los primeros retos que debe afrontar una Telco es el cambio cultural. Las áreas de IT de las empresas no suelen relacionarse con clientes finales de negocio, por lo que deben incorporar nuevos procesos y terminología. En estas situaciones de cambio, las personas suelen aferrarse a lo conocido y rechazar la novedad: una buena estrategia de comunicación y capacitación puede vencer esta resistencia y hacerlas sentir parte de la propuesta.

En materia de procesos, surge la necesidad de definir rigurosamente las características y los niveles de los servicios a ofrecer, y que se estará en condiciones de comprometer, medir y cumplir. A diferencia del soporte interno, se ofrecerá servicio a clientes finales, con los cuales estableceremos un contrato legal: éste contendrá el SLA (Acuerdos de Niveles de Servicio) y el detalle del servicio. A nivel legal, se deberá considerar también otras reglamentaciones y leyes particulares que impacten en el servicio a brindar, como por ejemplo, la Ley de Protección de Datos. Por otro lado, la definición y medición de los niveles de servicio y el consumo de recursos permitirá realizar el chargeback de las prestaciones brindadas y contar con información disponible tanto para consultas externas del cliente, como internas de la propia empresa.

Otra importante tarea es la planificación de la demanda y la provisión de la capacidad requerida, desafío mayor en un negocio que gira en torno a la asignación dinámica de recursos on demand y en el cual no es posible relevar las necesidades del cliente con anticipación ni contar con información histórica sobre su comportamiento (a diferencia de lo que ocurre con los usuarios internos). Lo que sí se conoce son las principales preocupaciones que tienen clientes en materia de seguridad y acceso a datos: ellas son confidencialidad, integridad y disponibilidad de la información y los sistemas. Por lo tanto, como proveedor de servicios en la nube, será fundamental la definición de las políticas, procesos e implementación de los servicios para asegurar estos aspectos.


En la vecindad
Un capítulo aparte merece la reflexión sobre las implicancias que tendrá para las Telcos ofrecer servicios para múltiples “inquilinos” o multitenancy, definición básica del negocio en la nube. Una de ellas es la performance: como proveedor de servicios deberá asegurar que todos los usuarios puedan consumir recursos a medida que lo vayan necesitando y soportar los picos de demanda en la utilización de los recursos. Otro desafío es la seguridad en el acceso: ésta se vuelve una tarea más compleja que en un ambiente singletenant, y conllevará la implementación de mecanismos de identificación y autentificación de usuarios.

Un punto clave a tener en cuenta en la gestión del multitenancy —que tiene incluso implicancias legales y regulatorias, es la separación de datos: la base de datos debe permitir a los usuarios almacenar su información, sin ésta quede expuesta o comprometida ante otros tenants, y viceversa. Esto implicará el manejo de diferentes niveles de encriptación de datos. A su vez, el proveedor deberá proveer cierta flexibilidad en la ubicación del almacenamiento físico de datos, ya que existen algunas regulaciones que impiden que cierta información se almacene por fuera de determinadas zonas geográficas.
Es importante, en todo momento, definir y seguir detallados procesos y cumplir con estándares de seguridad porque una brecha en un ambiente multitenant puede tener como consecuencia el robo o la exposición de datos críticos de los usuarios.

Otro asunto en la lista de desafíos, es el mantenimiento de las aplicaciones: si un cliente necesita determinados cambios de configuración o actualizaciones de software, el proveedor de servicios deberá poder bloquear su tráfico, manteniendo el servicio al resto de los tenants. Por último, pero no menos importante, se requiere robustez en toda la infraestructura: en un ambiente multitenant, la falla de un solo servidor o base de datos puede provocar la interrupción del servicio en varios tenants a la vez. La redundancia y los planes de contingencia efectivos serán muy importantes en estas situaciones.


Buenas noticias
Ante los múltiples desafíos reseñados, el negocio de la nube parecería volverse, para los interesados, en un verdadero nimbo con múltiples obstáculos. Pero en este camino, las Telcos tienen gran parte del terreno ganado: la clave está en BPF (Business Process Framework, antes conocido como eTom), el marco referencial de los procesos de negocios de la industria de telecomunicaciones. De hegemonía mundial, BPF proporciona procesos end-to-end que son relevantes para el lanzamiento al mercado de nuevos productos en la nube, junto a un enfoque estructurado y independiente para su desarrollo (Product Life Cycle Management). Anteriormente, a diferencia de lo que propone BPF, los procesos de desarrollo de producto no se distinguían de las operaciones básicas que realizaba la empresa: no se tenía en cuenta que estos procesos cuentan con diferentes ciclos de negocio  y objetivos, lo que hacía difícil cumplir con características de time to market y performance. Por otro lado, BPF incluye las mejores prácticas provistas por otros frameworks, como ITIL (para desarrollar un nuevo servicio) y TOGAF (para generar la arquitectura que soporte un nuevo producto).

Para el Product Life Cycle Management de BPF, un producto es lo que un proveedor ofrece o provee a un consumidor. El producto se compone de servicios y estos, a su vez, se construyen a partir de los recursos tangibles o intangibles de la empresa (aplicaciones, redes, servidores). En la práctica, eso implica primero, definir las características del producto; segundo, identificar qué servicios puedo utilizar o son necesarios desarrollar para vender con el producto; y tercero, reconocer los recursos que van a componer los servicios. Un posible ejemplo es pensar a la “instancia de plataforma en la nube” como un producto que se brinda a través del servicio  PaaS y en el que se utilizan como recursos servidores del datacenter. De esta manera, se puede considerar a BPF como un checklist con las actividades que tenemos que cumplir para lograr colocar un nuevo producto cloud en el mercado: desde su identificación y especificación, pasando por su desarrollo, hasta el lanzamiento (Ver Frameworx en acción).

Por si fuera poco, BPF también orienta respecto de las actividades a tener en cuenta en la operación a fin de que el producto esté listo para ser requerido por el cliente. De esta manera, al momento de emprender negocios en la nube, las Telcos no parten de una página en blanco sino que cuentan, como guía para desarrollar sus productos, con un framework de procesos de probado éxito a nivel mundial. Totalmente a prueba de vértigo. 

jueves, 31 de octubre de 2013

ITIL: Change Management

Estamos ante uno de los procesos mas famosos de ITIL. Change Management es junto Incident Management los procesos mas difundidos e implementados (no siempre bien) en las áreas de Tecnología Informática.

Ahora veamos de que trata Change Management...

CM es el proceso responsable de controlar el ciclo de vida de todos los cambios (para ver que es un cambio leer la entrada anterior).

¿Porque necesitamos controlar los cambios? En un mundo ideal para TI seriamos felices si tuviéramos toda nuestra infraestructura, aplicaciones y arquitectura estabilizada 100% y sin cambios. Lamentablemente esto no es real, continuamente la gente del negocio necesita de cambios de TI para poder desarrollar nuevos negocios, cumplir con nuevos requerimientos legales o satisfacer necesidades del cliente.
Como los cambios existen, necesitamos controlarlos, ¿cuales son los que son realmente necesarios? ¿cuales son lo que producen beneficio? ¿como controlo que un cambio no afecte la estabilidad de todo el ecosistema de IT?

Por eso necesitamos de Change Management...

Muchas veces que en las organizaciones que Change Management tiene un alcance muy extendido incluyendo implementación y seguimiento de los cambios.
En ITIL el enfoque de Change Management es de AUTORIZACIÓN, lograr que todo cambios que se vaya a implementar este autorizado. Para implementación, seguimiento y evaluación hay otros procesos.
El enfoque extendido muchas veces hace que los procesos de CM se conviertan en muy burocráticos, por ese motivo es desaconsejable tener semejante nivel de acoplamiento.

Un buen proceso de CM garantiza que se siguen una serie de pasos determinados para cada tipo de cambio. (mas adelante hablaremos de los tipos de cambio). Básicamente tendremos estos pasos:

  1. Solicitar un cambio
    • Registrar el cambio con toda la información necesaria
  2. Revisar la solicitud
    • Revisar si la solicitud esta completa y es coherente
  3. Evaluar y realizar una análisis de impacto del cambio
    • Identificar quien lo solicita, la razón, que beneficios trae, cuales son los riesgos, que recursos necesita para implementar, quien es responsable de implementar, cual es la relación con otros cambios
  4. Autorizarlo
    • Conseguir el nivel de autorización adecuado para cada cambio
  5. Coordinar la implementación del cambio
    • Calendarizar el cambio, exigir back-out plans (la implementación es responsabilidad de otro proceso)
  6. Revisar la implementación del cambio y cerrar la solicitud.
    • Una vez realizado se verifica si el cambio fue satisfactorio y se cierra o reabre según el caso

El proceso de Change Management sugerido por ITIL, tiene como alcance los servicios de IT. Dentro de una organización existe otros procesos de CM que tienen que estar correctamente integrados, como por ejemplo: Change Management de Proyectos basados en PMBOK o PRINCE2, Change Management Organizacional, entre otros.

Próximamente seguiremos hablando de CM.


viernes, 6 de septiembre de 2013

ITIL: ¿Qué es un cambio?

Me ha pasado de ir a muchas organizaciones que tienen problemas en la implementación de un proceso de Change Management debido a la falta de definición de que es un cambio...

Recurramos a la definición que nos da ITIL sobre lo que es un cambio:

"Alta, Baja o Modificación de cualquier cosa que pudiera afectar un servicio de IT"

De la definición podemos inferir que cualquier cosa que afecta un servicio de IT tiene que ser gestionada y cualquier cosa que tiene que ser gestionada, en ITIL se define como un configuration item (CI).

Entonces podemos decir que el alcance de Change Management son todos los configuration item (CIs).

Parece que pateamos la pelota para adelante....ahora que es un CI?
"Un CI es cualquier componente o activo de un Servicio de IT."
  • Servicio IT es un CI?
    • SI. Podemos decir que la definición de un CI es recursiva. Como analogía: Un auto es un CI, que se compone de  ruedas, que son CI, que se componen de llantas que es un CI, etc.... Un Servicio de IT es como el auto. "Un componente compuesto de componentes".
  • Componente Hardware?
    • SI. Seria como una rueda en el ejemplo anterior.
  • Componente Software?
    • SI. Una aplicación, Sistema Operativo, herramientas, componentes de aplicaciones, etc.
  • Componentes Virtuales?
    • SI. Servidores Virtuales, Storage Virtual, Clouds son un activos de un servicio.
  • Edificio u Oficina o Sector o Locación?
    • SI. Las facilities donde ser brinda un servicio son CI. Pensemos, ¿no nos interesa saber donde se brinda un servicio?
  • Personas?
    • SI. Nuevamente, ¿no nos interesa saber quienes son las personas asociadas al servicio, que lo brindan o que lo consumen?
  • Documentación asociada al servicio?
    • SI. Diagramas de arquitectura, SLAs, Manuales de usuario, Contratos, Métricas, Documentación de proceso, etc. 
  • Estrategia de Negocio?
    • NO. Usualmente la estrategia de negocio, cambios organizacionales, etc, no son tomados como CIs.
Como primera recomendación uno puede decir que primero se definan cuales son los servicios de IT, después se descomponga cada servicio granularmente en cada componente y luego cada componente queda bajo control de Change Management.
Ejemplo:
  • Servicio de Correo Electrónico
    • Webmail
      • Servidor de aplicaciones Apache
        • Maquina Virtual 1
          • Virtualizador A
            • Servidor Rackeable I
              • Microprocesador #
Así sucesivamente podemos ir descomponiendo un servicio en componentes y ver cuales son los que si sufren un ABM, afecta al servicio. (Afectar al servicio es que tengan un impacto, no que produzcan una interrupción).

Por este motivo me parece muy saludable implementar Change Management junto con Service Asset & Configuration Management.... pero la verdad es que pocas veces pasa....Es mas, la mayoria de las empresas empiezan a implementar Change Management antes de pensar en servicios...

Otro punto importante que me gustaría destacar, es que normalmente se piensa que Change Management solo aplica cuando un servicio esta operativo, pero el verdadero alcance del proceso es mas amplio, el diseño de un servicio también debería estar alcanzado por Change Management (Requerimientos funcionales, Recursos previstos, Capacidades, Herramientas, Arquitectura tecnológica, procesos, métodos de medición, métricas, etc).

Ahora bien, la primera reflexión que suelo recibir, es que el alcance de Change Management es muy amplio, que es impracticable, tengo que pedir permiso hasta para reiniciar un servidor, que necesito un batallon de gente desarrollando las actividades de Change....

Por suerte existe la clasificación de los cambios, pero eso lo veremos mas adelante!






miércoles, 28 de agosto de 2013

ITIL: Request Fulfillment

Es común que en las organizaciones no se diferencien incidentes de solicitudes de servicio. Esto tiene sentido para organizaciones con escaso volumen de generación de incidentes o bien que no cuenten con un catalogo de servicios de TI amplio, por lo tanto reciban poco volumen de solicitudes de servicio.

Request Fulfillment es un proceso sugerido por ITIL para tratar las Solicitudes de Servicio de los usuarios, diferenciándolo del proceso de Incident Management.

Una solicitud de servicio es un pedido formal de un usuario para que le provean un servicio. Ejemplos de solicitudes de servicios hay muchos, un usuario puede pedir un consejo, puede pedir información de como se realiza una tarea, puede pedir la instalación de software, puede pedir que le provean un consumible, puede pedir una notebook para otro usuario, puede pedir resetear la contraseña, puede pedir que le muden la computadora de lugar, y asi puede pedir tantas cosas como le dicte su imaginación :-)  .....(siempre y cuando no haya un catalogo de servicios que ponga una cota).

Como principal diferencia con un incidente, vemos que en una solicitud de servicio no hay una interrupción o degradación del mismo (porque esta solicitando un servicio nuevo!!!), y sobre todo, cumplir con una solicitud de servicio puede planificarse (no hay que salir corriendo a cumplirla porque no peligra la continuidad de un servicio).

Tipicamente el proceso de Request Fulfillmen sigue estos pasos:

1. Solicitud
El punto de entrada de este proceso suele ser el Service Desk, pero últimamente se esta siguiendo un enfoque de "Sírvase Ud. mismo". Es decir que la implementación de Request Fulfillment suele ser mas exitosa cuando se apoya en herramientas de Self Service. La idea es contar con un portal donde se encuentren listados los servicios que brinda el área de TI, donde este bien claro que es cada servicio, como se solicita, cuales son las condiciones, etc. Entonces el usuario ingresa al portal y selecciona el servicio que quiere solicitar, algunos pueden ser cumplimentados en el momento y otros requieren escalamiento o autorización.
Este enfoque aumenta la productividad del Service Desk, que no debe estar atendiendo estas solicitudes, aumenta la productividad del usuario, que puede ver cumplimentado el servicio en el momento, reduce la burocracia en la solicitud de servicio reduciendo el costo por ejemplo en horas hombre, incrementa el control sobre lo servicios solicitados dado que tenemos una única fuente de ingreso de solicitudes de servicio. 

2. Autorización
Muchas veces las solicitudes de servicio requieren autorización. Es común que usuarios soliciten la instalación de software en sus computadoras, si el software es licenciado, dado que el numero de licencias suele ser restringido, para que el usuario pueda utilizar el programa en cuestión, tiene que tener autorización. 

3. Cumplimiento
Dependiendo de la solicitud, la misma puede ser auto-cumplida, cumplida por el SD, o escalada a otro grupo. Igualmente, al igual que incidentes el SD debe mantener informado a los usuarios sobre el progreso de su solicitud

4. Cierre
Al igual que los incidentes, las solicitudes de servicio, se registran, se priorizan, se categorizan, también pueden ser escaladas y una vez cumplimentadas cerradas. El ownership de las solicitudes debe permanecer siempre en el SD.

A tener en cuenta para contar con un saludable proceso de Request Fulfillment

-Definir y documentar claramente todos los tipos de solicitudes que son manejadas por el proceso 
-Establecer una herramienta de self service para agilizar el cumplimiento de solicitudes
-Dejar bien en claro en que consiste el servicio que se esta solicitando, con el SLA asociado, requisitos de autorización, etc (hay que tener un buen Service Catalog)


Para finalizar, me parece importante decir que las solicitudes de servicio, suelen ser no muy difíciles de cumplimentar pero causan un alto impacto en la satisfacción de los usuarios. Es decir que bien implementado es un Quick Win en cualquier proyecto de ITIL