La importancia de diseñar y aplicar un buen uso de Gobernanza en nuestro entorno SharePoint 2013 – Parte II

Escrito por Francisco Ricardo Gil González - 21/05/2015

​Enfocando el modelo operativo de SharePoint donde el usuario es un cliente conseguimos dotar de mentalidad positiva a las operaciones, al definir los límites y limitaciones del servicio, implícitamente estamos dotando a los Administradores del Sistema capacidades para establecer expectativas con los usuarios del servicio, beneficiándose de una estructura de planificación que orienta las decisiones presupuestarias y de dotación de recursos.

El punto importante es definir lo que el servicio que ofrecemos, lo que implica que el servicio, y qué recursos es responsable de qué acciones.

La idea es que sepamos como:

  • Hacer que el ámbito de aplicación del servicio de SharePoint sea explícito e intencional.
  • Establecer diferentes niveles de servicio para dirigirse a diferentes necesidades.
  • Organizar y priorizar las entradas de solicitud de servicio.

La determinación del alcance de su servicio de SharePoint

Hay varias razones por las que podrían querer un amplio margen para su primer lanzamiento de SharePoint. A continuación se enumeran algunas razones que a menudo encontramos:

  • Consultoría de empresas quieren un amplio margen para que puedan asegurar su propia tubería de suministro.
  • Los promotores de proyectos a menudo quieren hacer una mezcla grande con un wow-factor en un comunicado de que puedan adjuntar su nombre;
  • Los usuarios están entusiasmados con todas las diferentes características de SharePoint y no pueden priorizar entre cuáles quieren primero.

Me gusta pensar en ello como una muerte por mil cortes de papel. Cada aspecto marginal en el proyecto en sí mismo no parece demasiado grande. Cuanto mayor sea el número de requisitos a definir en el servicio, más se aumenta el riesgo y se ralentiza el proceso. Cada corte de papel solamente podría venir con una pequeña picadura, pero todos se suman y trabajan en nuestra contra. Con un ciclo de entrega regular, puede evitar la carga de cualquier ciclo de entrega individual.

Usted debe entregar rápidamente, ofrecer con frecuencia, y entregar de forma incremental.

Una de las cosas que más me gusta de SharePoint es la forma en que puede crecer y adaptarse con el tiempo. No es como otros sistemas que necesitan de decisiones por adelantado. SharePoint no te obliga a desplegar la mayoría en el primer despliegue. Puede desplegar la infraestructura básica, con una línea de base y luego rápida y regularmente.

A la hora de definir el ámbito de un servicio, podemos precisamente definir una línea básica y posteriormente ir incrementando funcionalidad, un poco más adelante veremos cómo determinar las características de SharePoint y su funcionalidad. Yo uso la metáfora de la fruta madura: lo que está en esas ramas SharePoint metafóricas más al alcance, que yo pudiera llegar rápida y fácilmente. No hay una respuesta única para todas las preguntas, al igual que con cualquier tipo de actividad de diseño, ya que su elección depende de su situación particular y prioridades individuales.

Digamos, por ejemplo, que las bases de operaciones resultan ser que fruta madura para usted. Sus usuarios utilizan actualmente recursos compartidos de archivos, pero su experiencia de intercambio de archivos no es tan rica o de colaboración, que frecuentemente suele ser. Queremos ofrecerles la posibilidad de revisar los documentos para la edición, el seguimiento de las versiones, para comentar sobre los cambios, e incluso establecer alertas de notificación cuando hay cambios. SharePoint hace esto muy bien, y este escenario lo convierte en una excelente fruta madura para encargarse de ello.

Ahora, ¿cómo se dibuja un cuadro alrededor de la entrega de bases de operaciones para proporcionar una experiencia de colaboración de documentos más rica para los usuarios? En primer lugar, necesitamos los servidores desplegados y SharePoint instalado, a continuación generamos un sitio web con una dirección URL a la que los usuarios podrán acceder, y entonces necesitamos decidir si los usuarios pueden aprovisionar sus propios sitios o si van a solicitar y tener el servicio para crear sitios para ellos. Ahí lo tienen: fruta madura que se puede entregar rápidamente y que va a proporcionar un valor inmediato a sus usuarios.

No hay marca, no hay plantillas de sitio, no hay desarrollo, no hay flujos de trabajo y sin campanas y silbatos. Usted sólo tiene el núcleo de los sitios de grupo de SharePoint, y que le ha hecho estos sitios disponibles para los usuarios en casi ningún momento. Sitios de grupo por defecto ya están desbordados con las campanas y silbatos integrados en los que hará las delicias de los usuarios que están acostumbrados a usar recursos compartidos de archivos. Los usuarios pueden asignar tareas, crear discusiones, e incluso pueden blog y enviar encuestas! Hay un montón de características que ya están disponibles para mantenerlos satisfechos, por lo que no necesitan inflar su alcance del proyecto de servicios de SharePoint inicial y retardo haciendo este valor a disposición de sus usuarios.

Entregar el servicio tan rápido como pueda, y luego extender y mejorar en una fase de seguimiento. La fase dos para este ejemplo podría incluir lo siguiente:

  • Un diseñador puede diseñar los colores de la interfaz de usuario y logotipos, y el branding necesario para  que los usuarios se sientan bien.
  • Un desarrollador puede adjuntar una página maestra y los temas a los nuevos   sitios usando la función de grapado.

La identificación de diferentes niveles de servicio para diferentes necesidades

Cada cliente es diferente, y eso es cierto, independientemente si el cliente es un cliente externo o si son sus usuarios internos. Todos ellos tienen diferentes necesidades, capacidades diferentes, y diferentes prioridades. Cada uno tiene una combinación única de las tres que traen con ellos, ya que consumen el servicio de SharePoint, y tienen sus propias expectativas.

Tratando de individualizar el servicio para complacer a cada una de estas necesidades se puede desbordar el servicio rápidamente. Si tratamos de ser todo para todos, se termina arriesgando no siendo mucho a nadie. No podemos simplemente escalar el servicio si usted consume a sí mismo con el enfoque en cada usuario individual, y por lo que necesita una manera de agrupar usuarios en grupos con necesidades comunes. Al mismo tiempo, no queremos alejarnos de estos clientes o desarrollar una actitud militante en el que tienen que ajustarse a lo que usted ofrece. No, queremos satisfacer las necesidades de nuestros clientes y ofrecer un servicio valioso que los apoyará en sus funciones diarias y funciones de trabajo. En lugar de individualizar el servicio que ofrecemos y lo que es específico para cada persona, puede simplemente dar la impresión de un servicio individualizado

¿Cómo se puede dar la impresión de hacer frente a las diferentes necesidades? Podemos ofrecer unos sabores del servicio donde la funcionalidad y uso donde agrupar características comunes en un nivel de servicio. Esto nos permite centrarnos en el uso más pesado para obtener los mayores beneficios para el momento de invertir, mientras que también proporciona un conjunto repetible y de bajo mantenimiento de las ofertas que satisfagan la mayoría de las necesidades con la menor cantidad de nuestra participación. A continuación, puede dividirse y dar prioridad a sus clientes, agrupándolos en niveles de servicio adecuados.

Otro enfoque para definir los niveles de servicio, si las devoluciones de cargos no son una opción consiste en supervisar el uso y la identificación de los usuarios pesados. Me refiero a estos como aquellos usuarios del servicio de SharePoint que son mis principales clientes. Si no tengo un modelo de cargo donde los clientes pueden suscribirse y auto-identificarse a su nivel de servicio más apropiado, entonces yo les identifico con base en sus tasas de uso y adopción reales. Utilizo una serie de medidas para identificar a estos clientes. En primer lugar, me veo en el número de usuarios activos que utilizan su sitio y la cantidad de contenido que almacenan en el sitio. Estas dos métricas me dan un indicador razonable de cuáles son mis clientes más grandes y más activos. Identificarlos mediante la ejecución de una secuencia de comandos en el servidor que enumera los sitios por tamaño o actividad.

La siguiente secuencia de comandos de PowerShell SharePoint 2013 lista los sitios en una granja y los ordena de mayor a menor en base a la cantidad de contenido que almacenan. Puedo usar esto como un método rápido y fácil para obtener una lista de todas las colecciones de sitios en un servidor y su tamaño. Usando la salida, puedo dirigir mi atención a los sitios en la parte superior de la lista, que sitios almacenan la mayor cantidad de contenido. Puedo usar esto en diferentes escenarios, por ejemplo, si quiero auditar almacenamiento para identificar oportunidades para reducir cualquier espacio desperdiciado de almacenamiento de contenido.

Get-SPSite | Select Url, @{Label="Size";Expression={$_.usage.Storage/1MB}} | Sort-Object -Descending -Property "Size" | ConvertTo-Html -Title "Site Collection List" | Set-Content SiteCollectionSizeReport.html

El Diseño de nuestro nivel de servicio

Podemos nombrar  a sus niveles de servicio basado en números, como nivel uno, nivel dos, y así sucesivamente. Este método para mi gusto es bastante genérico y aburrido; pero lo que es peor, es cuando el número de niveles de servicio que restringirá a sí mismo por el propio sistema de numeración. Me siento obligado en este sistema de numeración de dos maneras: los números implican una jerarquía u orden, y esto se convierte en un problema cuando desea incluir niveles paralelos que ofrecen el mismo nivel de servicio con diferentes conjuntos de características; y la segunda manera es que la numeración hace que sea difícil insertar niveles de servicio adicionales más adelante, tales como 1B oferta nivel.

Me gusta mucho más nombres para los niveles de servicio y los nombres más comunes parecen ser platino, oro, plata y bronce. Podemos  utilizar otros nombres que muestren más descriptivo de sus servicios, tales como: básico, extranet, portal y repositorio. Alternativamente, es posible utilizar otros nombres que también ofrecen descripción de sus necesidades de recursos del servidor, tales como: la residencia, semiprivada, aislar las aplicaciones de servicio, aplicación web privada y agrícola dedicada. Puede ser que incluso mezclar y combinar entre estas estrategias de denominación. Todas estas estrategias de nombres son descriptivos y pueden ser significativos para los clientes, así que escoja uno que resuena con su organización y el tipo de niveles de servicio que desea ofrecer.

Generalmente empiezo con un nivel de servicio básico, y esto normalmente incluye un sitio de grupo de SharePoint predeterminado con mi cuota de sitio más restrictiva. Yo uso este nivel de servicio para incluir a todos los sitios de grupo que los usuarios crean con la creación de sitios sin servicio integrado para SharePoint. Esto permite a los usuarios a la libre prestación de un sitio genérico bajo demanda. Estos sitios bajo una ruta de acceso administrada y que comparten las aplicaciones de servicio asociadas a su aplicación web. Los usuarios pueden "inflar" estas páginas a varios gigabytes de tamaño, personalizar el diseño visual, y añadir funcionalidad adicional. Podrían agregar funcionalidad personalizada mediante un paquete de soluciones de usuario o un SharePoint 2013 App Del SharePoint Store o desde un catálogo de aplicaciones internas. Dependiendo de cómo me desglose de los niveles de servicio, que pueden ofrecer lo suficiente en este nivel básico para dar cabida a este tipo de necesidades para que pueda satisfacer las necesidades de la mayoría de mis usuarios, sobre todo si tengo una base de usuarios que es razonablemente autosuficiente y que quiere ser habilitada para gestionar sus propios sitios.

El nivel de servicio básico puede ofrecer un montón de campanas y silbatos, pero a fin de que a escala y en gran parte de autoservicio impulsado, sitios de usuario en el nivel de servicios básicos tienen que compartir la URL de la raíz y de provisión de sus sitios bajo una ruta de acceso administrada. La mayoría de los usuarios no les importará, y probablemente ni siquiera pensar en esto, pero algunos prefieren una URL fácil y corta. A menudo me llamo a estas peticiones URL Vanity. Por sí solo, probablemente no es razón suficiente para romper los sitios en el nivel de servicio básico para comenzar a ofrecer los nombres de host individuales, pero todavía se puede satisfacer la mayoría de nuestros clientes que preguntar por una dirección URL Vanity. En mi respuesta a estas peticiones, recomiendo el aprovisionamiento del sitio con una URL normal bajo una ruta de acceso administrada, y luego ofrecer un servicio de redireccionamiento que utiliza DNS, IIS, o una aplicación ASP.NET sencilla que recibe las solicitudes realizadas a la URL de Vanity  más corto y luego les redirige a la URL real de la colección de sitios.

  • Una opción para redireccionar  las URLs de Vanity a la URL de una colección de sitios bajo una ruta de acceso administrada implica añadir una regla de redireccionamiento con la función de reescritura de URL de IIS. Puedo crear las reglas para hacer una redirección a la URL y aprobar la solicitud en el servidor SharePoint frontend web. Puede descargar y aprender más acerca de la herramienta de reescritura de URL de IIS desde la siguiente URL: www.iis.net/download/urlrewrite.
  • También he visto a los clientes a implementar un servicio centralizado de dirección de la URL donde crean una entrada DNS para un simple URL, como http:// ir. A continuación, construir una aplicación de redirección de URL en el lugar donde reciban a esta Go URL. El Diseño es muy similar a cómo iba a funcionar un servicio de acortamiento de URL pública y lo utilizan para el sitio o página de referencias, perfil de las personas de referencias, referencias de mapa, y similares. Pueden anunciar un anuncio en un ascensor o de un pasillo con una URL corta y fácil como http: // go / 102, y el uso que para redirigir las solicitudes a las direcciones URL largas.

    Puede acoger esta aplicación de redirección Ir URL centralizado en IIS utilizando una simple aplicación ASP.NET. Me gustaría crear una aplicación ASP.NET para proporcionar una forma donde los usuarios pueden crear su propio Go URLs, y almacenar la lista de direcciones URL de redirección en una base de datos de Microsoft SQL Server para mantener una lista dinámica de URLs.

Un ejemplo común es un nivel de servicio GOLD, que podría ofrecer cosas tales como una aplicación web dedicado para alojar un portal personalizado, aplicaciones de servicios aislados, una frecuencia de copia de seguridad mayor contenido, a un público más amplio de usuarios de los contenidos, y similares. Estos niveles de servicio más altos suelen ser para los clientes internos que quieren construir un sitio de portal de departamento o algún otro tipo de aplicación personalizada alojado en SharePoint. Podrían ser un portal que aloja los formularios de informe de gastos y procesa los flujos de trabajo, un portal de aprobación de viajes y reservas, o un sistema de gestión de aprendizaje empresarial. Uno podría albergar un portal del Departamento de Recursos Humanos, que contiene varias aplicaciones personalizadas tales como las relacionadas con las revisiones de desempeño y planificación de la carrera. Estas son todas las aplicaciones que añaden valor empresarial enriquecido en SharePoint y podrían requerir más de su participación.

A medida que nuestros clientes internos adoptan el servicio de SharePoint, algunos tendrán requisitos muy sencillos, mientras que otros tendrán necesidades de servicios más complejos o más involucrados. Podemos proporcionar a nuestros clientes con un servicio básico para empezar, y luego ofrecerles diferentes opciones para que puedan aumentar el alcance de las capacidades disponibles y el grado con el que se puede construir una aplicación personalizada.

  • Un mayor número de usuarios que utilizan el sitio.
  • Una mayor cantidad de contenido en el sitio.
  • Una gama más amplia de funciones disponibles para el sitio.

Organizar y priorizar las entradas de solicitud de servicio.

Una de las cuestiones a las que las personas se enfrentan con las solicitudes de servicio implica el manejo de entradas de solicitud de servicio de un cliente, o la falta de manejo para ser más precisos. Por ejemplo, cuando un usuario experimenta algo o un indicio de algo que él o ella quiere experimentar viene a la mente, que se abra un ticket de solicitud de servicio. Por supuesto, el usuario piensa que su solicitud de servicio es importante, de lo contrario, el usuario no se habría molestado en abrir la compra de entradas y para que asigne una alta prioridad a la compra de entradas. Entonces el proceso le asigna el billete, pero ese recurso no cambia el nivel de prioridad, probablemente debido a que el recurso de apoyo no quería insultar al solicitante.

Las solicitudes de servicio van a venir cuando los usuarios tienen problemas con el sistema, y cuando los usuarios imaginan todo tipo de cosas que les gustaría que el sistema haga para el desarrollo de sude trabajo. Si un problema afecta a un usuario, él o ella es, naturalmente, va a percibirlo como de alto impacto. El usuario simplemente no tiene una visión global del servicio de SharePoint y por lo general no es consciente de los costos que hay detrás de su petición. En el caso de solicitar una nueva funcionalidad, el usuario no puede incluso saber si la funcionalidad va a resolver su problema o incluso ser factible. Por otro lado, un usuario puede solicitar una nueva funcionalidad que no es la solución óptima para el problema que están tratando de resolver. Si un experto no analiza un problema real del usuario y el equipo simplemente salta a cualquier funcionalidad que el usuario solicita, entonces el equipo confía en un usuario para jugar el papel de un arquitecto de la solución; sin embargo, un usuario normal no tiene la misma experiencia de SharePoint como arquitecto para soluciones reales. Por otra parte, no creo que esas cuestiones deben ser incluso problemas de los usuarios, ya que tienen sus propios puestos de trabajo. Deben confiar en nosotros para responder a sus solicitudes mediante la adopción de una visión empresarial del sistema y sus costos. Estamos allí para dar sentido a sus peticiones ya que como profesionales de TI, analizamos y comprendemos  la función de negocios que están tratando de lograr, y luego diseñar una solución o proporcionar orientación de una manera que ayude a continuación, a que el usuario realice su tarea.

En la imagen de abajo podemos ver el ejemplo de un proceso de flujo de trabajo de entradas de solicitud de servicio:

Imagen 1.- Ejemplo de un proceso de flujo de trabajo de entradas de solicitud de servicio. 

Si no podemos confiar en los usuarios para priorizar sus propios billetes, ¿cómo se puede confiar en los socorristas y personal urgencias  para dar prioridad a una urgencia correctamente? ¿Cómo se asegura la coherencia entre el equipo? Necesitamos un protocolo que defina lo que cada uno de los niveles de prioridad son y los criterios de umbral del ticket debe caber dentro con el fin de asignar a un determinado nivel de prioridad. Necesitamos umbrales precisos para indicadores que puedan  medir, y por supuesto, que los indicadores tienen que ser medibles.

Un indicador que me parece revelador de la prioridad de un ticket es la medición de la cantidad de personas afectadas por el problema. Podría ser sólo una persona que presenta la solicitud de servicio, un pequeño grupo de trabajo que esté colaborando con el que consta de ocho personas, su departamento que consta de un centenar de personas, o de toda la organización. Si tenemos en cuenta estos diferentes umbrales, deberían mostrarnos los diferentes impactos que una solicitud de servicio tiene desde el punto de vista de la empresa, y por lo tanto proporcionar una forma consistente para asignar una prioridad válida para la compra de entradas. Determinando el número de personas afectadas por un problema proporciona una medida fiable para determinar un nivel de prioridad para asignar a una solicitud de servicio durante su diseño inicial. Esto también tiene una perspectiva global, ya que sus umbrales serán en proporción al tamaño de la organización.

Por ejemplo, en una organización más pequeña con menos de 1.000 usuarios, los umbrales pueden variar desde un único usuario a todos los 1000. En contraste, una organización más grande con 100.000 o más usuarios se extenderán esos mismos umbrales en un rango mucho más grande. He encontrado que estas proporciones también representan propia percepción de la organización de la prioridad para un número determinado de usuarios. Esa organización más pequeña se sentiría los efectos de 500 personas afectadas por un corte de luz, la mitad de sus usuarios totales, y se daría prioridad a una resolución mucho más urgente. El mismo número de usuarios de la organización mucho más grande seguiría siendo importante, pero la criticidad no estaría en la misma medida porque el número de usuarios afectados solo representa apenas la mitad del uno por ciento de su población total de usuarios, en lugar de un medio como en el que se hizo para la compañía más pequeña.

Otro indicador que uso para determinar la prioridad de un ticket es la pérdida potencial de ingresos cuando la solicitud de servicio es en relación a un corte de luz que afecta a los clientes externos, como en un ejemplo de un sitio de comercio electrónico. En un proceso similar a la determinación de umbrales medibles para los usuarios afectados, me gustaría determinar los umbrales de la posible pérdida de los ingresos que van desde ninguno hasta tener todos los ingresos detenidos. Cualquier pérdida de ingresos es importante. Tener este tipo de medidas y umbrales razonables le ayudará a mantener el incidente en perspectiva para que pueda reaccionar adecuadamente.

Otra medida para la prioridad: comparar el coste de volver a crear frente al coste para recuperar el contenido. En un sentido más general más allá del costo de producción de contenidos, puede medir el valor de la disponibilidad del contenido. Me gusta tener en cuenta tanto el costo y el valor, en función de las circunstancias. Yo uso el costo como una medida para el contenido generado en las operaciones diarias donde los usuarios pueden fácilmente volver a crear o de contenido que no es verdaderamente misión crítica y sensible al tiempo. Esto proporciona una decisión métrica  más fácil de usar en la priorización de la solicitud de servicio. Por otro lado, el contenido puede ser de misión crítica por razones sensibles al tiempo u otros. Este tipo de contenido se ajusta mejor a la medición del valor que aporta más que el costo de producir, ya que está proporcionando más valor en curso. Después de haber determinado el valor que el contenido más crítico ofrece, puede utilizar esta en la determinación de la prioridad de la solicitud de servicio. Ahora lo ideal es que haya identificado que el contenido antes de un corte de luz o antes de que un usuario envía una solicitud de servicio urgente.

Algunos ejemplos incluirían recuperación de desastres o grandes planes y procedimientos de respuesta a incidentes. Estos son valiosas piezas de contenido cuando los usuarios los necesitan, y en el caso de un incidente grave, que será fundamental para poner a disposición en lugar de considerar la re-creación. Puede identificar qué tipo de contenido y, posiblemente, la almacena en una base de datos designada para el contenido crítico, y esto podría ser la primera base de datos que se restaura en caso de un incidente grave. Otro caso que se puede usar para clasificar contenido es si está considerando la sensibilidad del contenido en sí mismo, y se podía utilizar eso para ayudar a determinar la prioridad de un ticket de solicitud de servicio. Por ejemplo, saber un contenido sensible que contiene información de identificación personal nos  proporciona un indicador que puede utilizar para determinar la prioridad en la respuesta a la solicitud de servicio relacionado. Coste contenido, valor crítico, la sensibilidad, la seguridad, y la urgencia proporcionan medidas que podría utilizar para determinar la prioridad de la solicitud de vale de servicio, y lo más importante, se puede medir a todos sin depender de una gran cantidad de subjetividad.

Ahora que podemos dar prioridad a las entradas con una prioridad válida, puede priorizar su respuesta. Cuando sabemos los umbrales de las prioridades de las entradas y las rúbricas que definan en qué consiste cada prioridad, entonces podemos tener confianza en nuestro sistema de venta de entradas y tendremos la seguridad cierta para su funcionamiento. Nuestros usuarios pueden tener confianza en el proceso, y una vez que tengamos los niveles de prioridad bien definidos con todos los parámetros que intervienen en ellos, podemos compartir esta información con los usuarios para ayudar a establecer sus expectativas también.

 

Francisco Ricardo Gil González
MVP CLUSTER | Especialista en SharePoint & Office 365
francisco.gil@fiveshareit.es
Linkedin
http://www.mvpcluster.es

***