Изначально создававшиеся для организации коммуникаций внутри предприятий, современные коллаб-платформы в настоящее время способны не только обеспечивать сотрудникам доступ к электронной почте, календарю и другим инструментам для совместной работы, но также могут выполнять и ряд других задач. Например, на такие платформы часто возлагают задачу по управлению некоторыми ресурсами предприятия. Давайте же посмотрим на то, как функциональность управления ресурсами реализована в Zimbra Collaboration Suite.
Основными особенностями ресурсов, которыми способна управлять система для совместной работы является то, что они доступны сразу нескольким сотрудникам, но при одновременно этом могут использоваться кем-то одним. К ним, например, можно отнести комнаты для переговоров, служебные автомобили, аудио- и видеооборудование и ряд других вещей. В тех случаях, когда управление такими ресурсами пущено на самотек, возможно возникновение неприятных ситуаций, когда назначенная менеджером встреча с клиентом откладывается или даже срывается из-за того, что единственную свободную переговорку занял его коллега. Именно поэтому через коллаб-систему, как правило, реализуется бронирование ресурсов и оборудования, благодаря чему автоматически формируется график использовании ресурсов предприятия, позволяющий избежать подобных ситуаций.
Управление ресурсами в Zimbra Collaboration Suite реализовано через так называемые «Ресурсные учетные записи», которые представляют из себя почтовые ящики с собственным календарем, в который пользователи могут добавлять собственные события. Создать ресурсную учетную запись может администратор сервера в разделе «Управление пользователями» админки Zimbra. В процессе создания такого аккаунта он может указать:
- Вид ресурса: может быть вещью или помещением
- Политика бронирования
- Адрес для пересылки копий приглашений
- Описание ресурса
- Контактная информация (В качестве нее, как правило, указываются контакты ответственного лица)
- Информация о местонахождении (Например номер переговорки, адрес или корпус в котором она расположена, а также ее вместительность)
После создания ресурсного аккаунта, для него создается папка на сервере LDAP и пользователи могут отправлять ему приглашения на свои мероприятия. То, как ресурсный аккаунт будет реагировать на такие приглашения, зависит от политики бронирования. Администратор может выбирать из пяти видов политик:
- Auto decline all recurring appointments — Такая политика бронирования автоматически отклоняет все повторяющиеся встречи. Такую политику стоит включать в тех случаях, когда ресурс может быть запланирован только для одной встречи за раз.
- Auto accept if available, auto-decline on conflict — При такой политике ресурс автоматически принимает встречу, если он не был забронирован ранее и автоматически отклоняет при конфликте. При этом пользователи смогут просматривать расписание, а администратор сможет изменить правило автоматического отклонения, чтобы принимать некоторые встречи даже в тех случаях, если они конфликтуют.
- Manual accept, auto decline on conflict — При выборе такой политики, аккаунт будет автоматически отклонять все конфликтующие приглашения. Все приглашения, которые не конфликтуют, будут отмечены в календаре ресурса как предварительные и должны быть приняты вручную. При использовании такой политики настоятельно рекомендуется настроить почтовый адрес, на который будут приходить копии приглашения для их дальнейшего утверждения. Кроме того, имеется возможность настройки алгоритма отклонения конфликтующих приглашений.
- Auto accept always — Политика учетной записи ресурса настроена на автоматическое принятие всех приглашений. В данном случае информация о занятости не сохраняется и поэтому ресурс можно запланировать сразу под несколько встреч одновременно. Обычно такую политику используют для площадок, расположенных на прилегающих к зданиям территориях.
- No auto accept or decline — Использовать такую политику бронирования рекомендуется при полностью ручном управлении ресурсом. Ответственный пользователь должен осуществлять вход в ресурсный аккаунт чтобы принять или отклонить приглашения.
Помимо политики бронирования, администратору доступна тонкая настройка работы с конфликтующими приглашениями для тех ресурсных аккаунтов, политика которых поддерживает автоматические отклонение и принятие приглашений. Для таких аккаунтов можно задать допустимый объем автоматического принятия конфликтующих приглашений. Значение может быть задано как в абсолютных числах, так и в процентах от общего числа приглашений. В том случае, если вы укажете оба лимита, автоматическое принятие приглашений прекратится после первого достигнутого значения.
Также в настройках календаря ресурсного аккаунта можно найти пункт "Allow only the following internal users to invite me to meetings", позволяющий ограничить круг пользователей, которые имеют возможность бронировать и использовать ресурс, а также указать адрес электронной почты, на которую будут перенаправляться все поступающие на ресурсный аккаунт приглашения. Например какие-то переговорки можно закрепить за отделом продаж, разрешив бронировать их только продавцам, а какие-то только за отделом клиентского сервиса. Кроме того, имеется возможность передать управление календарем ресурсного аккаунта любому пользователю с менеджерскими правами.
Ресурсные аккаунты также можно создать и в интерфейсе командной строки. Для этого сперва нужно создать новый аккаунт на сервере zmprov ca resource@zimbra.local resource, а затем сконвертировать его в ресурсный при помощи команды zmprov ma resource@zimbra.local +objectClass zimbraCalendarResource displayName «resource» zimbraAccountCalendarUserType RESOURCE zimbraCalResType Equipment. Проверить успешность создания ресурсного аккаунта можно при помощи команды zmprov gacr, которая выводит на экран календари всех ресурсных аккаунтов.
Превратить ресурсный аккаунт обратно в обычный можно при помощи команды zmprov ma resource@zimbra.local -objectClass zimbraCalendarResource displayName «user account» zimbraAccountCalendarUserType USER -zimbraCalResType Equipment.
Автор: KaterinaZextras
