Explorando los beneficios comerciales de SharePoint

¿Alguien en su empresa ha considerado alguna vez si estaba obteniendo el máximo valor de SharePoint? En su superficie, esto parece ser una pregunta ridícula. ¿Por qué una empresa implementaría SharePoint si aún no ha determinado sus verdaderos beneficios y valor general?

Pero en mis conversaciones diarias con otras personas técnicas y comerciales, me sorprende la frecuencia con la que no pueden identificar y cuantificar el ROI real que ven en SharePoint. Aún más sorprendente es cuántas empresas no han utilizado completamente su entorno de SharePoint para reducir los costos comerciales generales y aumentar la productividad.

Los detalles técnicos de SharePoint son importantes, pero en este artículo quiero compartir con ustedes más sobre lo que normalmente falta en la estrategia comercial de las empresas que usan SharePoint.

Por qué usar SharePoint: una visión…

Un domingo del invierno de 2009, estaba sentado en mi asiento junto a la ventana, mirando ansiosamente desde un 747. Me dirigía a San Francisco para asistir a mi primera conferencia, VSLive.

En ese momento, yo estaba trabajando en una importante empresa de cosméticos. Estaba emocionado de asistir a las clases de SharePoint en las que me había registrado: era una pila de tecnología relativamente nueva dentro de la empresa y quería ver por mí mismo lo que SharePoint realmente podía hacer por la empresa.

No me decepcionó. Salí de San Francisco con tanta emoción, un sentimiento que había pensado que se había ido hace mucho tiempo de mi carrera profesional. Estaba tan ansioso por volver a la oficina para hablar sobre esta increíble herramienta con mi equipo... solo para volver a la realidad de mi existencia como director en el equipo de Sistemas de información global:

[Director Ejecutivo – GIS] : “Claro, he oído hablar de SharePoint. No veo por qué tanto alboroto... Podríamos hacer las mismas páginas web dentro de nuestra propia granja web. Creo que estás perdiendo el tiempo”.

[Gerente de Relaciones Comerciales – GIS] : “Es demasiado simple y feo. Nunca podré vender esto a ninguno de mis clientes comerciales”.

[Desarrollador sénior – GIS] : “¿Cuál es el problema? No lo veo agregando ningún valor. Parece demasiado complicado para trabajar. Creo que Active Server Pages es una dirección mucho mejor”.

La única persona que mostró incluso un poco de interés fue el director a quien reporté directamente. No sabía mucho acerca de las tecnologías dentro de SharePoint, pero sabía que yo estaba demasiado entusiasmado con esto como para simplemente ignorarlo.

Me pidió que organizara una breve reunión para hablar un poco más sobre esta tecnología. Esa reunión nos llevó a diseñar una prueba de concepto (POC) de SharePoint para nuestra alta gerencia que eventualmente se convertiría en un componente central dentro del departamento GIS. Automatizaría y agilizaría nuestros nuevos procesos de ciclo de vida de desarrollo de software (SDLC) y marcaría el camino para que la empresa adoptara muchas ventajas de SharePoint, catapultándome al nivel destacado de "The SharePoint Guy". Durante los siguientes ocho años, pasaría gran parte de mi tiempo en la empresa utilizando SharePoint como una increíble herramienta de productividad de bajo costo. Para aquellos que quisieran escuchar, mejoraría muchos procesos comerciales y reduciría sus costos, pero todavía había demasiados sitios dentro de la empresa que eran simples sitios de equipo con bibliotecas de documentos. Yo era solo una persona, nadando contra la corriente para vender SharePoint no solo a mi negocio, sino también a los niveles más altos dentro de la organización.

¿Esto suena familiar?

Durante los últimos nueve años, he observado que los usos de SharePoint en la mayoría de las empresas se presentan en uno de dos escenarios básicos.

1. Sitios de grupo con bibliotecas de documentos

Estos sitios generalmente se crean a partir de la plantilla Team y contienen una o más bibliotecas de documentos que pueden tener estructuras de carpetas muy complicadas. Hay muy poco uso de tipos de contenido, etiquetas de metadatos o flujos de trabajo. Los sitios cuentan con el respaldo total de la unidad comercial, cuyos miembros no tienen un conocimiento formal de SharePoint y no han asumido el rol de "Usuario avanzado". El sitio fue creado por el equipo de infraestructura o soporte que puede generar rápidamente un sitio a partir de un simple ticket de solicitud de la mesa de ayuda.

2. Sitios totalmente personalizados con una base de código grande y complicada

Por lo general, estos son sitios mucho más grandes con una audiencia mucho mayor: las intranets corporativas, los recursos humanos corporativos y los sitios de TI corporativos son los candidatos habituales para este tipo de uso de SharePoint.

Estos proyectos suelen comenzar con una gran dirección y expectativas. Se venden como una alternativa de bajo costo a muchos de los costosos sistemas de administración de contenido (CMS) de alto nivel que la empresa ya ha investigado. Luego, a medida que avanza el proyecto, los requisitos se transforman y se vuelven más complicados. Necesita más código personalizado, que finalmente se vuelve lo suficientemente complejo como para que admitir el código se convierta en un problema.

A partir de aquí, las cosas suelen salirse de control. El equipo de desarrollo ha renunciado a la premisa de quedarse con la funcionalidad lista para usar (OOTB) con una base de código limitada. En su lugar, tienen un enfoque totalmente personalizado, que va desde páginas maestras totalmente personalizadas hasta posiblemente una aplicación alojada por el proveedor (PHA) o, como lo llaman ahora, un complemento alojado por el proveedor.

Ya puedo escuchar los suspiros y ver los ojos en blanco. "Tony, estos son enfoques de utilización perfectamente válidos". "Tenemos ambos y a nuestros usuarios les encantan los sitios y no tenemos problemas para apoyarlos". De ninguna manera afirmo que ninguno de estos métodos sea incorrecto, ni que uno sea ventajoso sobre el otro, pero sí creo que ambos enfoques simplemente pierden la oportunidad de utilizar completamente lo que la plataforma de SharePoint tiene para ofrecer.

Además, creo que estos dos modelos dan como resultado que la empresa sienta que SharePoint es demasiado caro para lo que se usa, o que el departamento de TI sienta que simplemente podría haber desarrollado la misma funcionalidad a través de servidores web y páginas HTML o un CMS enlatado. solución en la nube. Cualquiera de las dos opiniones deja a la empresa ya TI con la sensación de que SharePoint no parece ser la herramienta adecuada para sus necesidades.

¿Beneficios de SharePoint Gone AWOL?

Para que podamos comprender mejor dónde estamos, debemos dar un paso atrás y revisar cómo llegamos aquí.

Lo llevaré de regreso a la simple pregunta de "¿Cómo se enteró de SharePoint?" Desde mi experiencia personal y la experiencia de muchos otros líderes de TI con los que he hablado, SharePoint como plataforma técnica fue presentada a la empresa por el equipo de infraestructura con la ayuda de sus asesores de Microsoft Enterprise.

Por lo general, la primera granja de servidores de SharePoint es una especie de banco de pruebas que se entrega a la empresa como parte de su contrato empresarial con Microsoft. En este punto, la mayoría de las empresas contratan a un cliente comercial e implementan su primera colección de sitios con un solo sitio de grupo. El cliente comercial ama las bibliotecas de documentos y la capacidad de colaborar y compartir documentos, por lo que comienza a utilizar el sitio como parte de sus procesos comerciales.

Esto puede sonar perfectamente aceptable para muchos de ustedes y, con toda honestidad, puede ser un caso de uso viable para SharePoint. Pero una vez que profundiza un poco más en SharePoint, se da cuenta de que es mucho más que una plataforma implementada y compatible con el equipo de infraestructura: es un espacio de aplicación sólido que requiere la estrecha colaboración de los equipos de infraestructura, arquitectura empresarial y aplicaciones.

No soy una persona "anti-infraestructura" o alguien que se opone políticamente al equipo de infraestructura, pero sin la colaboración de los socios correctos desde el principio, se corre el riesgo de no comprender el alcance completo de la plataforma de SharePoint y, por lo tanto, no están preparados para las estrategias comerciales apropiadas y el plan de utilización. Esta situación no es exclusiva de la plataforma de SharePoint y apunta a un problema mucho mayor de colaboración y estrategia adecuadas, al que se enfrentan muchos departamentos de TI.

Su cliente comercial es la clave

Con demasiada frecuencia, muchas organizaciones técnicas no tienen absolutamente ninguna estrategia comercial cuando se trata de SharePoint. Simplemente tienen un pequeño proceso agregado a los existentes sobre cómo solicitar y crear un sitio de SharePoint. Es posible que ni siquiera incluyan ningún tipo de control sobre el proceso de creación del sitio, lo que puede dar lugar a un gran volumen de colecciones de sitios y, finalmente, a un problema de soporte.

Puede haber alguna conversación básica y educación sobre el uso de algunos de los conceptos más grandes, como las colecciones de sitios y la búsqueda en SharePoint . Pero las discusiones de estrategia pueden volverse muy complicadas. Debido a esto, muchas organizaciones técnicas simplemente deciden finalizar su estrategia en el proceso de creación del sitio. En su lugar, comencemos despacio y con las características clave básicas de SharePoint.

¿Quiénes son sus clientes comerciales? ¿Son el equipo técnico corporativo, su equipo de marketing regional o quizás el equipo de I+D? Como dije anteriormente, la implementación de SharePoint generalmente la inicia el equipo de infraestructura y luego se filtra lentamente hacia la población de clientes comerciales.

En algunos casos, sus clientes comerciales ya habrán oído hablar de SharePoint en un contexto más simple cuando estén considerando alguna aplicación de línea de negocio clave a gran escala, que es donde generalmente comienza el segundo uso de SharePoint. Sin una estrategia de adopción comercial clara, será un viaje muy lento y arduo para el equipo técnico garantizar que su granja de servidores de SharePoint tenga la cantidad adecuada de adopción y uso.

En mi caso, la mayoría de los sitios de SharePoint que ya se crearon cuando me presentaron a SharePoint eran simplemente sitios de colaboración con grandes bibliotecas de documentos con estructuras de carpetas muy complicadas y enrevesadas.

Algunos de los nombres de las carpetas eran en realidad oraciones pequeñas para que el equipo pudiera entender exactamente qué tipos de documentos había en la carpeta. No había etiquetas de metadatos, ni tipos de contenido, simplemente documentos en carpetas.

Todo el proceso de colaboración consistió en compartir los documentos reales. Había un repositorio único donde todos podían compartir documentos y ese era el alcance de la colaboración para el equipo. Eso es lo que el cliente comercial vio como el mayor valor de SharePoint.

No es de extrañar que, cuando comencé a hablar con la gente de la empresa, su impresión de SharePoint fuera, en el mejor de los casos, poco entusiasta. Incluso algunos de mis homólogos técnicos comenzaron a argumentar que podríamos ahorrar una gran cantidad de costos si simplemente compráramos recursos compartidos de archivos para manejar los archivos y las estructuras de carpetas.

Muchas de las funciones básicas de SharePoint simplemente no se comunicaron correctamente a mi empresa y, en cierta medida, incluso al equipo técnico. Se vendieron en SharePoint como una increíble herramienta CMS con grandes posibilidades para fortalecer la colaboración y la innovación, pero lo mejor que se nos ocurrió fue compartir archivos.

Durante una de mis primeras entrevistas dentro de mi empresa, descubrí que el motivo de algunas de las estructuras de carpetas largas era proporcionar cierto nivel de estructura para que las personas encontraran ciertos archivos. La empresa ni siquiera estaba al tanto de las capacidades de búsqueda básicas de SharePoint , y mucho menos de seguir las mejores prácticas de SharePoint. Necesitaba encontrar una manera de involucrar a mis clientes comerciales para que no solo pudieran utilizar SharePoint de una manera más eficiente, sino también para educarlos sobre algunas de las fortalezas reales de la plataforma.

Presentación de un mejor caso de negocios

Según los comentarios de las entrevistas anteriores con clientes comerciales, me di cuenta de que tendría que empezar de nuevo con la educación. Pero en base a la granja ya grande que teníamos actualmente, ¿cómo iba a poder "empezar de nuevo" cuando las cosas ya estaban avanzando?

La mayoría de los sitios eran sitios de colaboración en equipo con bibliotecas de documentos. Así que decidí comenzar con las bibliotecas de documentos. Uno de mis clientes comerciales acordó trabajar conmigo y mi equipo en la reestructuración de sus bibliotecas de una manera que les permitiera minimizar las estructuras de carpetas mientras aumentaba la visibilidad de encontrar el archivo correcto que el usuario estaba buscando.

A medida que profundizamos en la estructura de algunos de los sitios, me resultó evidente que las estructuras de carpetas eran en realidad elementos de datos y agrupaciones de los distintos tipos de archivos en los que colaboraba el equipo. Así que decidí comenzar con una característica muy básica, pero poderosa, de SharePoint: las etiquetas de metadatos.

Siempre he sentido que una de las formas más poderosas de educar a cualquier cliente sobre una tecnología era simplemente desarrollar algún tipo de POC. El problema con los POC es que tienen un impacto en los costos. Debe tener cuidado de no desarrollar completamente una aplicación para que la empresa decida que no es lo que quiere.

En mi caso, el costo fue mínimo, pero el valor fue potencialmente enorme. Decidí tomar varias bibliotecas de documentos, cada una de las cuales tenía 20 o más carpetas separadas, y recrearlas como una biblioteca de documentos con metadatos y tipos de contenido. En lugar de tratar de explicar los tipos de contenido, fue más fácil mostrar cómo el uso de un tipo de contenido no solo podría agregar a la estructura de datos, sino también permitirles gobernar adecuadamente los metadatos adicionales asociados con un archivo.

El efecto bola de nieve

Muchos de los archivos contenían información importante y muy útil. La empresa decidió agrupar los archivos utilizando una estructura de carpetas muy complicada. Por ejemplo, tenían una carpeta para cada una de sus 15 marcas y, dentro de esas carpetas, tenían subcarpetas para marketing, finanzas y otras categorías clave; dentro de esas subcarpetas tenían aún más subcarpetas.

Esto les había permitido encontrar más fácilmente un archivo o archivos en particular, en lugar de tener que abrir y ver archivos individuales. Pero debido a esta complicada estructura de carpetas, ahora necesitaban un proceso comercial para garantizar que cada archivo se colocara en la carpeta correcta. Descubrieron que el nuevo proceso comercial era simplemente demasiado difícil de administrar y muchos archivos terminaron en el lugar equivocado.

Esto me permitió incorporar y explicar el uso de metadatos al negocio. Dividí la estructura del archivo en algunos tipos de contenido clave, que luego usamos para incluir elementos de datos clave, junto con la validación de datos importantes. Fue este enfoque simple de tipos de contenido, metadatos y validación de datos el primer gran éxito en mi viaje para presentarle a mi empresa un mejor caso de negocios para SharePoint.

Ahora que tenía la atención de la empresa, decidí hacer un recorrido sencillo por la biblioteca de documentos con las partes interesadas clave. Les mostré el verdadero valor de los metadatos y los tipos de contenido filtrando y clasificando sus datos.

Para mi asombro, simplemente estaban asombrados por algunas de las funciones básicas de SharePoint que ni siquiera sabían que existían. Entonces decidí incluir una página de filtro personalizada para mostrarles realmente lo que se podía hacer con la creación de una página simple, elementos web y filtrado.

Tuve mucho cuidado de no personalizar completamente ninguna de estas páginas. Quería usar solo elementos web OOTB. De esa forma, tendrían una mejor comprensión de las características básicas de SharePoint antes de que yo pasara a escenarios más complicados. La página personalizada fue un gran éxito y ni siquiera habíamos discutido las capacidades extendidas que el motor de búsqueda les proporcionaría. Quería posponer el motor de búsqueda hasta después de tener una mejor adopción de los conceptos básicos de SharePoint.

Flujos de trabajo de SharePoint: la clave

En mi humilde opinión, los flujos de trabajo de SharePoint han sido el factor más importante en mi capacidad para educar a mis clientes comerciales y garantizar la adopción y el uso de SharePoint dentro de mi organización. Los flujos de trabajo fueron la primera característica que me llamó la atención en ese primer VSLive que mencioné, y fueron un importante contribuyente a mi primer POC completo de SharePoint que incorporó nuestros procesos SDLC.

Cuando se trata de SharePoint, las conversaciones iniciales que tengo con mis clientes comerciales suelen ser en torno a sus procesos comerciales. Los procesos comerciales son clave para usar SharePoint para aumentar la productividad y reducir los costos, algo que cualquier cliente comercial está ansioso por discutir.

Como les he dicho a muchos altos ejecutivos de TI, prácticamente puedo garantizar el uso y la adopción de SharePoint simplemente a través de procesos comerciales. Cada unidad de negocio tiene procesos, y la mayoría de estos procesos tienen puntos de control o puntos de aprobación, y aquí es donde los flujos de trabajo resultan útiles, ya sea mediante el envío de un correo electrónico de aprobación o la creación de una tarea de aprobación.

Una vez que he convencido a un cliente comercial de cómo los flujos de trabajo pueden mejorar sus procesos y reducir sus costos, lo educo sobre cómo pueden usar esas mismas tareas de aprobación para luego crear acuerdos de nivel de servicio (SLA) o indicadores clave de rendimiento (KPI).

¿Qué tan bueno sería para una unidad de negocios saber cuánto tiempo lleva revisar y aprobar un documento? Luego podrían tomar esa información y adoptar una estrategia para mejorar el proceso general. Eso les permitiría crear KPI para monitorear y gobernar el proceso.

Para mostrar el compromiso de la alta dirección con la mejora de sus procesos, incluso podrían incluir las mejoras como parte de sus programas de objetivos de bonificación. Este suele ser el jonrón que convence a un cliente empresarial del verdadero valor que puede lograr mediante la adopción y el uso de SharePoint.

El futuro

Cuando escuché por primera vez sobre Office 365 y SharePoint Online, entendí el valor de un entorno de SharePoint alojado, pero nuevamente tuve problemas para convencer a mis clientes comerciales de que esta nueva dirección era lo mejor para su futuro. Me entusiasmó escuchar acerca de las PHA, pero también fui cauteloso sobre el costo potencial que esto podría tener desde una perspectiva de soporte de aplicaciones.

Mi empresa había comenzado por la dirección de los proveedores de desarrollo de terceros con un modelo de subcontratación, lo que puede llevar fácilmente a los proveedores a crear aplicaciones comerciales complicadas con un gran costo residual de mantenimiento y mejoras.

Al igual que con todos los modelos alojados, debemos prepararnos para el cambio. Como seres humanos, realmente no nos gusta el cambio y, como equipos de soporte técnico, a menudo tenemos miedo del cambio y de cómo afectará la capacidad de nuestro equipo para avanzar.

Cuando me enteré por primera vez de la decisión de Microsoft de desaprobar InfoPath y luego de la introducción de Flow como motor de flujo de trabajo, mi reacción fue: "¡Aquí vamos de nuevo!" Microsoft iba a tomar otra decisión comercial que me dificultaría "vender" su nueva dirección de SharePoint. Cuando comencé a revisar lo que Flow tenía para ofrecer, me decepcionó lo que vi.

Pero Microsoft tenía su visión del futuro y simplemente no la entendí, hasta que comencé a ver algunas de las capacidades de Flow con respecto a los puntos de integración. Flow se integra con muchas de las aplicaciones existentes en la actualidad, pero también permite que una empresa cree sus propios puntos de integración. Esto lo ha convertido en un jugador importante en mis discusiones comerciales sobre procesos comerciales mejorados a través de la integración con varias aplicaciones de línea de negocios.

Movilidad

Esto se ha convertido en un tema de conversación estándar que yo, como ejecutivo técnico, tengo con muchos de mis clientes comerciales. Está bien hablar sobre el diseño web receptivo y cómo maximizarlo para mejorar su presencia en la web móvil. También podemos analizar cómo SharePoint utiliza páginas web receptivas para crear una mejor experiencia de SharePoint en dispositivos móviles. Microsoft incluso ha desarrollado una aplicación móvil de SharePoint. Pero, por lo general, la discusión se dirige en la dirección de tener una aplicación móvil independiente.

Tan pronto como escucho las palabras "aplicación móvil independiente", escucho el sonido de una caja registradora: muchas aplicaciones móviles tienen un alto costo junto con un modelo de soporte especializado. Mi respuesta del mundo de SharePoint es PowerApps.

Como lo hice en el pasado, inmediatamente comencé a desarrollar una aplicación POC de PowerApps móvil. Utiliza listas y bibliotecas de SharePoint existentes como fuente de datos de back-end para mi aplicación. PowerApps es lo que yo llamo una plataforma de desarrollo basada en configuración : permite un desarrollo muy rápido de aplicaciones móviles.

Un usuario puede simplemente seleccionar la opción de PowerApps en SharePoint para crear su propia aplicación móvil de PowerApps. Incluso crea automáticamente muchas de las pantallas para agregar y editar nuevos elementos en una lista o biblioteca. También ha sido probado con todos los líderes actuales en el espacio de dispositivos móviles. Tiene su propio IDE, junto con un lenguaje basado en configuración muy simple que un desarrollador técnico o incluso un usuario experto en tecnología puede adaptar fácilmente.

Una vez más, tengo una gran herramienta/característica de SharePoint que puedo usar para mejorar la adopción y el uso de la plataforma de SharePoint. Incorpore esta nueva herramienta con SharePoint y Flow, junto con notificaciones automáticas y la capacidad de usar funciones inherentemente móviles como servicios de ubicación y llamadas telefónicas, y PowerApps se ha convertido en mi nuevo punto de conversación favorito para discutir con mis clientes comerciales sobre la adopción y utilización de SharePoint.

De hecho, mi POC no solo fue recibido con entusiasmo por mi empresa, sino que debido a mi uso de funciones móviles como servicios de ubicación y navegación GPS, se me pidió que presentara mi aplicación de POC a la ingeniería de PowerApps como un ejemplo de lo que se podía hacer con el herramienta.

De VSLive a las soluciones de SharePoint

Mientras estaba sentado en mi asiento junto a la ventana rumbo a San Francisco, nunca podría haber imaginado cómo ese simple viaje tendría un impacto tan importante en mi carrera técnica. SharePoint es una herramienta verdaderamente innovadora y colaborativa, y Microsoft continúa cumpliendo su visión y dirección con SharePoint.

Al igual que cualquiera de las miles de soluciones SaaS o PaaS que tenemos a nuestra disposición en la actualidad, debemos asegurarnos de comprender realmente cómo utilizar mejor estas soluciones. Al seguir mejorando nuestros procesos comerciales generales y satisfacer a nuestros clientes comerciales, SharePoint se ha convertido en una herramienta clave en mi arsenal. Espero con ansias el futuro y lo que SharePoint tendrá que ofrecer para mí y mi negocio.