Сервисы Google в основе работы с корпоративным контентом в средней компании
До написания статьи я не встречал, чтобы Джи-сьют (G Suite, набор сервисов Гугла для бизнеса) рассматривался через призму решения ECM-задач... хотя если погуглить на английском, примеры есть. Между тем, я уверен, что можно и нужно...
До написания статьи я не встречал, чтобы Джи-сьют (G Suite, набор сервисов Гугла для бизнеса) рассматривался через призму решения ECM-задач... хотя если погуглить на английском, примеры есть. Между тем, я уверен, что можно и нужно смотреть на Джи-сьют как на ECM-решение.
Профиль бизнеса, который использует сервисы Гугла
Я погружен в несколько проектов, в которых взаимодействие завязано на гугловских сервисах, поэтому опишу профиль бизнеса, для которого Джи-сьют является ECM-решением.
Моя основная работа — Кивитакси — международная трэвел-компания из Ижевска, разрабатывающая и продвигающая систему бронирования туристических трансферов. У нас 57 сотрудников, около четверти которых — в отделе разработки. Основная система, автоматизирующая наш бизнес, — платформа собственной разработки, в которой работает бэк-офис. В качестве workflow-движка мы используем Джиру. Все сотрудники имеют корпоративную гугловскую почту и пользуются Гугл-диском и -документами. Переписываемся в Слэке.
Я знаю редпроцесс Тинькофф-журнала — проекта Тинькофф-банка. Над Т—Ж работает внутренняя команда, насчитывающая около пяти человек, и более 20 удаленных авторов. Все взаимодействие ведется через Трелло, Телеграмм и Гугл-документы. В основном Гугл-документы создают авторы, не имеющие корпоративной почты, раздавая права всем на комментирование по ссылке и расширенные тем, кому нужно, по имейлу.
Гугл-документы и корпоративную почту используют в IT-Agency. В агентстве работает команда около 100 человек: штатных и удаленных специалистов; около 20% сотрудников связаны с разработкой. Все имеют корпоративную почту, через логин которой раздаются права и доступы. Проекты ведутся в Эктив-коллабе, база знаний хранится в Конфлюэнсе, основное средство связи — Скайп.
Итого профиль. Средняя компания 50–150 человек или небольшая команда 15–30 человек. Молодые специалисты. Хорошее знание современных ИТ-продуктов, позволяющее быстро осваивать новые системы, используя хотя бы четверть их функциональности, кастомизируя под себя даже на уровне пользователя. Айтишники в команде. Готовность ко всему новому, вовлеченность в процесс: реально работают пресловутые «системы вовлечения» (systems of engagement), о которых в последний раз на моей памяти упоминалось в статье Максима Галимова про двуединство ECM. Основной актив бизнеса — интеллектуальный продукт. Интересно, что во всех проектах, с которыми я работаю, помимо сервисов Гугла есть решения от Атлассиан (Трелло было куплено в конце 2016-го).
Теперь подробней о том, как мы пользуемся гугловскими сервисами в Кивитакси.
Гугл-диск, -документы и права доступа
У каждого штатного специалиста Кивитакси есть рабочий аккаунт Джи-мейла и, соответственно, рабочий Гугл-диск. Все внутренние документы: таблицы, документы, формы и презентации — создаются в этих рабочих дисках. Структуру папок каждый настраивает под себя, соответственно, добавляя все нужные ему документы, созданные другими пользователями, на свой Гугл-диск. Нередко сотрудник, ответственный за тот или иной процесс или проект, создает папку, в которой собираются все нужные документы, и тогда причастным коллегам проще добавить к себе на диск всю папку и работать в ней. [Прим ред. Можно сказать “ссылку”, объект не дублируется.].
По умолчанию у всех в Гугл-дисках настроены права на просмотр всем пользователям в домене kiwitaxi.com. Если необходимо закрыть документы от общего доступа, владелец создает папку и ограничивает права доступа к ней, все Гугл-документы будут наследовать права папки, если отдельно не настроить иное.
Если документы нужны для взаимодействия с контрагентами, на них назначаются расширенные права с доступом по ссылке или с доступом для пользователя, не входящего в группу kiwitaxi.com.
Соответственно, поиск документов ведется в структуре личных папок или при помощи строки поиска по всем доступным пользователю Гугл-документам.
Гугл-календари, почта и контакты
Чтобы организовать очную коллективную работу мы планируем встречи в календаре. Каждый сотрудник ведет личный календарь так, как ему удобно: планирует или не планирует прочие дела, кроме собраний с коллегами. Есть несколько общих календарей, в частности для «часов открытых дверей» в отделах, которые мы устраиваем еженедельно, чтобы обмениваться новостями и задавать друг другу вопросы.
Основным рабочим инструментом для большинства является Гугл-почта. Здесь собираются нотификации из Гугл-документов и из Джиры.
Есть несколько групп контактов, объединенных под едиными адресами, чтобы можно было, например, быстро написать письмо всему отделу.
Device Policy (неудачное для BYOD-реалий гугловское MDM-решение)
Около половины сотрудников пользуются смартфонами в рабочих целях. Как минимум это касается почты, как максимум — выполнения задач в не слишком удобном для мобильного устройства веб-интерфейсе Джиры. На совещаниях документы и таблицы кто-то смотрит на рабочем ноутбуке, кто-то — на экране гаджета.
Такое положение вещей не очень радует нашего системного администратора. Поэтому мы пробовали работать с сервисом Джи-сьюта для управления корпоративными устройствами. Это MDM-решение, позволяющее администратору контролировать доступ сотрудников к корпоративному контенту и, в случае чего, удалять контент и обрезать доступ.
По своей сути, с точки зрения администратора, решение отличное. Но оно не слишком удачно реализовано в плане клиентского приложения. Если использовать сервис в компании, нужно обязать каждого сотрудника установить на устройство приложение Девайс-полиси. Пользователь должен будет создать отдельный рабочий профиль, в который установятся все выбранные администратором приложения. Даже если приложение уже есть на гаджете, оно продублируется. Рабочий профиль отдельно запускается и, естественно, съедает оперативную память. Тестирование на Асусе Зенфон 2 с четырьмя гигабайтами ОЗУ нас расстроило, так как смартфон начал думать в четыре раза дольше обычного, даже при простом обращении к Гугл-документам. После такого теста мы отказались от использования сервиса. Так что мобильный доступ у нас не защищен ничем, кроме ответственности сотрудников. По крайней мере до тех пор, пока мы придерживаемся концепции BYOD, а не CYOD и не выдаем сотрудникам гаджеты.
Признаки ECM в Джи-сьюте
Так почему же я настаиваю на том, что Джи-сьют — это вполне себе ECM-решение для средних и малых компаний?
Давайте посмотрим на последнее определение ECM от Гартнера: «Управление корпоративным контентом (ECM) включает в себя создание, хранение, распространение, поиск, архивное хранение и управления неструктурированным контентом (например, сканами, электронной почтой, отчетами, медицинскими изображениями и прочими документами); технология дает возможность организации анализировать использование информации, чтобы предоставлять пользователям релевантный контент где и когда это необходимо».
Сферы, которые закрывает ECM по Гартнеру (оранжевым выделено то, что позволяют делать гугловские сервисы)
Джи-сьют закрывает более половины названных задач. Сервисы Гугла идеальны для создания, хранения, распространения и, конечно, поиска корпоративного контента. Да, сейчас здесь нет архива и аналитики. Тем не менее, хорошо закрывается задача мобильного доступа. Есть даже функциональность для публикации и работы с веб-контентом. Но это другая история, которую я тоже хочу вам рассказать в обзоре новых Гугл-сайтов, вышедших в конце 2016 года.
Полезные ссылки
Маркетинговое описание сервисов Джи-сьюта
Справка по возможностям управления корпоративными мобильными устройствами
Комментарии 9
Максим, очень интересная статья! Ты заметил, что в перечисленных тобой компаниях немного другая парадигма управления, чем в госорганах или предельно вертикальных холдингах? И что для этой парадигмы нужен другой инструмент? Инструмент именно вовлечения, а не принуждения, как это реализовано в отечественных СЭД в виде механизма "задача-задание". Конечно, есть административные вопросы, типа обработка заявления на отпуск или заявки на технику, тут отечественная СЭД вполне подойдет, чтобы автоматизировать этот рутинный бизнес-процесс. А вот для основного, "продуктивного" взаимодействия в творческой среде, схема "задача-задание" подходит, на мой взгляд, чуть хуже, чем полностью :) Ибо не только не помогает вовлекать, а даже убивает горизонтальные связи формальностью подхода.
Сергей, а разве формальное и неформальное взаимодействие должны друг друга заменять?
Странно пенять на неподходящий инструмент (в данном случае СЭД), вместо того чтобы использовать иные пути коммуникаций.
Посмотри с другой стороны - когда тебе надо будет быстро понять кто задерживает согласование договора, вряд ли "виноватыми" будут слак или почта :)
По портрету потребителя - до 100 человек, это все-таки не средняя, а небольшая компания.
По комментариям выше - думаю, тут вопрос не столько вовлечения или принуждения, а вопрос доверия и управляемости, универсальности и заточенности - с одной стороны стоят подобные общие сервисы, а с другой классические СЭД. А где-то посредине новые облачные "легкие" ECM-системы.
Ну, у меня был в жизни опыт, когда для продуктивного общения в компании (т.е. для горизонтального общения сотрудников) использовалась СЭД. Сейчас я начинаю понимать, что формализация этого общения путем отправки задания в СЭД имеет свои недостатки. Может, контроль исполнения просьбы будет проще, но для более здоровых взаимоотношений, ИМХО, бывает лучше использовать менее формально-обязательные инструменты, как то почта, чат, звонок. К тому же, в известной мне СЭД нельзя было просто поставить задачу, не назначая исполнителей. Такое бывает нужно, когда сотрудники, в пределах своей компетенции, сами захотят выбрать себе задачу. Тот же YouTrack позволяет организовать такого рода бизнес-процессы. К тому же, становится проще привлекать новых коллег к решению задачи. Я уже не говорю про информативность - текущие задачки можно окинуть "одним взглядом" на Agile Board. Agile Boards можно применить не только для разработки ПО, но и для других, в том числе более крупных задач.
Подытоживая вышесказанное, скажу, что, на мой взгляд, классическая СЭД в компании с самоорганизующимися командами и духом взаимопомощи своим формальным подходом скорее убьет инициативу и энергию сотрудников, чем наведет порядок.
И в этом случае можно использовать любой инструмент, который устроит организатора бизнес-процесса. И СЭД, и Agile Board позволят увидеть, кто задерживает процесс. Согласование по почте или в безадресном инструменте, думаю, не очень эффективное решение :)
Сергей, я заметил. Я бы даже сказал не «немного другая», а «принципиально другая».
Про инструмент все не так однозначно. Понятно, что мне ни в одном моем проекте не нужна СЭД. Но это не значит, что такие системы вообще не нужны или вредят и убивают инициативу. Инструмент в принципе вторичен, а первично отношение людей (в том числе топов и мидлов) к работе.
Василий, я еще с одной стороны предложу посмотреть на пример с договором, который задерживается на согласовании... Мне кажется, что если договор (документ, который обязует компанию что-то сделать) застревает, это свидетельствует о том, что для компании большой нужды в этом договоре нет, иначе бы ответственный сотрудник любыми инструментами добился результата. Или же потребность скорее подписать договор не понимают участники процесса, но тогда это вообще беда процесса, т.е. совсем другая история.
Максим, можно несколько технических вопросов:
Михаил, привет!
Не уверен, что я могу на твоем уровне ориентироваться в этих технических деталях, но попробую ответить.
— Про метаданные и атрибутивный поиск. Мы с ними никак не работаем. Я лично про возможности работать с ними не слышал. Часть вещей может решаться просто стандартизацией названий документов. В IT-Agency так и делаем — унифицируем названия, чтобы легко можно было найти все доки по проекту. А вообще, думаю, можно что-то сделать. Для начала можно почитать про возможности эйпиай драйва. Вот, например, ссылка https://developers.google.com/drive/v3/web/search-parameters
— Про шаблоны. Простые, конечно, делать можно. У нас в Кивитакси, например, есть шаблоны маркетинговых материалов. Если речь об умных шаблонах, которые опять же на уровне метаданных что-то сразу подхватывают в тело документа — не знаю. Думаю, если и есть возможности, то реализовать их является не тривиальной задачей.
— Про совместимость с настольными офисными системами. Без скачивания ничего не выйдет (по крайней мере, я не встречал официальных браузерных расширений, которые бы решали проблему). Но это не проблема Гугла, а скорее проблема Майкрософт, как мне кажется.
Наверное, не очень помог, но я только и могу, что рассказывать, как делаю сам. Пока у меня нет потребности что-то усложнять и я на проектах использую минимальные возможности сервисов.
Да нет, всё вполне прозрачно.
Спасибо!
А вот и «Яндекс» запустил платформу «Яндекс.Коннект», обеспечивающую совместный доступ к различным облачным сервисам для совместной работы. В состав платформы «Коннект» вошли приложения «Почта» для домена, «Диск», мессенджер «Ямб», общая база документов «Вики», а также адресная книга с возможностью отражения структуры организации.
Подробнее: http://www.cnews.ru/news/top/2017-04-25_yandeks_zapustil_konnekt_dlya_sovmestnoj_raboty