SPC12: El segundo día

El segundo día de la SharePoint Conference empezó igual que el primero, con mucho contenido y poco tiempo para decidir a qué sesión asistir. Sin embargo, las sesiones han sido más bien flojas. No sé si soy yo o la mala suerte, pero la conferencia me está dejando un sabor de boca blando.

Voy a poner los apuntes que he ido tomando en el OneNote con el tablet, perdonad la escritura casi taquigráfica.

Las extranets

La primera sesión a la que he ido esta mañana ha sido la que hablaba de las mejoras prácticas para montar una extranet. El ponente fue Ian Woodgate. Estas son mis notas de la sesión:

El autoservicio no siempre es mejor solución. La gente lo tiene que "querer". ejemplo: los supermercados con autoservicio.

Definición de la extranet: no está clara. si lo quieres llamar extranet, es extranet.

¿Por qué montar una intranet?

- compartir documentos

- reducir las actividades manuales al máximo

- dar visibilidad a los proyectos, productos o procesos

La seguridad....muchas veces se pasa información muy sensible por correo electrónico.

Auditing: saber que la información se ha leído.

Los beneficios de la extranet

- satisfacción de los clientes

- menos errores

- menos carga de trabajo

- seguridad mejorada

- auditoría

- gestión efectiva de la información

- flexibilidad (sobre todo cuando no hay código)

¿Cómo es una extranet “maravillosa”?

- Está bien planificada, con el ROI calculado si puede ser. Hay que definir bien los roles y permisos de los usuarios. Recordar el ejemplo del supermercado con autoservicio....no siempre más es mejor. Aqui tambien hay que hacer adopción de usuarios.

- Con los temas legales resueltos. SLA, obligaciones frente a terceros, políticas de uso para que los acepten los usuarios.

- Diseño. Empezar con UX. Menos es más. Autoprovisionamiento y delegación de usuarios (los usuarios pueden invitar a externos sin que intervenga IT).

- Infraestructura: multibrowser, multidispositivo y con login federado a podr ser. Rápido y fiable.

- Gestión del día a día. De quién es la extranet? Quien da soporte? Como se contacta? Monitorización, promoción y mejoras incrementales.

¿Por que intranet con SharePoint 2013?

- Federación de identidad con seguridad

- Soporte para dispositivos móviles

- Posible en SharePoint Online

¿Donde ubicar la extranet?

- Abrir la intranet directamente a los usuarios externos. A favor: barato y un solo conjunto de contenido. En contra: complejo para gestionar la seguridad y es fácil que se "cuelen" cosas. Posibles problemas de rendimiento. Apto para negocios pequeños.

- Separar una parte de la intranet. Mejora la seguridad, pero tiene todo el resto de desventajas de la anterior. La información además está duplicada (hay que sincronizar la información a menudo). Para empresa mediana.

- Un sistema separado. Mejora la seguridad y la escalabilidad, pero el coste es alto. Para empresas grandes. Se puede usar Office365 para la extranet y onpremises para intranet. (SPO permite invitar los usuarios externos sin CAL, solo con LiveID).

Estructura de la intranet

- Matriz de Clientes y Proyectos (productos, areas...). ¿Como mapearlo a la estructura de ShaePoint? ¿Sitios de cliente o de proyecto? Depende de cada caso.

No code: construir o comprar?

1. No code, OOB.
2. Herramientas de terceros.
3. Desarrollo a medida, en este orden de prioridad.

El código a medida añade un factor diferencial? si no, no vale la pena. Puede ser que el código a medida es más eficiente a corto plazo, pero a largo plazo no.

Licenciamiento

- CAL o External Connector?

- SPO tiene soporte para usuarios externos (50, aunque se admiten hasta 1000)

- SharePoiint Foundation vale la pena en muchos casos. Se ahorran muchas licencias.

Riesgos

- la imagen proyectada por la intranet puede dañar la imagen de marca.

¿Como recoger requrimientos efectivos para despliegues de SharePoint?

La segunda sesión fue impartida por Shannon Bray.

Ha hablado de las 4 fases de un proyecto y de como los requerimientos minimos insuficientes y el “scope creep” (crecimiento de alcance) pueden matar los proyectos.

Los requerimientos físicos de SharePoint 2013 han cambiado respecto al 2010:

• SF2013: 8 GB RAM
• SP2013 un solo servidor: 24 GB
• WFE o APP en una granja de 3 capas: 12 GB

¿A quien hay que hacer contento (key players)?

¿A que iniciativa se suscribe SharePoint en la empresa? ¿Con que objetivos de negocio? Hay conflictos entre los objetivos?

Pregunta importante: "qué haría que este proyecto sea un éxito?"

¿Quién mantendrá la solución?

Governance está para poner un camino por donde tiene que caminar SharePoint.

Arquitectura de la información

- como encontrarán la información? buscando o navegando

- una sola biblioteca ya no es imposible (10 millones de doc por biblioteca)

- información que pertenece a otro equipo, como encontrarla?

Procesos de negocio

- que procesos hay y que contenido está relacionado?

- quien es el responsable de los workflows?

- integración con otros sistemas?

Seguridad

- quien/cuando/que/por que/como?

- ActiveDirectory con empresas grandes puede ser una pesadilla

- usuarios internos y externos? los mismos derechos?

- información personal (PII): como protegerla?

- SSL, TDE? Puertos, proxys, balanceadores de carga? el impacto que tiene en los servicios de SP?

- gestión de contraseña (a nadie le gusta cambiará)

- gestión de amenazas

- configuración de GPO: está decumentada?

- grupos en SP o AD? el gran debate

Business intelligence

- reports, gráficos, dashboards y scorecards

- Excel services, performance point y visio: planificar con antelación

Office

- qué versión?

- office web apps ahora están en otro servidor

Continuidad de negocio

- SLA

- RPO

- RTO

- quién es el responsable? del backup? del plan?

- cuando se hacen las pruebas del plan de backup?

- presupuesto límite de disaster recovery: crece exponencialmente

- estas preguntas pueden salvar o costar millones!!

high availability: no se cae
disaster recovery: cuando y como se levanta al caer?

- geoclustering: hay un limite de latencia aceptada para separar servidores físicamente

Limite de soporte

- saber los límites de sharepoint

- ojo con los soft limits: p.ej. más de 10 app pools en un servidor. pueden ralentizar mucho. revisar el articulo de technet.

No preguntes si quieren load balancer, sino cual quieren. ojo con el NLB de Windows...tiene limites. f5 es caro pero mejor en muchos casos.

Todo el entorno SP en un Blade: ojo con el cable que desenchufas sin querer al pisarlo

Cambios en la topología

- La cache distribuida hay que ponerla en un servidor aparte

- Ojo con los scripts de instalación de SP, que no pongan la caché distribuida en todos los servidores

- Office web apps van en otro servidor

- El entorno ahora tiene más servidores. puede haber problemas de rendimiento con ntlm cuando hablan los servidores entre si

Rendimiento y fiabilidad

- pregunta que interesa: usuarios concurrentes? pregunta de entrevista: que quiere decir usuarios concurrentes (son los que entran en la granja en 60 segondos)

- presupuesto para user adoption?

- métricas definidas y quien las vigila? ignorar no es una opción.

- Solo poner los servicios para los que tienes requerimientos. No más.

- hora punta: asegurarse el rendimiento en ese intervalo (warmups...)

- Quien monitoriza SharePoint?

- NUMA boundaries para la RAM

- contención y encriptación en la red

- distribución de blades

El ponente proveerá un PDF a modo de checklist.

Caso de cliente: Merck y la planificación integrada de negocio

La tercera sesión fue de un caso práctico de SharePoint con Project Server para la farmacéutica Merck impartido por Phyllis Post

Se hizo la decisión para integrar SharePoint y Project Server para proveer la planificación integrada. Además, se hizo durante una fusión de dos empresas en una.

Merck tiene 10.000 usuarios en I+D. Muchos departamentos, niveles ejecutivos, órganos de gobierno. Había muchas expectativas a alto nivel y hubo soporte desde el nivel ejecutivo (IT era la "fuerza ejectora"). El cambio cultural se llevó a cabo desde el negocio.

Antes

- información desconectada y diversa

- inconsistencias, email arriba y abajo

- muchos procesos y metodologías diferentes (1 por departamento). Lenguaje no compartido.

- analíticas heterogéneas (Excel, Cognos...). 30 días de delay entre tener los datos y tenerlos procesados.

En enero de 2010 se decidió mejorar la toma de decisiones (calidad y transparencia y conectar las diferentes comunidades dentro de Merck. El objetivo era mejorar la calidad, el ciclo de proyecto, transparencia y crear equipo para el futuro.

Clave: moverse desde tener unas decisiones de calidad pero ejecutadas lentamente hacia unas decisiones informadas pero ejecutadas rápidamente.

Conectar las áreas funcionales con el pipeline: Planificación, Costes, Colaboración y Planificación de recursos funcionales.

Plataforma: SP2010 para sitios de franquicia, equipo y governance, así como colaboración de equipos. PS2010 para planificar proyectos, costes y plan de recursos. SQL2010 para reporting y datos de referencia.

Ahora

Acceso en tiempo real a la información de planing de proyectos, con reports para ver información crítica. La herramienta de scheduling se hizo con un lenguaje compartido y a nivel de área funcional.

Se han montado más de mil espacios colaborativos (con plantillas estandarizadas)

- reducción en el tiempo de acceso a la información

- sitios de governance para ver información compuesta y soporte para reuniones.

Se hizo un modelo simplificado y a medida de planificación de recursos funcionales (los proyectos son a largo plazo).

Los costes se recogen con los forecasts y los costes reales se agregan para dar información en tiempo real. Este fue uno de los objetivos críticos (y factor de éxito) a nivel de negocio.

La información viene de SAP, de Timesheets (en Project Server separado de la granja de planificación) y otros costes para dar un nivel agregado. No se llega a nivel individual para ver los costes de cada persona porque no es relevante.

La información de dashboards tiene asociada la información de quien es responsable de cada área de proyecto para que los ejecutivos pueden contactar rápidamente para pedir información ampliada.

IT ya no es el responsable de dar la información, sino de proveer de servicios para que otras areas los usen. Se quitan del medio.

El siguiente objetivo para Merck es extender este buen trabajo en I+D a otras areas de la empresa.

CRM, workflows y Visio Services

La última sesión fue explicada por Dean Halstead de Microsoft. Él hablo de como conectar las formas de Visio a los datos de Dynamics CRM y workflows de SharePoint.

Versión "On the Road" (de andar por casa)

1. Crear un workflow de SP2013 en Visio 2013

2. Definir "Shape Data" en Visio a los estados de workflow (esto serán las claves primarias de datos)

3. Enlazar a datos con el asistente. Los datos se agregan y se representan en una barra por encima de la de Visio en el workflow.

Versión empresarial subida a SharePoint

1. Guardar el Excel en SharePoint.

2. Reconectarse al Excel desde Visio

3. Hacer "Publish in SharePoint"

4. Poner una webpart de Visio Web View en la página

La información de workflows en CRM está en la base de datos de Log no en la base de datos normal de CRM.