Explorando os benefícios comerciais do SharePoint

Alguém em sua empresa já considerou se estava obtendo o máximo valor do SharePoint? À primeira vista, esta parece ser uma pergunta ridícula. Por que uma empresa implementaria o SharePoint se ainda não determinou seus verdadeiros benefícios e valor geral?

Mas em minhas conversas diárias com outras pessoas técnicas e de negócios, fico surpreso com a frequência com que eles não conseguem identificar e quantificar o ROI real que veem no SharePoint. Ainda mais surpreendente é a quantidade de empresas que não utilizaram totalmente seu ambiente SharePoint para reduzir o custo geral dos negócios e aumentar a produtividade.

As especificações técnicas do SharePoint são importantes, mas neste artigo quero compartilhar mais com você sobre o que normalmente está faltando na estratégia de negócios das empresas que usam o SharePoint.

Por que usar o SharePoint: uma visão…

Em um domingo no inverno de 2009, sentei-me na janela, olhando ansiosamente para fora de um 747. Eu estava indo para São Francisco para participar da minha primeira conferência, VSLive.

Na época, eu trabalhava em uma grande empresa de cosméticos. Eu estava animado para participar das aulas do SharePoint para as quais me inscrevi: era uma pilha de tecnologia relativamente nova dentro da empresa e eu queria ver por mim mesmo o que o SharePoint realmente poderia fazer pela empresa.

Eu não fiquei desapontado. Saí de São Francisco com tanta empolgação, uma sensação que eu achava que estava muito longe da minha carreira profissional. Eu estava tão ansioso para voltar ao escritório para discutir essa ferramenta incrível com minha equipe ... apenas para ser puxado de volta à realidade da minha existência como diretor da equipe de Sistemas de Informação Global:

[Diretor Executivo – GIS] : “Claro, já ouvi falar do SharePoint. Não vejo o motivo de tanto barulho... Poderíamos fazer as mesmas páginas da web dentro de nossa própria fazenda da web. Acho que você está perdendo seu tempo.”

[Gerente de Relacionamento Empresarial – GIS] : “É muito simples e feio. Eu nunca serei capaz de vender isso para nenhum dos meus clientes de negócios.”

[Desenvolvedor Sênior – GIS] : “Qual é o problema? Não vejo agregando valor. Parece muito complicado para trabalhar. Acho que o Active Server Pages é uma direção muito melhor.”

A única pessoa que mostrou um pouco de interesse foi o diretor a quem eu me reportava diretamente. Ele não sabia muito sobre as tecnologias do SharePoint, mas sabia que eu estava muito empolgado com isso para simplesmente ignorá-lo.

Ele me pediu para marcar uma pequena reunião para eu discutir um pouco mais sobre essa tecnologia. Essa reunião nos levou a projetar uma prova de conceito (POC) do SharePoint para nossa gerência sênior que acabaria se tornando um componente central no departamento de GIS. Isso automatizaria e agilizaria nossos novos processos de ciclo de vida de desenvolvimento de software (SDLC) e lideraria o caminho para a empresa adotar muitas vantagens do SharePoint, me catapultando para o nível proeminente de “The SharePoint Guy”. Nos oito anos seguintes, eu passaria muito do meu tempo na empresa utilizando o SharePoint como uma ferramenta de produtividade de baixo custo incrível. Para aqueles que quisessem ouvir, eu melhoraria muitos processos de negócios e reduziria seus custos, mas ainda havia muitos sites dentro da empresa que eram simples sites de equipe com bibliotecas de documentos. Eu era apenas uma pessoa, nadando rio acima para vender o SharePoint não apenas para minha empresa, mas também para os níveis mais altos da organização.

Isso soa familiar?

Nos últimos nove anos, observei que os usos do SharePoint na maioria das empresas ocorrem em um de dois cenários básicos.

1. Sites de equipe com bibliotecas de documentos

Esses sites geralmente são criados a partir do modelo Equipe e contêm uma ou mais bibliotecas de documentos que podem ter estruturas de pastas muito complicadas. Há muito pouco uso de tipos de conteúdo, tags de metadados ou fluxos de trabalho. Os sites são totalmente suportados pela unidade de negócios, cujos membros não têm conhecimento formal do SharePoint e não adotaram a função de “Usuário avançado”. O site foi criado pela equipe de infraestrutura ou suporte, que pode gerar um site rapidamente a partir de um simples tíquete de solicitação de suporte técnico.

2. Sites totalmente personalizados com uma base de código grande e complicada

Normalmente, esses são sites muito maiores com um público muito maior: intranets corporativas, RH corporativo e sites corporativos de TI são os candidatos usuais para esse tipo de uso do SharePoint.

Esses projetos geralmente começam com grande direção e expectativas. Eles são vendidos como uma alternativa de baixo custo para muitos dos caros e sofisticados sistemas de gerenciamento de conteúdo (CMSs) que a empresa já investigou. Então, à medida que o projeto avança, os requisitos se transformam e se tornam mais complicados. Ele precisa de mais código personalizado, que eventualmente se torna complexo o suficiente para que o suporte ao código se torne um problema.

A partir daqui, as coisas geralmente saem do controle. A equipe de desenvolvimento desistiu da premissa de ficar com a funcionalidade pronta para uso (OOTB) com uma base de código limitada. Em vez disso, eles têm uma abordagem totalmente personalizada, variando de páginas mestras totalmente personalizadas a possivelmente um aplicativo hospedado pelo provedor (PHA) ou - como agora o chamam - um suplemento hospedado pelo provedor.

Já posso ouvir os suspiros e ver os olhos revirando. “Tony, essas são abordagens de utilização perfeitamente válidas.” “Temos ambos e nossos usuários adoram os sites e não temos problemas em apoiá-los.” Não estou afirmando de forma alguma que qualquer um desses métodos esteja errado, nem que um seja vantajoso sobre o outro, mas acredito que ambas as abordagens simplesmente perdem a oportunidade de utilizar totalmente o que a plataforma SharePoint tem a oferecer.

Além disso, acredito que esses dois modelos resultam na sensação de negócios como o SharePoint é muito caro para o que eles usam, ou que o departamento de TI sente que poderia simplesmente ter desenvolvido a mesma funcionalidade por meio de servidores da Web e páginas HTML ou um CMS enlatado solução em nuvem. Qualquer uma das opiniões deixa tanto a empresa quanto a TI sentindo que o SharePoint não parece ser a ferramenta certa para suas necessidades.

Benefícios do SharePoint AWOL?

Para entendermos melhor onde estamos, precisamos dar um passo atrás e rever como chegamos aqui.

Vou levá-lo de volta à pergunta simples de "Como você ouviu falar do SharePoint?" Da minha experiência pessoal e da experiência de muitos outros líderes de TI com quem conversei, o SharePoint como plataforma técnica foi apresentado à empresa pela equipe de infraestrutura com a assistência de seus consultores Microsoft Enterprise.

Normalmente, o primeiro farm do SharePoint é uma espécie de banco de testes fornecido à empresa como parte de seu Enterprise Agreement com a Microsoft. Nesse ponto, a maioria das empresas envolve um cliente comercial e implanta seu primeiro conjunto de sites com um único site de equipe. O cliente de negócios adora as bibliotecas de documentos e a capacidade de colaborar e compartilhar documentos e, portanto, começa a usar o site como parte de seus processos de negócios.

Isso pode parecer perfeitamente aceitável para muitos de vocês e, com toda a honestidade, pode ser um caso de uso viável para o SharePoint. Mas quando você se aprofunda um pouco mais no SharePoint, percebe que é muito mais do que apenas uma plataforma que a equipe de infraestrutura implementou e oferece suporte: é um espaço de aplicativo robusto que requer a colaboração estreita da infraestrutura, arquitetura corporativa e equipes de aplicativos.

Não sou uma pessoa “anti-infraestrutura” ou alguém que se opõe politicamente à equipe de infraestrutura, mas sem a colaboração dos parceiros corretos desde o início, você corre o risco de não entender todo o escopo da plataforma SharePoint e, portanto, estão despreparados para as estratégias de negócios e plano de utilização apropriados. Essa situação não é exclusiva da plataforma SharePoint e aponta para um problema muito maior de colaboração e estratégia adequadas, que está enfrentando muitos departamentos de TI.

Seu cliente de negócios é a chave

Muitas vezes, muitas organizações técnicas não têm absolutamente nenhuma estratégia de negócios quando se trata do SharePoint. Eles simplesmente têm um pequeno processo adicionado aos existentes sobre como solicitar e criar um site do SharePoint. Eles podem nem incluir qualquer tipo de governança em torno do processo de criação do site, o que pode levar a um volume muito grande de conjuntos de sites e, eventualmente, a um problema de suporte.

Pode haver alguma conversa e educação básica sobre o uso de alguns dos conceitos maiores, como conjuntos de sites e Pesquisa no SharePoint . Mas as discussões de estratégia podem ficar muito complicadas. Por causa disso, muitas organizações técnicas simplesmente decidem encerrar sua estratégia no processo de criação do site. Em vez disso, vamos começar devagar e com os principais recursos básicos do SharePoint.

Quem são seus clientes empresariais? Eles são a equipe técnica corporativa, sua equipe de marketing regional ou talvez a equipe de P&D? Como afirmei anteriormente, a implementação do SharePoint geralmente é iniciada pela equipe de infraestrutura e, em seguida, lentamente atinge a população de clientes corporativos.

Em alguns casos, seus clientes de negócios já devem ter ouvido falar sobre o SharePoint em um contexto mais simples quando estão considerando algum aplicativo de linha de negócios chave em grande escala, que é onde o segundo uso do SharePoint geralmente começa. Sem uma estratégia clara de adoção de negócios, será uma jornada muito lenta e árdua para a equipe técnica garantir que seu farm do SharePoint tenha a quantidade certa de adoção e uso.

No meu caso, a maioria dos sites do SharePoint que já foram criados quando fui apresentado ao SharePoint eram simplesmente sites de colaboração com grandes bibliotecas de documentos com estruturas de pastas muito complicadas e complicadas.

Alguns dos nomes das pastas eram na verdade pequenas frases para que a equipe pudesse entender exatamente quais tipos de documentos estavam na pasta. Não havia tags de metadados, nem tipos de conteúdo, apenas documentos em pastas.

Todo o processo de colaboração foi o compartilhamento dos próprios documentos. Havia um único repositório onde todos podiam compartilhar documentos e essa era a extensão da colaboração para a equipe. Isso é o que o cliente de negócios viu como o maior valor do SharePoint.

Não é de admirar que, quando comecei a falar com as pessoas da empresa, sua impressão do SharePoint fosse, na melhor das hipóteses, pouco entusiasmada. Até mesmo alguns de meus colegas técnicos começaram a argumentar que poderíamos economizar muito se simplesmente comprássemos compartilhamentos de arquivos para lidar com os arquivos e as estruturas de pastas.

Muitos dos recursos básicos do SharePoint simplesmente não foram comunicados adequadamente para minha empresa e, até certo ponto, até mesmo para a equipe técnica. Eles foram vendidos no SharePoint como uma ferramenta CMS incrível com grandes possibilidades de fortalecer a colaboração e a inovação, mas o melhor que conseguimos foi o compartilhamento de arquivos.

Durante uma das minhas primeiras entrevistas na minha empresa, descobri que o motivo de algumas das estruturas de pastas longas era fornecer algum nível de estrutura para as pessoas encontrarem determinados arquivos. A empresa nem conhecia os recursos básicos de pesquisa do SharePoint , muito menos seguir as práticas recomendadas do SharePoint. Eu precisava encontrar uma maneira de envolver meus clientes de negócios para que eles pudessem não apenas utilizar o SharePoint de maneira mais eficiente, mas também educá-los sobre alguns dos pontos fortes reais da plataforma.

Apresentando um caso de negócios melhor

Com base no feedback das entrevistas acima com clientes empresariais, percebi que precisaria começar tudo de novo com a educação. Mas com base na fazenda já grande que tínhamos atualmente, como eu poderia “começar de novo” quando as coisas já estavam avançando?

A maioria dos sites eram sites de colaboração de equipe com bibliotecas de documentos. Então decidi começar com bibliotecas de documentos. Um dos meus clientes de negócios concordou em trabalhar comigo e minha equipe na reestruturação de suas bibliotecas de uma maneira que lhes permitisse minimizar as estruturas de pastas e aumentar a visibilidade de encontrar o arquivo certo que o usuário estava procurando.

À medida que nos aprofundávamos na estrutura de alguns sites, ficou evidente para mim que as estruturas de pastas eram na verdade elementos de dados e agrupamentos dos vários tipos de arquivos com os quais a equipe estava colaborando. Então, decidi começar com um recurso muito básico, mas poderoso, do SharePoint: tags de metadados.

Sempre achei que uma das formas mais poderosas de educar qualquer cliente sobre uma tecnologia era simplesmente desenvolver algum tipo de POC. O problema com os POCs é que eles têm um impacto no custo. Você precisa ter cuidado para não desenvolver totalmente um aplicativo para que apenas a empresa decida que não é o que eles querem.

No meu caso, o custo foi mínimo, mas o valor foi potencialmente enorme. Decidi pegar várias bibliotecas de documentos, cada uma com 20 ou mais pastas separadas, e recriá-las como uma biblioteca de documentos com metadados e tipos de conteúdo. Em vez de tentar explicar os tipos de conteúdo, foi mais fácil mostrar como o uso de um tipo de conteúdo pode não apenas adicionar à estrutura de dados, mas também permitir que eles governem adequadamente os metadados adicionais associados a um arquivo.

O efeito bola de neve

Muitos dos arquivos continham informações importantes e muito úteis. A empresa decidiu agrupar os arquivos usando uma estrutura de pastas muito complicada. Por exemplo, eles tinham uma pasta para cada uma de suas 15 marcas e, dentro dessas pastas, havia subpastas para marketing, finanças e outras categorias-chave; dentro dessas subpastas eles tinham ainda mais subpastas.

Isso permitiu que eles encontrassem mais facilmente um arquivo ou arquivos específicos, em vez de ter que abrir e visualizar arquivos individuais. Mas por causa dessa estrutura de pastas complicada, eles agora precisavam de um processo de negócios para garantir que cada arquivo fosse colocado na pasta certa. Como eles descobriram, o novo processo de negócios era simplesmente muito difícil de gerenciar e muitos arquivos acabavam no lugar errado.

Isso me permitiu incorporar e explicar o uso de metadados para o negócio. Eu dividi a estrutura do arquivo em alguns tipos de conteúdo chave, que então usamos para incluir elementos de dados chave, juntamente com validação de dados importantes. Foi essa abordagem simples de tipos de conteúdo, metadados e validação de dados que foi o primeiro grande sucesso em minha jornada para apresentar à minha empresa um caso de negócios melhor para o SharePoint.

Agora que eu tinha a atenção do negócio, decidi fazer um simples passo a passo da biblioteca de documentos com as principais partes interessadas. Mostrei a eles o verdadeiro valor dos metadados e tipos de conteúdo filtrando e classificando seus dados.

Para minha surpresa, eles ficaram simplesmente impressionados com alguns dos recursos básicos do SharePoint que eles nem sabiam que existiam. Decidi então incluir uma página de filtro personalizada para realmente mostrar a eles o que poderia ser feito com uma simples criação de página, web parts e filtragem.

Tomei muito cuidado para não personalizar totalmente nenhuma dessas páginas. Eu queria usar apenas Web Parts OOTB. Dessa forma, eles teriam uma melhor compreensão dos recursos básicos do SharePoint antes de eu passar para cenários mais complicados. A página personalizada foi um grande sucesso e nem havíamos discutido os recursos estendidos que o mecanismo de pesquisa forneceria para eles. Eu queria adiar o mecanismo de pesquisa até depois de ter uma melhor adoção dos fundamentos do SharePoint.

Fluxos de trabalho do SharePoint: a chave

Na minha humilde opinião, os fluxos de trabalho do SharePoint têm sido o fator mais importante na minha capacidade de educar meus clientes de negócios e garantir a adoção e o uso do SharePoint em minha organização. Os fluxos de trabalho foram o primeiro recurso que chamou minha atenção no primeiro VSLive que mencionei e foram um dos principais contribuintes para meu primeiro POC completo do SharePoint que incorporou nossos processos SDLC.

Quando se trata do SharePoint, as conversas iniciais que tenho com meus clientes de negócios geralmente giram em torno de seus processos de negócios. Os processos de negócios são fundamentais para usar o SharePoint para aumentar a produtividade e reduzir os custos, algo que qualquer cliente de negócios está ansioso para discutir.

Como já disse a muitos executivos seniores de TI, posso praticamente garantir o uso e a adoção do SharePoint simplesmente por meio de processos de negócios. Todas as unidades de negócios possuem processos, e a maioria desses processos possui checkpoints ou pontos de aprovação, e é aí que os fluxos de trabalho são úteis, seja por meio do envio de um e-mail de aprovação ou da criação de uma tarefa de aprovação.

Depois de convencer um cliente de negócios de como os fluxos de trabalho podem melhorar seus processos e reduzir seus custos, eu os instruo sobre como eles podem usar essas mesmas tarefas de aprovação para criar acordos de nível de serviço (SLAs) ou indicadores-chave de desempenho (KPIs).

Quão bom seria para uma unidade de negócios entender quanto tempo leva para um documento ser revisado e aprovado? Eles poderiam então pegar essas informações e adotar uma estratégia para melhorar o processo geral. Isso permitiria que eles criassem KPIs para monitorar e controlar o processo.

Para mostrar o comprometimento da alta administração com a melhoria de seus processos, eles podem até incluir as melhorias como parte de seus programas objetivos de bônus. Geralmente, esse é o home run que convence um cliente de negócios do verdadeiro valor que ele pode obter por meio da adoção e uso do SharePoint.

O futuro

Quando ouvi falar do Office 365 e do SharePoint Online pela primeira vez, compreendi o valor de um ambiente hospedado do SharePoint, mas novamente me esforcei para convencer meus clientes de negócios de que essa nova direção era a melhor para o futuro deles. Fiquei empolgado ao ouvir sobre os PHAs, mas também estava cauteloso com o custo potencial que isso poderia ter do ponto de vista do suporte a aplicativos.

Minha empresa começou na direção de fornecedores de desenvolvimento de terceiros com um modelo de terceirização, o que pode facilmente levar os fornecedores a criar aplicativos de negócios complicados com um grande custo residual para manutenção e aprimoramentos.

Como em todo modelo hospedado, precisamos nos preparar para a mudança. Como humanos, realmente não gostamos de mudanças e, como equipes de suporte técnico, muitas vezes temos medo de mudanças e como isso afetará a capacidade de nossa equipe de avançar.

Quando ouvi pela primeira vez sobre a decisão da Microsoft de descontinuar o InfoPath e, em seguida, a introdução do Flow como um mecanismo de fluxo de trabalho, minha reação foi: “Lá vamos nós de novo!” A Microsoft tomaria outra decisão de negócios que tornaria mais difícil para mim “vender” sua mais nova direção do SharePoint. Quando comecei a revisar o que o Flow tinha a oferecer, fiquei desapontado com o que vi.

Mas a Microsoft tinha sua visão de futuro, e eu simplesmente não entendi – até que comecei a ver alguns dos recursos do Flow com relação aos pontos de integração. O Flow se integra a muitos dos aplicativos existentes hoje, mas também permite que uma empresa crie seus próprios pontos de integração. Isso o tornou um participante importante em minhas discussões de negócios sobre processos de negócios aprimorados por meio da integração com vários aplicativos de linha de negócios.

Mobilidade

Isso se tornou um tópico padrão de conversa que eu, como executivo técnico, tenho com muitos de meus clientes de negócios. Não há problema em discutir web design responsivo e como maximizá-lo para melhorar sua presença na web móvel. Também podemos discutir como o SharePoint está utilizando páginas da Web responsivas para criar uma melhor experiência do SharePoint em dispositivos móveis. A Microsoft até desenvolveu um aplicativo móvel do SharePoint. Mas geralmente, a discussão segue na direção de ter um aplicativo móvel autônomo.

Assim que ouço as palavras “aplicativo móvel autônomo”, ouço o cha-ching de uma caixa registradora: muitos aplicativos móveis têm uma pegada de alto custo junto com um modelo de suporte especializado. Minha resposta do mundo do SharePoint é PowerApps.

Como fiz no passado, comecei imediatamente a desenvolver um aplicativo móvel PowerApps POC. Ele utiliza listas e bibliotecas existentes do SharePoint como fonte de dados de back-end para meu aplicativo. PowerApps é o que chamo de plataforma de desenvolvimento baseada em configuração : permite o desenvolvimento muito rápido de aplicativos móveis.

Um usuário pode simplesmente selecionar a opção PowerApps no SharePoint para criar seu próprio aplicativo móvel PowerApps. Ele até cria automaticamente muitas das telas para adicionar e editar novos itens em uma lista ou biblioteca. Também foi testado com todos os líderes atuais no espaço de dispositivos móveis. Ele tem seu próprio IDE, juntamente com uma linguagem baseada em configuração muito simples que pode ser facilmente adaptada por um desenvolvedor técnico ou até mesmo por um usuário avançado com experiência em tecnologia.

Mais uma vez, tenho uma ótima ferramenta/recurso do SharePoint que posso usar para melhorar a adoção e o uso da plataforma SharePoint. Incorpore essa nova ferramenta ao SharePoint e ao Flow, juntamente com notificações push e a capacidade de usar recursos inerentemente móveis, como serviços de localização e chamadas telefônicas, e o PowerApps se tornou meu novo ponto de conversa favorito para discutir com meus clientes comerciais sobre a adoção e utilização de SharePoint.

Na verdade, meu POC não foi apenas recebido com entusiasmo pela minha empresa, mas por causa do meu uso de recursos móveis, como serviços de localização e navegação GPS, fui solicitado a apresentar meu aplicativo POC à engenharia do PowerApps como um exemplo do que poderia ser feito com o ferramenta.

Do VSLive às soluções do SharePoint

Enquanto eu estava sentado lá no meu assento na janela indo para San Francisco, eu nunca poderia imaginar como aquela simples viagem teria um impacto tão grande na minha carreira técnica. O SharePoint é uma ferramenta verdadeiramente inovadora e colaborativa, e a Microsoft continua a cumprir sua visão e direção com o SharePoint.

Como qualquer uma das milhares de soluções SaaS ou PaaS disponíveis para nós hoje, devemos garantir que realmente entendemos como melhor utilizar essas soluções. Continuando a melhorar nossos processos gerais de negócios e a satisfazer nossos clientes de negócios, o SharePoint tornou-se uma ferramenta essencial em meu arsenal. Estou ansioso pelo futuro e pelo que o SharePoint terá a oferecer para mim e minha empresa.