Изучение бизнес-преимуществ SharePoint
Опубликовано: 2022-03-11Задумывался ли кто-нибудь в вашей компании, получают ли они максимальную отдачу от SharePoint? На первый взгляд, это кажется нелепым вопросом. Зачем компании внедрять SharePoint, если они еще не определили его истинные преимущества и общую ценность?
Но в своих повседневных беседах с другими техническими и деловыми людьми я поражаюсь тому, как часто они не могут определить и количественно оценить реальную рентабельность инвестиций, которую они видят в SharePoint. Еще более поразительно, как много компаний не полностью использовали свою среду SharePoint для снижения общих затрат на бизнес и повышения производительности.
Технические особенности SharePoint важны, но в этой статье я хочу рассказать вам больше о том, чего обычно не хватает в бизнес-стратегии компаний, использующих SharePoint.
Зачем использовать SharePoint: видение…
Зимой 2009 года, в воскресенье, я сидел на своем сиденье у окна и с нетерпением выглядывал из 747-го. Я направлялся в Сан-Франциско на свою первую конференцию VSLive.
В то время я работал в крупной косметической компании. Я был рад посетить занятия по SharePoint, на которые я зарегистрировался: это был относительно новый стек технологий в компании, и я хотел лично убедиться, что SharePoint действительно может сделать для компании.
Я не был разочарован. Я уехал из Сан-Франциско с таким волнением, с чувством, которое, как мне казалось, давно ушло из моей профессиональной карьеры. Мне так не терпелось вернуться в офис, чтобы обсудить этот удивительный инструмент с моей командой… только чтобы вернуться к реальности моего существования в качестве директора в команде глобальных информационных систем:
[Исполнительный директор – ГИС] : «Конечно, я слышал о SharePoint. Я не понимаю, из-за чего весь этот шум... Мы могли бы сделать те же веб-страницы в нашей собственной веб-ферме. Я думаю, ты зря теряешь время».
[Менеджер по деловым отношениям – ГИС] : «Это слишком просто и безобразно. Я никогда не смогу продать это ни одному из моих бизнес-клиентов».
[Старший разработчик — ГИС] : «Что такого особенного? Я не вижу в этом никакой ценности. Это выглядит слишком сложным для работы. Я думаю, что Active Server Pages — гораздо лучшее направление».
Единственным человеком, который проявил хотя бы небольшой интерес, был директор, которому я подчинялся напрямую. Он мало что знал о технологиях в SharePoint, но он знал, что я был слишком взволнован этим, чтобы просто игнорировать это.
Он попросил меня устроить короткую встречу для дальнейшего обсуждения этой технологии. Эта встреча привела к тому, что мы разработали пробную версию SharePoint (POC) для нашего высшего руководства, которая в конечном итоге стала основным компонентом в отделе ГИС. Это позволит автоматизировать и оптимизировать наши новые процессы жизненного цикла разработки программного обеспечения (SDLC) и проложить путь к тому, чтобы компания использовала многие преимущества SharePoint, подняв меня на выдающийся уровень «Парня с SharePoint». В течение следующих восьми лет я проводил большую часть своего времени в компании, используя SharePoint как удивительно недорогой инструмент повышения производительности. Для тех, кто будет слушать, я бы улучшил многие бизнес-процессы и сократил их затраты, но внутри компании все еще было слишком много сайтов, которые были простыми командными сайтами с библиотеками документов. Я был всего лишь одним человеком, плывущим вверх по течению, чтобы продать SharePoint не только своему бизнесу, но и самым высшим уровням в организации.
Это звучит знакомо?
За последние девять лет я заметил, что использование SharePoint в большинстве компаний происходит по одному из двух основных сценариев.
1. Сайты групп с библиотеками документов
Эти сайты обычно создаются на основе шаблона Team и содержат одну или несколько библиотек документов, которые могут иметь очень сложную структуру папок. Очень мало используются типы контента, теги метаданных или рабочие процессы. Сайты полностью поддерживаются бизнес-подразделением, члены которого не имеют формального представления о SharePoint и не взяли на себя роль «Опытного пользователя». Сайт был создан инфраструктурой или группой поддержки, которые могут быстро создать сайт из простого запроса в службу поддержки.
2. Полностью настраиваемые сайты с большой и сложной кодовой базой
Обычно это гораздо более крупные сайты с гораздо большей аудиторией: корпоративные интрасети, корпоративные отделы кадров и корпоративные ИТ-сайты являются обычными кандидатами для такого типа использования SharePoint.
Эти проекты обычно начинаются с большого направления и ожиданий. Они продаются как недорогая альтернатива многим высококлассным и дорогим системам управления контентом (CMS), которые бизнес уже исследовал. Затем по мере продвижения проекта требования трансформируются и усложняются. Требуется больше пользовательского кода, который в конечном итоге становится настолько сложным, что поддержка кода становится проблемой.
Отсюда обычно все выходит из-под контроля. Команда разработчиков отказалась от предпосылки использования готовых функций (OOTB) с ограниченной кодовой базой. Вместо этого у них есть полностью настраиваемый подход, начиная от полностью настраиваемых главных страниц и заканчивая, возможно, приложением, размещенным у поставщика (PHA), или, как они теперь его называют, надстройкой, размещенной у поставщика.
Я уже слышу вздохи и вижу, как закатываются глаза. «Тони, это совершенно правильные подходы к использованию». «У нас есть и то, и другое, и нашим пользователям нравятся эти сайты, и у нас нет проблем с их поддержкой». Я никоим образом не утверждаю, что какой-либо из этих методов неправильный или что один из них лучше другого, но я действительно считаю, что оба подхода просто упускают возможность в полной мере использовать то, что может предложить платформа SharePoint.
Я также считаю, что эти две модели приводят к тому, что бизнес считает, что SharePoint слишком дорог для того, для чего они его используют, или что ИТ-отдел считает, что они могли бы просто разработать ту же функциональность с помощью веб-серверов и HTML-страниц или готовой CMS. облачное решение. Любое из этих мнений оставляет как у бизнеса, так и у ИТ-отдела ощущение, что SharePoint не является подходящим инструментом для их нужд.
Преимущества SharePoint Gone AWOL?
Чтобы нам лучше понять, где мы находимся, нам нужно сделать шаг назад и проанализировать, как мы сюда попали.
Я собираюсь вернуть вас к простому вопросу «Как вы узнали о SharePoint?» Исходя из моего личного опыта и опыта многих других ИТ-лидеров, с которыми я разговаривал, SharePoint как техническая платформа была представлена компании командой по инфраструктуре при содействии их консультантов Microsoft Enterprise.
Обычно первая ферма SharePoint представляет собой своего рода испытательный стенд, предоставляемый компании в рамках соглашения Enterprise Agreement с Microsoft. На этом этапе большинство компаний подключают бизнес-клиента и развертывают свое первое семейство сайтов с помощью одного сайта группы. Бизнес-клиенту нравятся библиотеки документов и возможность совместной работы и обмена документами, поэтому он начинает использовать сайт как часть своих бизнес-процессов.
Это может показаться вполне приемлемым для многих из вас и, честно говоря, может быть жизнеспособным вариантом использования SharePoint. Но как только вы углубитесь в SharePoint, вы поймете, что это гораздо больше, чем просто платформа, которую внедрила и поддерживает команда инфраструктуры: это надежное пространство приложений, которое требует тесного сотрудничества команд инфраструктуры, корпоративной архитектуры и приложений.
Я не являюсь «антиинфраструктурным» человеком или кем-то, кто политически настроен против команды инфраструктуры, но без сотрудничества с правильными партнерами с самого начала вы рискуете не понять всего объема платформы SharePoint и, следовательно, не готовы к соответствующим бизнес-стратегиям и плану использования. Эта ситуация не уникальна для платформы SharePoint и указывает на гораздо более серьезную проблему правильного сотрудничества и стратегии, с которой сталкиваются многие ИТ-отделы.
Ваш бизнес-клиент — ключ к успеху
Слишком часто многие технические организации не имеют абсолютно никакой бизнес-стратегии, когда речь идет о SharePoint. У них просто есть небольшой процесс, добавленный к их существующим, о том, как запросить и создать сайт SharePoint. Они могут даже не включать какое-либо управление процессом создания сайта, что может привести к очень большому объему семейств сайтов и, в конечном итоге, к проблеме с поддержкой.
Может быть некоторое базовое обсуждение и обучение использованию некоторых более крупных концепций, таких как семейства веб-сайтов и поиск в SharePoint . Но обсуждение стратегии может стать очень сложным. Из-за этого многие технические организации просто решают завершить свою стратегию на этапе создания сайта. Вместо этого давайте начнем медленно и с основных ключевых функций SharePoint.
Кто ваши бизнес-клиенты? Это корпоративная техническая команда, ваша региональная маркетинговая команда или, может быть, команда R&D? Как я уже говорил ранее, внедрение SharePoint обычно начинается командой инфраструктуры, а затем постепенно распространяется на бизнес-клиентов.
В некоторых случаях ваши бизнес-клиенты уже слышали о SharePoint в более простом контексте, когда они рассматривают какое-то крупномасштабное ключевое бизнес-приложение, с которого обычно начинается второе использование SharePoint. Без четкой бизнес-стратегии внедрения для технической группы будет очень медленным и трудным путь к обеспечению того, чтобы их ферма SharePoint получила правильное внедрение и использование.
В моем случае большинство сайтов SharePoint, которые уже были созданы, когда я познакомился с SharePoint, были просто сайтами для совместной работы с большими библиотеками документов с очень сложной и запутанной структурой папок.
Некоторые имена папок на самом деле были небольшими предложениями, чтобы команда могла точно понять, какие типы документов находятся в папке. Не было ни тегов метаданных, ни типов контента, просто документы, лежащие в папках.
Весь процесс сотрудничества заключался в обмене фактическими документами. Был единый репозиторий, где каждый мог обмениваться документами, и это было пределом совместной работы команды. Именно в этом бизнес-клиент увидел самую большую ценность SharePoint.
Неудивительно, что, когда я начал разговаривать с представителями компании, их впечатление от SharePoint было в лучшем случае без энтузиазма. Даже некоторые из моих технических коллег начали утверждать, что мы могли бы значительно сэкономить, если бы просто купили общие папки для обработки файлов и структур папок.
Многие из основных функций SharePoint просто не были должным образом доведены до моего бизнеса и, в некоторой степени, даже до технической группы. Они продавались на SharePoint как потрясающий инструмент CMS с большими возможностями для укрепления совместной работы и инноваций, но лучшее, что мы смогли придумать, — это общий доступ к файлам.
Во время одного из моих первых интервью в моем бизнесе я узнал, что причина некоторых длинных структур папок заключалась в том, чтобы предоставить людям определенный уровень структуры для поиска определенных файлов. Компания даже не знала об основных возможностях поиска SharePoint , не говоря уже о том, чтобы следовать рекомендациям SharePoint. Мне нужно было найти способ привлечь своих бизнес-клиентов, чтобы они могли не только более эффективно использовать SharePoint, но и рассказать им о некоторых реальных преимуществах платформы.

Презентация лучшего бизнес-кейса
Основываясь на отзывах из приведенных выше интервью с бизнес-клиентами, я понял, что мне нужно начинать все сначала с образования. Но, исходя из того, что у нас уже была большая ферма, как я мог «начать сначала», когда дела уже двигались вперед?
Большинство сайтов были сайтами совместной работы с библиотеками документов. Поэтому я решил начать с библиотек документов. У меня был один из моих бизнес-клиентов, который согласился работать со мной и моей командой над реструктуризацией их библиотек таким образом, чтобы они могли свести к минимуму структуры папок, повысив при этом видимость поиска нужного файла, который искал пользователь.
Когда мы углубились в структуру некоторых сайтов, мне стало очевидно, что структура папок на самом деле была элементами данных и группами различных типов файлов, над которыми работала команда. Поэтому я решил начать с очень простой, но мощной функции SharePoint: тегов метаданных.
Я всегда считал, что одним из самых эффективных способов обучения любого клиента технологии является простая разработка своего рода POC. Проблема с POC заключается в том, что они влияют на стоимость. Вы должны быть осторожны, чтобы полностью не разработать приложение только для того, чтобы бизнес решил, что это не то, что им нужно.
В моем случае стоимость была минимальной, но потенциально ценность была огромной. Я решил взять несколько библиотек документов, в каждой из которых было 20 или более отдельных папок, и воссоздать их как одну библиотеку документов с метаданными и типами контента. Вместо того, чтобы пытаться объяснить типы контента, было проще продемонстрировать, как использование типа контента может не только добавить к структуре данных, но и позволить им правильно управлять дополнительными метаданными, связанными с файлом.
Эффект снежного кома
Многие из файлов содержали важную, очень полезную информацию. Компания решила сгруппировать файлы, используя очень сложную структуру папок. Например, у них была папка для каждого из 15 брендов, а в этих папках были подпапки для маркетинга, финансов и других ключевых категорий; внутри этих подпапок у них было еще больше подпапок.
Это позволило им легче находить конкретный файл или файлы, а не открывать и просматривать отдельные файлы. Но из-за такой сложной структуры папок им теперь требовался бизнес-процесс, гарантирующий, что каждый файл будет помещен в нужную папку. Как выяснилось, новым бизнес-процессом было слишком сложно управлять, и многие файлы оказывались не в том месте.
Это позволило мне внедрить и объяснить бизнесу использование метаданных. Я разбил файловую структуру на несколько ключевых типов контента, которые мы затем использовали для включения ключевых элементов данных, а также для проверки важных данных. Именно этот простой подход к типам контента, метаданным и проверке данных стал первым крупным успехом в моем путешествии по представлению моей компании лучшего экономического обоснования для SharePoint.
Теперь, когда я привлек внимание бизнеса, я решил провести простой обзор библиотеки документов с ключевыми заинтересованными сторонами. Я продемонстрировал им истинную ценность метаданных и типов контента, фильтруя и сортируя их данные.
К моему изумлению, они были просто в восторге от некоторых основных функций SharePoint, о существовании которых они даже не подозревали. Затем я решил включить пользовательскую страницу фильтра, чтобы действительно показать им, что можно сделать с помощью простого создания страницы, веб-частей и фильтрации.
Я был очень осторожен, чтобы полностью не настроить ни одну из этих страниц. Я хотел использовать только веб-части OOTB. Таким образом, они будут лучше понимать основные функции SharePoint, прежде чем я перейду к более сложным сценариям. Пользовательская страница имела огромный успех, и мы даже не обсуждали расширенные возможности, которые поисковая система предоставит для них. Я хотел воздержаться от поисковой системы до тех пор, пока лучше не освою основы SharePoint.
Рабочие процессы SharePoint: ключ
По моему скромному мнению, рабочие процессы SharePoint были самым важным фактором в моей способности обучать своих бизнес-клиентов и обеспечивать внедрение и использование SharePoint в моей организации. Рабочие процессы были первой функцией, которая привлекла мое внимание на том первом VSLive, о котором я упоминал, и они внесли основной вклад в мой первый полный SharePoint POC, который включал наши процессы SDLC.
Когда дело доходит до SharePoint, мои первые разговоры с бизнес-клиентами обычно касаются их бизнес-процессов. Бизнес-процессы являются ключом к использованию SharePoint для повышения производительности и снижения затрат, и любой бизнес-клиент хочет обсудить это.
Как я уже говорил многим старшим ИТ-руководителям, я могу практически гарантировать использование и принятие SharePoint просто посредством бизнес-процессов. У каждого бизнес-подразделения есть процессы, и у большинства этих процессов есть контрольные точки или точки утверждения, и именно здесь рабочие процессы пригодятся, будь то отправка электронного письма об утверждении или создание задачи утверждения.
После того как я убедил бизнес-клиента в том, как рабочие процессы могут улучшить их процессы и снизить затраты, я затем обучаю их тому, как они могут использовать те же самые задачи утверждения для последующего создания соглашений об уровне обслуживания (SLA) или ключевых показателей эффективности (KPI).
Насколько здорово было бы, если бы бизнес-подразделение понимало, сколько времени требуется для рассмотрения и утверждения документа? Затем они могли бы взять эту информацию и принять стратегию для улучшения всего процесса. Это позволит им создавать ключевые показатели эффективности для мониторинга и управления процессом.
Чтобы показать приверженность высшего руководства улучшению своих процессов, они могли бы даже включить усовершенствования в свои программы премирования. Обычно это пробная версия, которая убеждает бизнес-клиента в истинной ценности, которую он может получить благодаря внедрению и использованию SharePoint.
Будущее
Когда я впервые услышал об Office 365 и SharePoint Online, я понял ценность размещенной среды SharePoint, но снова столкнулся с проблемой, как убедить своих бизнес-клиентов в том, что это новое направление лучше всего подходит для их будущего. Я был рад услышать о PHA, но также был осторожен в отношении потенциальных затрат, которые это могло иметь с точки зрения поддержки приложений.
Моя компания пошла по пути сторонних поставщиков разработки с моделью аутсорсинга, что может легко привести к тому, что поставщики будут создавать сложные бизнес-приложения с большими остаточными затратами на обслуживание и усовершенствования.
Как и в случае с каждой размещенной моделью, нам нужно подготовиться к изменениям. Как люди, мы очень не любим перемен, и как команды технической поддержки мы часто боимся изменений и того, как они повлияют на способность нашей команды двигаться вперед.
Когда я впервые услышал о решении Microsoft отказаться от поддержки InfoPath, а затем о внедрении Flow в качестве механизма рабочего процесса, моей реакцией было: «Ну вот опять!» Microsoft собиралась принять еще одно бизнес-решение, которое затруднило бы мне «продажу» их новейшего направления SharePoint. Когда я начал просматривать то, что мог предложить Flow, я был разочарован тем, что увидел.
Но у Microsoft было свое видение будущего, и я просто не понимал его — пока не начал видеть некоторые возможности Flow в отношении точек интеграции. Flow интегрируется со многими из существующих на сегодняшний день приложений, но также позволяет компании создавать свои собственные точки интеграции. Это сделало его важным участником моих деловых дискуссий об улучшении бизнес-процессов за счет интеграции с различными бизнес-приложениями.
Мобильность
Это стало стандартной темой для разговоров, которые я, как технический руководитель, веду со многими своими бизнес-клиентами. Можно обсуждать адаптивный веб-дизайн и то, как максимально увеличить его присутствие в мобильной сети. Мы также можем обсудить, как SharePoint использует адаптивные веб-страницы для улучшения работы SharePoint на мобильных устройствах. Microsoft даже разработала мобильное приложение SharePoint. Но обычно обсуждение идет в сторону создания отдельного мобильного приложения.
Как только я слышу слова «автономное мобильное приложение», я слышу стук кассового аппарата: многие мобильные приложения требуют больших затрат и имеют специализированную модель поддержки. Мой ответ из мира SharePoint — PowerApps.
Как и раньше, я немедленно приступаю к разработке мобильного приложения PowerApps POC. Он использует существующие списки и библиотеки SharePoint в качестве внутреннего источника данных для моего приложения. PowerApps — это то, что я называю платформой разработки на основе конфигурации : она позволяет очень быстро разрабатывать мобильные приложения.
Пользователь может просто выбрать параметр PowerApps в SharePoint, чтобы создать собственное мобильное приложение PowerApps. Он даже автоматически создает множество экранов для добавления и редактирования новых элементов в список или библиотеку. Он также был протестирован со всеми текущими лидерами в области мобильных устройств. У него есть собственная IDE, а также очень простой язык настройки, который может быть легко адаптирован техническим разработчиком или даже технически подкованным пользователем.
И снова у меня есть отличный инструмент/функция SharePoint, который я могу использовать для улучшения принятия и использования платформы SharePoint. Интеграция этого нового инструмента с SharePoint и Flow, наряду с push-уведомлениями и возможностью использования встроенных мобильных функций, таких как службы определения местоположения и телефонные звонки, и PowerApps стали моей новой любимой темой для обсуждения с моими бизнес-клиентами внедрения и использования SharePoint.
На самом деле мой POC был не только с готовностью принят моим бизнесом, но и из-за того, что я использовал мобильные функции, такие как службы определения местоположения и GPS-навигация, меня попросили представить мое приложение POC инженерам PowerApps в качестве примера того, что можно сделать с помощью инструмент.
От VSLive к решениям SharePoint
Сидя у окна и направляясь в Сан-Франциско, я и подумать не мог, что это простое путешествие так сильно повлияет на мою техническую карьеру. SharePoint — это действительно инновационный инструмент для совместной работы, и Microsoft продолжает реализовывать свое видение и направление с SharePoint.
Как и любое из тысяч решений SaaS или PaaS, доступных нам сегодня, мы должны убедиться, что мы действительно понимаем, как лучше всего использовать эти решения. Продолжая улучшать наши общие бизнес-процессы и удовлетворять потребности наших бизнес-клиентов, SharePoint стал ключевым инструментом в моем арсенале. Я с нетерпением жду будущего и того, что SharePoint может предложить мне и моему бизнесу.