34 цифровых сервиса библиотеки вуза

Год назад я на данных показал, что цифровая трансформация библиотек является блефом и подавляющее большинство библиотек – «ходячие мертвецы», они делают вид, что живы, хотя в действительности уже мертвы. Но рассуждения про цифровую трансформацию в прошлогодней статье не содержали указаний что стоило бы библиотеке делать, чтобы пройти цифровую трансформацию. Пора исправить это упущение на примере библиотеки вуза.

Для начала я дам свое определение цифровой трансформации библиотеки.

Цифровая трансформация библиотеки – комплексное изменение бизнес-процессов для повышения конкурентоспособности библиотеки путем замены печатного фонда на цифровые сервисы, продукты и ресурсы.

Продукт — решение потребности пользователя, несущее в себе ценность для последнего.

Как ранее и предложено, я буду называть цифротрансформированные библиотеки инфотеками.

Из определения прямо следует, что цифровая трансформация библиотеки обесценивает печатный фонд, а значит будет сопровождаться значительным сокращением штата. Если у библиотеки штат в результате цифровой трансформации не сокращен хотя бы в 2 раза или большинство оставшихся сотрудников занимается тем же чем раньше, значит бизнес-процессы не изменились и цифровая трансформация не произошла.

Перечислю цифровые продукты, которые стоило бы внедрить библиотекам уже к сегодняшнему дню, чтобы не выглядеть отсталыми. Ну а читатель может загибать пальцы, сколько внедрено в его библиотеке и является именно продуктом, т.е. несет ценность (решает какую-то «боль» и потому востребовано) именно пользователю, а не библиотекарю. Сразу договоримся, что некоторые перечисленные продукты могут быть реализованы в рамках одной программы, но большинство будет отдельным ПО. Список продуктов открытый, то есть у организаций чего-то может не быть или быть дополнительное. По возможности продукты будут сопровождены примерами ПО, на которых они могут быть реализованы, при этом задачи сделать полный обзор ПО для реализации продуктов не ставится и не следует считать приведенные примеры как рекомендации. Вузу надо самостоятельно провести исследование и выбрать ПО, наиболее подходящее именно ему.

Содержание

1 Цифровые сервисы (продукты) библиотеки вуза
2 Цифровая культура
- 2.1 Цифровая зрелость
3 Роль библиотеки
4 Выводы

Цифровые сервисы (продукты) библиотеки вуза[править]

1 АБИС[править]

1.1 Электронный каталог[править]

1.2 Электронная выдача и сдача[править]

1.3 Бронирование и продление ресурсов[править]

Системы автоматизации библиотек существуют давно и в большом разнообразии, их задача – автоматизировать деятельность библиотеки. Особо на АБИС останавливаться не буду, отмечу только, что ПО АБИС морально устарело, делает упор на теряющий актуальность печатный фонд и самое главное: неудобно пользователям.

Примеры ПО: ИРБИС64, Руслан-НЕО, Koha.

Типичная ошибка: попытка решать все проблемы библиотеки с помощью АБИС. АБИС, как универсальное ПО, плохо справляется с узкими задачами, а даже если технически и справляется, проблемы с интерфейсом и пользовательским опытом (UI/UX) АБИС распространяются и на дополнительный функционал. Так я не советую создавать электронные библиотеки в АБИС (плохой UI/UX и плохое индексирование поисковиками) и единый поиск (проблемы с добавлением, слиянием, удалением большого количества записей на внешние ресурсы, часто нет фасетного поиска).

2. Подсчет книгообеспеченности[править]

Многие пытаются книгообеспеченность затащить в АБИС, но так делать не обязательно, так как книгообеспеченность опирается на образовательные программы и академические группы, а все это находится в системе управления вузом, разумно именно там книгообеспеченность и считать. Тогда уже система автоматизации вуза должна ходить в АБИС и выгружать из нее данные об количестве экземпляров и строить у себя отчеты книгообеспеченности.

3. Цифровая (электронная) библиотека[править]

В образовательном процессе преподаватели генерируют большое количество ресурсов, которые надо в каком-то упорядоченном виде хранить и распространять с ограничением доступа. Цифровая библиотека должна поддерживать создание преподавателями собственных цифровых библиотек (хостинг электронных библиотек преподавателей) и иметь централизованный каталог (или каталоги для подразделений и факультетов), а также решать некоторые специальные задачи (размещение ВКР и т.д.).

Типичная ошибка: библиотека считает, что в её электронной библиотеке должны находиться только «качественные издания» и зачастую туда попадают по 100-300 изданий вузовского издательства в год и все. Где должны хранить преподаватели свои документы, презентации и другие учебные ресурсы – библиотеку не интересует. Позиция библиотеки, что для пользовательских ресурсов пусть создает библиотеку кто-то другой. Но тогда цифровая библиотека будет одна «качественная» от библиотеки, и одна действительно полезная преподавателям и студентам не от библиотеки. Ну а так как UI/UX цифровых библиотек, созданных на базе АБИС, оставляют желать лучшего, процедура добавления ресурсов затянута и забюрократизирована, преподаватели отправляют студентам ресурсы, включая собственные учебники, минуя библиотечный сервис цифровой библиотеки. Таким образом цифровые библиотеки «от библиотеки» оказываются не нужны образовательному процессу, а библиотека неспособна качественно решить даже свою «родовую» задачу.

Примеры ПО: ELiS, модули к АБИС, ИнфоРост, Комплекс «Электронная библиотека» от Открытых библиотечных систем, Xerox ПЭБ, а из открытого ПО Rescarta и DSpace, хотя DSpace на самом деле не электронная библиотека. Есть обзор ПО для создания электронных библиотек.

Примеры: ELiS, Комплекс «Электронная библиотека».

Ключевое отличие цифровой библиотеки от архива и репозитория, что библиотека прежде всего «выдавалище», а не «хранилище» и значит библиотека должна быть нацелена на удобное потребление ресурсов.

Примеры цифровых библиотек

4. Архив[править]

В качестве сервиса я уже называл цифровую библиотеку, но может быть внедрен и архив. Архив отличается от библиотеки тем, что в нем ресурсы, которые утратили актуальность и выведены на хранение на случай, если когда-нибудь потом понадобятся.

ПО для архивов есть как специализированное, позволяющее размещать произвольные файлы, так иногда используются и функционал систем электронного документооборота.

5. Институциональное хранилище[править]

Также называют институциональным репозитарием (repository – хранилище). В отличие от архива, ресурсы в хранилище могут быть и не устаревшими, но слишком малоспрашиваемыми для размещения их в цифровой библиотеке, например это могут быть сырые или обработанные научные данные к исследованиям, копии опубликованных статей. В России и в мире популярен DSpace.

Примеры ПО: DSpace, Eprints, Invenio.

Примеры: https://elar.urfu.ru, https://earchive.tpu.ru, https://dspace.susu.ru.

Типичная ошибка: использование хранилища в качестве замены цифровой библиотеки.

DSpace в УрФУ.

6. Управление цифровыми активами[править]

На английском записывается как digital assets management (DAM), но фактически сфера применения довольно узкая и возникает из следующих предпосылок: часто в работе сайтов контент-менеджерам и редакторам необходимо размещать изображения, видео, документы и если таких ресурсов много и они переиспользуются (один ресурс встраивается на разных страницах и сайтах), нужно что-то вроде электронной библиотеки, но без публичного каталога, публичного поиска, зато с механизмами встраивания в другие сайты и правами на совместное управление ресурсами, включая совместное описание. Архивация или блокировка в DAM-системе заблокирует ресурс сразу везде, где он был встроен. DAM часто используется менеджерами крупных сайтов, а сайты вузов – это крупные сайты.

Пример интерфейса DAM-системы

Есть много программ с открытым исходным кодом и коммерческих для задач DAM. Можно использовать и ELiS (есть плееры).

Стоит сделать небольшое отступление. Увидеть разницу между цифровой библиотекой, архивом, институциональным хранилищем и системой управления цифровыми активами не просто: всё это требует описания, навигации, полнотекстового поиска, ограничения доступа. Однако требования к ПО различаются: раз библиотека имеет смысл только если она выдает ресурсы, то к ней высокие требования к хорошему интерфейсу и пользовательскому опыту при использовании. Для архивов и хранилищ требования ниже, так как предполагается, что они нужны редко и небольшому количеству пользователей, которые пробьются сквозь проблемы интерфейса. Тем не менее, никто не мешает делать архив и институциональное хранилище на ПО цифровой библиотеки, просто добавив соответствующие атрибуты в метаданные. Обратное не верно: делать цифровую библиотеку на базе ПО для хранилищ и архивов технически возможно, но не следует, так как интерфейс и пользовательский опыт будут слишком плохими. В АБИС делать архив и хранилище затруднительно, так как система метаданных на базе MARC для этого не предназначена. Касательно ПО для DAM – пользователь не видит их интерфейс, так как пользуется только встроенными ресурсами, но обычно такие системы относительно просты, вместе с тем для редакторов поиск должен быть достаточно удобен, так как они им часто пользуются.

Кстати, есть еще одна интерпретация систем управления цифровыми активами, идущая от производителей корпоративного ПО. Суть в том, что часто ресурсы имеют определенный жизненный цикл, вначале они создаются, затем распространяются, а после устаревают и сдаются в архив. Но электронная библиотека и архив - часто разные программы и тогда такие ресурсы вместе с навигацией и метаданными надо переносить из одной системы в другую. Это не удобно и кажется логичным объединить электронную библиотеку с архивом в одной системе, чтобы прямо в электронной библиотеке можно было проставить срок хранения и добавить атрибут передачи в архив. Такие системы IBM и другие производители и называют системами управления цифровыми активами. По-сути добавка функционала небольшая, но звучит в разы дороже ;)

Жизненный цикл ресурсов в системе управления цифровыми активами.

В конечном счете перечисленные системы по своей сути амбары с надстройками, а разница в том, насколько актуальные ресурсы в них хранятся, кем и как они используются, что определяет различия в функционале и требованиях к интерфейсу.

7. Аренда внешних ЭБС[править]

Хотя арендуемые ЭБС являются внешними сервисами, для них надо обеспечить бесшовный переход и доступ, управление лицензиями, подтягивание метаданных, учет в книгообеспеченности, поиск и т.д.

8. Поиск[править]

Проблему поиска библиотеки понимают достаточно узко, считая необходимым реализовать поиск только по библиотечным ресурсам. На самом деле у вузов много внутренних сайтов с ресурсами, в том числе в интранете, закрытых от внешних систем индексирования, и нужен полнотекстовый поиск по всем корпоративным сайтам и базам данных.

8.1. Библиотечный поиск[править]

Собрать в одном месте данные с разных библиотечных ресурсов можно с помощью VuFind. Но придется немного пописать кода. Применяется в КФУ и ПНИПУ. В виде готового сервиса эту задачу пытается решить БиблиоПоиск.

Примеры: https://allfind.kpfu.ru/, https://elib.pstu.ru/.

Типичная ошибка: библиотеки, внедрив поиск и не дождавшись удобных интерфейсов АБИС, кидаются в другую крайность и пытаются самостоятельно реализовать функционал АБИС и электронной библиотеки с помощью поиска. Им кажется это разумным так как веб-интерфейс АБИС часто поиск из себя в основе и представляет. Но так делать не надо: если вы не можете всё из поиска удалить и заново автоматически добавить и проиндексировать – значит вы поисковик используете не по назначению.

VuFind в КФУ. https://allfind.kpfu.ru

8.2. Корпоративный поиск[править]

Поиск по сайтам и базам данных в интранете, где АБИС – один из поставщиков данных. Когда-то давно Яндекс выпускал поисковый сервер с роботом для обхода ресурсов в интранете, но было это давно. Сейчас надо будет такой сервис писать самостоятельно. При реализации корпоративного поиска отдельный библиотечный можно не делать.

8.3. Поиск по научным статьям[править]

Подписные западные ресурсы не дадут себя полноценно индексировать поисковикам вуза, поэтому подписчикам на большое количество ресурсов придется покупать доступ к EBSCO Discovery Service или аналогу.

9. Файловый хостинг[править]

Преподаватели часто отправляют студентам какие-то файлы или принимают работы, а также задачи файлообмена есть у сотрудников вуза, поэтому может быть удобно локальное файловое хранилище. Для этих целей можно использовать открытый NextCloud.

Хотя файловые хранилища походят функционально на цифровые библиотеки (упорядоченное хранение файлов), созданы они принципиально для других задач: обмена и совместной работы с файлами. То есть это прежде всего продукт для текущей работы, а не презентации и доставки ресурсов.

В библиотеках часто есть пренебрежение к пользовательским файлам, дескать не библиотечное это дело работать с некачественным контентом. Вместе с тем проблема работы с файлами хорошо известна в корпоративной среде и для ее решения существует такое ПО как Microsoft SharePoint, IBM FileNet, Alfresco, SAP Content Server, Oracle Content Server, хотя стоит добавить, что упомянутое ПО может заниматься не только хранением файлов, но все же используется и для этого.

Примеры ПО: NextCloud, ownCloud, VK WorkDisk.

Примеры: https://disk.hse.ru/, https://oc.mpgu.su/.

10. Файлообменник[править]

Файловый хостинг нужен чтобы файлы хранились долго, упорядоченно и с ними выстраивалась какая-то работа.

Файлообменник нужен для обмена файлами, при этом длительное хранение не предполагается и файлы будут автоматически удалены по истечению какого-то срока. Файлообменник нужен чтобы пользователи не забивали квоты файлового хостинга файлами, которые надо просто передать и которые не нужно длительно хранить.

Пример ПО: открытый Firefox Send, модуль SendFile в ELiS.

Пример: https://files.psu.ru.

11. Сервис единого входа[править]

Я уже перечислил с десяток продуктов и иметь для каждого собственные аккаунты крайне неудобно с точки зрения их выдачи и блокировки при увольнении/отчислении. Гораздо удобней сделать один единственный сервер на котором хранятся аккаунты (логины и пароли) и все сервисы, которые вы внедряете, будут брать аккаунты именно с этого сервера и проверять по нему пользователей. Конечно, такой сервер должен быть единый на весь вуз, чтобы ко всем сервисам вуза был единый логин с паролем. Такой сервис поддерживает не библиотека, а ИТ-команда вуза, но библиотека свои продукты должна стыковать с этим. Базой данных с аккаунтами обычно является сервер LDAP, но по причинам безопасности не стоит сайты подключать к LDAP напрямую, а лучше добавить веб-сервис единого входа (Single Sign On, SSO).

Известный в библиотечных кругах ФЕДУРУС тоже является сервисом единого входа, но для других целей – доступа к подписным ресурсам, я же сторонник SSO не для доступа к подпискам, а для входа на внутренние ресурсы организации.

Пример ПО: OpenLDAP + Keycloak.

12. Конструкторы образовательных ресурсов[править]

Преподаватели чаще всего не используют чужие курсы и учебники, работая по собственным материалам. Этот процесс и приводит к тому, что вроде у библиотеки много чего есть для получения знаний, но в среднем студент заходит в ЭБС 4 раза в год и значит библиотеки и ЭБС не особо нужны образовательному процессу.

Однако культура создания образовательных ресурсов низкая, без использования специализированного ПО для создания именно образовательных ресурсов с добавлением тестов, мультимедиа и различных заданий ресурсы не слишком отличаются от презентаций и учебников. Поэтому популяризация использования конструкторов может и улучшить учебные результаты и включить библиотеку в реальный образовательный процесс.

Здесь можно выделить конструктор H5P с поддержкой 50 типов интерактивных заданий, включая интерактивные презентации (замена PowerPoint) и интерактивные учебники (замена PDF), который можно установить в Moodle, WordPress, Drupal и использовать в качестве вузовского продукта. Независимо от того, где созданы ресурсы, их надо хранить или в LMS или в цифровой библиотеке. ELiS позволяет создавать образовательные ресурсы H5P прямо в цифровой библиотеке преподавателя и отдавать результаты решений в другие LMS через SCORM, однако при наличии программистов нечто подобное можно создать и самим в WordPress/Drupal.

При выборе где разворачивать H5P: в LMS или в цифровой библиотеке, важно помнить разницу, что в Moodle для публикации ресурсы должны включаться в курс, а пользователь войти в курс гостем, в то время как опубликованные в библиотеке ресурсы можно просто использовать перейдя по ссылке. Какой ресурс преподавателю где размещать лучше – зависит от случая, поэтому надо реализовать конструктор и в составе цифровой библиотеки и в LMS.

Пример ПО: H5P, ELiS.

Пример: https://udoba.org (ELiS).

Сервис Удоба с конструктором H5P на базе ELiS. https://udoba.org.

13. Хранилище цифровых следов[править]

Пока российские библиотеки радуются использованию COUNTER и знанию количества скачанных книг, в образовании прямо в конструкторах ресурсов зашивают трекинг событий, происходящих в процессе обучения: как и на какие вопросы пользователь отвечал, когда какие слайды перелистывал, в какой момент проматывал видео и т.д. на основе стандарта xAPI. Так как систем, в которых идет учебный процесс, много и некоторые ресурсы арендованы на сторонних сервисах, для анализа учебного процесса цифровые следы собираются в единую на организацию базу данных, которую называют Learning Record Store (LRS). Формат событий стандартизован с возможностью расширения под новые типы событий и есть готовое ПО для организации хранилища.

Примеры ПО: Learning Locker.

14. Система аналитики и управления на основе цифрового следа[править]

Цифровые следы нужны, чтобы извлекать из них что-то полезное, для этого нужна система аналитики и система управления, которая в некоторых случаях будет запускать действия на основе событий (рассылка уведомлений, рекомендаций и т.д.). Это надо все создавать и интегрировать с другими информационными системами самим и именно здесь можно ожидать основное развитие в ближайшие годы.

Но можно ли от цифровых следов получить пользу сейчас? В библиотеке ELiS для заданий H5P создана простая система аналитики, дающая рекомендации преподавателям в каких заданиях у них какие проблемы, а для презентаций и PDF подсказывающая какие страницы сколько просматривают, также есть возможность просмотреть как конкретный пользователь взаимодействовал с заданиями, презентациями, PDF. Прямо в ELiS это сделано это для получения пользы от цифровых следов здесь и сейчас, когда в России LRS еще практически не используются.

Аналитика в ELiS по тесту на знание цифровой трансформации https://demo.elibsystem.ru/node/38726 показывает, что мало людей, которые бы отвечали правильно на большинство вопросов в тесте, причем 30% ответивших на первый вопрос пропустили оставшиеся.

15. Управление лицензиями[править]

Хорошо иметь сервис, где записано на какие ресурсы есть доступ и когда он закончится. Ресурсы с закончившимся доступом надо удалять из поиска и пересчитывать книгообеспеченность.

16. Видеохостинг[править]

Видео – достаточно тяжелый ресурс и многие пользуются YouTube, так как это бесплатно не смотря на понятные риски. В LMS технически можно размещать видео, но лучше не стоит из-за роста нагрузки при активных просмотрах. Для создания видеохостинга внутри есть специальное ПО с распределенным транскодированием (с целью сжатия видео под низкоскоростные сети) и хранением (распределение нагрузки при просмотрах). Модули видеохостинга есть в ELiS, существовали для Joomla! и Drupal, есть отдельные системы, такие как Kaltura и PeerTube и даже есть пример создания видеохостинга в СФУ на Drupal своими силами.

Примеры ПО: ELiS, Kaltura, PeerTube.

Примеры: https://tube.sfu-kras.ru/, https://elis.psu.ru/node/643230.

Видеохостинг СФУ. https://tube.sfu-kras.ru.

17. Хостинг сайтов[править]

В вузе есть сайты факультетов, кафедр, лабораторий, подразделений, отдельных проектов и для этих сайтов нужен хостинг. Каждый раз запускать уникальный сайт, его поддерживать и обновлять когда сайтов сотни – становится очень затратно и это сказывается на качестве сайтов. У Гарвардского университета есть проект OpenScholar в виде модулей для Drupal, специально созданных для разворачивания академического сайта https://openscholar.harvard.edu/ и с помощью него в Гарварде развернуто 660 сайтов с 2 млн. просмотров страниц в неделю с быстрой процедурой запуска нового типового академического сайта.

Аналогичный продукт был бы полезен для каждого не слишком малого вуза. Не обязательно его делать именно на Drupal, сегодня можно рассмотреть и написание модулей и среды развертывания и обновления сотен сайтов на WordPress. Drupal гибче и имеет консольную утилиту администрирования drush, WordPress проще для пользователей и может сам обновляться.

Сайт проекта OpenScholar со статистикой использования в Гарварде. https://openscholar.harvard.edu/

18. Удаленный доступ к подпискам[править]

Это то, что должно быть у всех уже давно, но многие так и не смогли удаленный доступ организовать удобно. Я до сих пор считаю наиболее удобным использование универсального механизма проксирования и в России для этого можно использовать KOO proxy и KOO browser, но есть и множество других решений, которые я описал в статье «Способы удаленного доступа к ресурсам организации» в ноябрьском выпуске Университетской книги еще в 2019 г.

Примеры ПО: VPN, KOO Proxy/KOO Browser, ФЕДУРУС.

Работа прокси-сервера для доступа к локальным и удаленным ресурсам. https://koo.elibsystem.ru.

16. Система мониторинга[править]

Когда у вас много цифровых продуктов и они ломаются, нужна система мониторинга для быстрого обнаружения и сигнализации о проблемах. Она проверяет, что сервисы доступны, память не кончилась, место не кончилось, страницы веб-сайтов отвечают и можно запрограммировать другие проверки работоспособности сервисов.

Примеры ПО: Zabbix, Nagios

17. Цифровое интерактивное издательство[править]

Не секрет, что издательства иногда объединяют с библиотеками и действительно, когда издание становится цифровым и не просто PDF, тогда его надо создавать в конструкторах, где-то выкладывать, возможно обеспечивать ограниченный доступ другим организациям и объединением можно улучшить работу с цифрой.

Видя развитие курсов, издательства пытались тоже развиваться, но не от HTML, а от PDF, наполнения его заданиями, мультимедиа и интерактивами с помощью ПО «цифрового издательства». Фактически цифровое издательство идет в сторону тех же конструкторов, но с издательской спецификой. Впрочем, эта ветвь развития может оказаться тупиковой так как конструкторы вместе с LMS не оставят пространства развития для цифровых издательств.

Пример ПО: fulcrum.

18. Бронирование помещений и общих ресурсов[править]

В любом случае в вузе будут коворкинги или какие-то общие помещения и ресурсы с возможностью бронирования (вебинарные комнаты, центры коллективного пользования), а развитие индивидуальных образовательных траекторий будет приводить к окнам в расписании, которые надо где-то чем-то полезным занять. Поэтому нужен сервис бронирования. В простейшем случае используется общий календарь, но можно написать и специализированное ПО.

19. Базы знаний[править]

Иногда преподаватели и исследователи заинтересованы в создании базы знаний. Это база может состоять из учебных ресурсов по какой-то тематике или общевузовская база по всему сразу, а может база для каких-то исследований.

Для баз знаний существует специализированное ПО, в том числе можно использовать открытое ПО на котором создана Википедия – MediaWiki. Со стороны вуза должен быть сервис хостинга баз знаний.

Пример ПО: MediaWiki, Confluence.

20. Учебная вики[править]

Связанная вещь с базой знаний – учебная вики. Место, где люди совместно работают над какими-то ресурсами и проектами, при этом содержательное качество ресурсов значения не имеет, это именно место совместной работы, в котором может быть и учебный мусор.

ПО может быть аналогичное базе знаний, а могут использоваться и текстовые редакторы с функцией совместного редактирования.

21. Аренда системы поиска заимствований[править]

Такие системы большинство и так арендует, но может потребоваться интеграция в свои информационные системы.

22. Система прокторинга[править]

Системы прокторинга нужны чтобы удостовериться, что удаленный студент при работе с цифровыми продуктами работает в них лично и не жульничает. Обычно прокторинг избыточен для каждого тестирования и используется в каких-то значимых случаях, таких как удаленная сдача экзамена, защита ВКР, сдача контрольной точки и т.п.

Некоторые арендуют системы прокторинга. Можно делать собственные, если хватит умений.

Пример ПО: ProctorEDU.

23. Справочно-правовые системы[править]

Кодекс, КонсультантПлюс и другие справочные системы вузы и так арендуют, но надо не забывать, что к ним надо обеспечить доступ из интернета.

24. Станции самосканирования[править]

Публичный сканер, на котором люди сами сканируют книги или другие ресурсы, а затем загружают на файлообменник или флешку. В бюджетном варианте можно использовать документ-камеры.

В России продукт плохо развит, так как в России библиотеки на этом стараются зарабатывать деньги, тогда как стоило зарабатывать лояльность.

С распространением на смартфонах приложения Microsoft Lens станция самосканирования теряет актуальность, но и при использовании смартфона создать условия для самосканирования хорошим освещением с инструкциями будет полезным.

Сканер

25. Сервис рассылок[править]

Чтобы эффективно информировать пользователей рассылки должны быть направленными: разделить пользователей по интересам и отправлять письмами только ту информацию, которая пользователям интересна, сделать простыми отписки. В сервисах можно создать группы, отправлять в разные группы письма, посмотреть открывают или не открывают письмо и делают ли переходы по ссылкам и понять в конечном счете эффективна рассылка или нет.

Сейчас распространены облачные сервисы рассылок.

26. Системы управления взаимоотношениями с клиентами (CRM)[править]

Если смотреть дальше, то рассылки являются частью управления взаимоотношениями с преподавателями, администрацией и студентами. Есть специальный класс ПО для таких целей. Хотя CRM чаще всего используется в продажах и поддержке пользователей, она может быть полезна и вузу. Конечно, CRM нужна единая на вуз, а не каждому подразделению своя, что делает задачу внедрения CRM довольно сложной.

Пример ПО: Битрикс24.CRM

27. Видеоконференцсвязь (ВКС)[править]

Это системы, где куча людей одновременно общается с помощью видео. Раньше это часто были дорогие аппаратные системы, но сейчас рынок заняли программные. Хорошо показал себя Zoom, но он за границей.

Примеры ПО: Jitsi, TrueConf, сервисы VideoMost, Яндекс.Телемост, сервисы трансляций в соцсетях.

28. Вебинары[править]

ВКС нужна чтобы для коммуникации одновременно множество человек с помощью видео, хотя ВКС можно использовать и для трансляции рабочего стола и проведения презентаций. Вебинары (от веб-семинары) специально созданы для обучения с помощью веба и имеют инструменты совместного управления презентаций, проведения опросов, совместного рисования на слайдах и т.д.

В вебинарах обычно одновременно общается небольшое количество людей (преподаватель и студент, который отвечает на вопросы), а презентации часто загружаются заранее и отображаются статическим изображением для уменьшения объема трафика.

Примеры ПО: открытый BigBlueButton, коммерческий eClass, сервис Webinar.ru.

Для вебинаров и ВКС часто используются внешние сервисы, так как ПО для онлайн-работы с видео очень чувствительно к тому, чтобы сервера и сеть не были перегружены и вуз не всегда может обеспечить их надежную работу.

29. Система управления проектами[править]

Про управление проектами много говорят, но тогда необходимо специально ПО для проектов. Систем управления проектами много, платные, бесплатные, облачные. Если хотите у себя поставить, посмотрите на OpenProject.

30. Рекомендательные системы[править]

Собирая цифровые следы (в широком смысле, не только учебные) можно пытаться на знании о поведении людей строить рекомендательные системы и рекомендовать с их помощью адресно не только какие-то ресурсы и курсы, но и события из вузовской жизни. Для преподавателей рекомендательные системы могут подсказывать какой студент нуждается в поддержке, а кого стоит проверить. Разрабатывать такие системы надо самостоятельно.

31. Хостинг научных журналов[править]

Есть ПО для автоматизации работы редакции и хостинга научных журналов как продукта работы редакции. Часто для этих целей используют Open Journal System (OJS). Модель монетизации OJS предполагает, что её открытая версия будет не вполне законченной и зарабатывают на её доработанных редакциях, предоставляемых в качестве сервисов. В России этим занимается Elpub, дополняя издательский сервис дополнительными услугами, фактически беря на себя часть издательского процесса.

Вузы обычно вкладывают в аренду OJS для 2-3 журналов с наилучшими перспективами, для остальных можно:

хостить самостоятельно недоработанные OJS или вложиться в их доработку;
редакцию оставить в OJS, а готовые выпуски размещать или в специально заказанных вебмастерам сайтах (важно правильно отдавать метаданные для попадания в Google Scholar) или в электронной библиотеке, например в ELiS можно сделать хостинг готовых журналов с автоматическим скачиванием из OJS.

Пример как может выглядеть выпуск журнала в Elpub (OJS) и в ELiS.

32. Наборы научных данных[править]

В процессе исследований ученые собирают и генерируют научные данные. Их надо где-то хранить и ограничивать доступ. В одних случаях данные надо публиковать для прозрачности результатов, в других они являются сырыми, их хранение необходимо для сохранности, но доступ ограничен. Наборы данных бывают структурированные и нет.

ПО для работы с данными много, можно упомянуть DKAN – основанный на Drupal и значит который можно адаптировать под себя без программирования и CKAN – платформа работы с данными на python.

32.1 Структурированные данные[править]

Для структурированных данных есть специальный класс ПО по работе с ними. В таком ПО можно часто просматривать данные с сайта, сортировать, иногда проводить простую аналитическую обработку, подписываться на изменения, публиковать схему, создавать каталог и т.д.

Отображение структурированных данных на портале открытых данных Минкультуры.

32.2 Неструктурированные данные[править]

Очень часто научные данные не табличные и не структурированные. Это какие-то кучи фотографий, видео испытаний, различные файлы, программный код, еще что-то. Это всё можно упаковать в ZIP-архив и загрузить куда угодно: в электронную библиотеку, архив, институциональное хранилище. Единственное, что потребуется: поддержка описания, чтобы потом данные можно было найти и желательно поиск по содержимому. Специализированные системы работы с неструктурированными данными позволяют смотреть и скачивать отдельные ресурсы, не скачивая весь архив. В том числе так может и ELiS c CKAN.

Пример: https://data.bris.ac.uk/data/dataset.

32.3 Системы аналитической обработки и визуализации данных[править]

Для полезного использования структурированных данных было бы удобно, чтобы их можно было визуализировать и провести простую обработку прямо на сервисе, где они хранятся или рядом стоящем сервисе, но чтобы не скачивать к себе на ПК и не писать код для статистической обработки (да и не каждому это под силу). Для этого существуют специальные аналитические системы для структурированных данных, в том числе могут использоваться системы бизнес-аналитики.

Пример ПО: PolyAnalyst, FlyBI

Пример: PolyAnalyst в ТГУ

Визуализация результатов исследований библиотек вузов

33. Сайты конференций[править]

Для проведения конференций желательно специализированное ПО. Особой специфики у научных и образовательных конференций нет и можно использовать универсальное ПО для проведения событий. Посадочные страницы и сайты конференций часто создают в Tilda, а разместить материалы можно в цифровой библиотеке. Если конференция заочная, в месте размещения материалов нужна возможность комментирования для вопросов и ответов.

34. Системы управления исследованиями[править]

Организации начали мотивировать ученых на статьи и исследования и чтобы знать сколько денег надо заплатить и что было сделано, используются системы управления исследованиями (CRIS). Есть как готовое ПО (Pure), так и можно в простейшем случае предложить ученым самим вводить свои статьи и другие результаты научной работы в какую-то самописную систему с полуавтоматическим контролем. Там где мониторинг исследований в вузе, там же и центр компетенций по наукометрии.

Пример: https://science.urfu.ru.

Цифровая культура[править]

Цифровая культура организации — способ управления организацией и развития ее сотрудников, в соответствии с которым цифровые инструменты и данные системно применяются в повседневной операционной деятельности для непрерывного улучшения и развития, их применение ориентировано на удовлетворение потребностей клиентов, качество и эффективность.

Внедрение перечисленных выше сервисов затруднительно без формирования цифровой культуры в организации.

Цифровая культура сотрудников – система ценностей, установок, норм и правил поведения, принимаемые сотрудником при работе с цифрой.

Принятие цифровой культуры будет означать:

клиентоориентированность;
ориентация на данные, а не на мнения и трактовки.

Ориентация на данные, кроме прочего, означает развитие через тестирование гипотез. Идея о нужности некоего сервиса или пользе от изменения существующего – это гипотеза, которую предстоит проверить на практике путем измерений поведения пользователей. Если гипотеза не подтверждается данными, то ее следует откинуть, вплоть до закрытия невостребованных сервисов или отката внесенных изменений.

Пробовать и ошибаться – нормальная ситуация при развитии цифровых сервисов. Это риски, которые надо принять.

Цифровая зрелость[править]

При планировании цифровой трансформации надо понять где организация находится в текущей момент. Делается это с помощью оценки «цифровой зрелости», в которую входит, кроме прочего, оценка имеющихся цифровых продуктов и инфраструктуры. В статье перечисленные продукты и сервисы, как элементы инфраструктуры инфотеки, а в более широком смысле как элементы оценки цифровой зрелости вуза.

Роль библиотеки[править]

Многие ошибочно смотрят на цифровую трансформацию как способ улучшить существующие процессы, на самом деле трансформацию (изменение) библиотеки надо начать с того, для какой цели библиотека существует, в чем ее миссия и лишь затем определять наилучшие способы достижения цели и определять какие новые процессы нужно создать, какие изменить, а какие ликвидировать.

Обычно библиотеки вузов нужны для информационного обеспечения учебного и научного процессов. А для этого надо понять какие проблемы в информационном плане в обучении и в науке у организации существуют и что надо сделать, чтобы помочь их решить, причем «информационное обеспечение» надо понимать широко, а не только как доступ к изданиям.

В результате быстро становится понятна ответственность библиотеки (а точнее информационного института) не только за ресурсы, но и за информационные сервисы, но чтобы к этому прийти, надо сделать шаг назад к исходной информационной роли библиотеки, чтобы понять, что печатный фонд в амбаре – лишь средство, оставшееся в XX веке, как средством являются и подписки на ресурсы, малоэффективные в конспектоориентированном обучении. А вот цифровые сервисы и продукты с одной стороны важны в XXI веке и массово используются, с другой – намного шире библиотечного фонда. Значит и функционал информационного института должен быть широк, иначе это не информационный институт, а кошелек для аренды подписок, который никак не может называться библиотекой. Отсюда вытекает преобразование библиотеки в инфотеку как путь институционального развития через трансформацию, в то время как клубизация библиотек – это ликвидация института.

Выводы[править]

Загибая пальцы какие сервисы у библиотеки вуза есть, вы наверное уже поняли, насколько отстали даже наиболее продвинутые вузовские библиотеки. При этом перечислены только те сервисы, которые стоило бы внедрить к сегодняшнему дню. И даже если библиотека вдруг начнет внедрять по 3 новых сервиса в год, ей понадобиться не менее 10 лет, чтобы догнать текущий уровень (сократить отставание до 10 лет), т.е. отставание даже у лучших библиотек уже 20 лет. Большинство же оказалось не способно за 30 лет даже с АБИС и цифровой библиотекой разобраться в клиентоориентированном ключе. Таким пройти через цифровую трансформацию вряд ли грозит, а значит они вполне предсказуемо умрут. Поэтому современные библиотеки напоминают мне ходячих мертвецов: они думают, что живы, их действия напоминают что-то живое, но на самом деле они в стадии разложения и проще созидать рядом что-то с нуля, чем пытаться оживить мертвецов.