Шелюто О.Н., Скворцов В.В.
Российская национальная библиотека,
С.-Петербург
Технологические аспекты
внедрения
автоматизированной системы в РНБ
С момента появления интегрированных библиотечных систем в России нам постоянно приходится отвечать на вопросы (в том числе и самим себе): почему бы не внедрить одну из них в нашей библиотеке или почему бы вам у себя не внедрить такую-то автоматизированную библиотечную систему?
Ответ, как правило, дается на интуитивном уровне и звучит примерно так: "Этого нельзя сделать в силу специфики нашей библиотеки". При этом специфика не раскрывается.
Попытаемся раскрыть смысл этой загадочной фразы и показать, как мы решаем эту задачу в РНБ.
Предпосылки
Если говорить о двух технологиях – традиционной и автоматизированной – как о двух крайних случаях, важно отметить, что это совершенно разные технологии, хотя и выполняют в сущности одни и те же задачи. Это различие закреплено не просто в организационных решениях, сопроводительной и отчетной документации, но и в самой структуре подразделений, участвующих в технологических процессах. Даже поверхностный анализ показывает, что совершить переход из прошлого в будущее за один шаг нельзя. Отсюда два очевидных принципа, положенных в основу внедрения автоматизированной технологии в РНБ.
Первый – поэтапное изменение технологии на базе постепенного внедрения автоматизированной системы. Другими словами, необходимо построить несколько промежуточных технологических процессов, каждый из которых является очередным приближением к идеальной автоматизированной схеме. Как показывает практика, даже такой подход не делает процесс внедрения автоматизированной системы абсолютно безболезненным, но это единственный способ, позволяющий не разрушить полностью производственный цикл.
Второй принцип – настройки автоматизированной системы должны позволять ей работать в каждой из промежуточных технологий. И это весьма существенное требование к внедряемой системе, но оно часто недооценивается.
Что такое технологический процесс с точки зрения постановки задачи? Это движение неких объектов по заданной структуре с целью последовательной их обработки.
Для библиотеки такими объектами являются библиографическая запись, экземпляр документа, заказ комплектования, заявка читателя, заявка фондов комплектованию, сопроводительные документы (которых в крупной библиотеке целая россыпь), документы отчетности (о них можно сказать то же самое), инвентарь фондов, различные акты – и это неполный перечень. Образно говоря, масса документов в бумажной и в электронной форме движется по извилистой сети заранее проложенных путей, определяемых организационной структурой библиотеки.
При переходе от традиционной к автоматизированной технологии должны изменяться и сами объекты, причем не только их форма и содержание. Какие-то из них исчезают, появляются новые, которые могут действовать постоянно либо в течение какого-то промежуточного периода. И все это связано с изменяющейся организационной структурой и с изменяющимся характером работ структурных единиц.
Как правило, в существующих автоматизированных системах технологическая схема представляется либо тремя АРМ: комплектатора, каталогизатора (иногда систематизатора), фондов и обслуживания – что совершенно неприемлемо для крупной библиотеки в силу разного характера работ сотрудников даже одного подразделения, либо тремя модулями с теми же названиями (или четырьмя модулями, если считать контроль сериальных изданий), что подразумевает существование нескольких АРМ в одном модуле и гибкую настройку рабочих листов и выходных форм, т.е. возможность создания новых АРМ в рамках модуля. (Мы сознательно оставляем вне рассмотрения модуль ОРАС, наименее связанный с технологическим процессом.)
Чего же не хватает крупным библиотекам в этом случае? Почему, например, не внедрить в РНБ одну из универсальных автоматизированных систем, предлагаемых на отечественном или зарубежном рынке?
Мы бы выделили здесь две основные причины, хотя их может быть и больше.
Первая и очевидная причина заключается в многообразии того, что выше мы назвали объектами и в сложности их обработки, что как правило не полностью учитывается разработчиками универсальных систем. Поэтому требования пользователей сплошь и рядом выходят за рамки настроек модулей и требуют специальной доработки систем. Как показывает практика, на этом обычно и заканчивается внедрение зарубежных систем в наших крупных библиотеках.
Теперь давайте вспомним о том, что процесс внедрения автоматизированной системы, например в РНБ, мы договорились осуществлять последовательно, небольшими шажками. А это значит, что требования, выдвигаемые пользователями, при всем их многообразии еще и постоянно меняются. Это может нанести моральную травму любому производителю.
Вторая причина более существенна – это организация технологического процесса как такового.
Дело в том, что путь ряда основных объектов должен быть определен на каком-то этапе обработки и должен контролироваться системой. Например, разные экземпляры одного и того же издания направляются в разные фонды и идут туда различными путями: одни из отдела комплектования идут прямо в фонд, другие через отдел обработки; одни попадают по пути на выставку новых поступлений, другие – нет. Пути экземпляров различны не только между отделами, но и внутри отделов. Последовательность их движения должна контролироваться системой в каждом узле сети, по которой они движутся внутри отделов и между ними.
А теперь давайте представим, что мы постепенно меняем технологию, т.е. меняем пути, структуру и даже сами объекты, причем делаем это не один раз. Система, которую мы при этом внедряем, должна обеспечивать задание пути движения, его контроль, а также контроль информационного состояния объектов на любой стадии проводимых изменений. Какая из известных систем удовлетворяет этим требованиям?
Постановка задачи
Прежде всего отметим, что определение технологии (назовем ее общей технологией) с точки зрения постановки задачи приобретает следующий вид: общая технология – это движение абстрактных объектов по абстрактной структуре с целью последовательной их обработки.
Это определение позволяет разложить задачу на три составляющие:
Мы должны определить объекты таким образом, чтобы удовлетворить любым мыслимым фантазиям (что просто) и чтобы это было практически осуществимо (что сложнее).
Мы должны уметь задавать движение этого объекта по любой структуре, независимо от того, как выглядит сама эта структура.
Мы должны уметь задавать структуру в любой момент времени, не нарушая общего технологического процесса, т.е. не нарушая движения по ней наших объектов.
Задача 1. Определение объекта
Мы определяем объект следующими параметрами:
1. Атрибуты объекта. Атрибуты объекта – это его информационное наполнение. Для задания атрибутов объекта определяется список полей, отвечающих как за описание самого объекта, так и за его содержание. Например, для объекта библиографическая запись таким списком является библиографический формат RUSMARC; для объекта авторитетная запись – формат RUSMARC для авторитетных записей; для объекта экземпляр – поля, отвечающие за описание экземпляра, и т.д.
2. Связи объекта. Большинство объектов могут существовать не сами по себе, а только в связи с другими объектами. Например, объекты экземпляр издания и заявка читателя могут существовать только в связи с другим объектом – библиографическая запись. Объекты счет, акт, внутренняя путевка, как правило, связаны с множеством объектов экземпляр и т.д.
3. Технологические параметры. Ряд параметров является общим для всех объектов и служит для установления их характеристик и организации их движения. Здесь мы выделяем следующие параметры:
3.1. Тип объекта. Например, объект заказ комплектования имеет в РНБ следующие типы: разовый заказ, продолжающийся заказ, подписка, членство в организациях.
Таким образом, тип объекта – это постоянный параметр, позволяющий группировать объекты в соответствии с определенным принципом. В рассматриваемом случае – по функциональному принципу, поскольку разный тип заказа подразумевает различный порядок работы с ним.
Объект экземпляр может типизироваться, например, по источнику поступления: обязательный экземпляр, покупной экземпляр, экземпляр обмена, дар.
3.2. Статус объекта. Тот же пример. Объект заказ комплектования приобретает в РНБ следующие статусы:
открытый заказ в запись о заказе введены начальные данные. Заказ доступен для включения в него данных о документах, которые хотела бы приобрести библиотека;
предполагаемый заказ – заказ полностью сформирован; ожидается подтверждение от поставщика на возможность выполнения заказа данного набора документов;
предварительный заказ – подтверждение от поставщика получено;
ожидаемый заказ – получено подтверждение от поставщика о получении денег;
частично выполненный заказ;
заказ, выполненный полностью;
отмененный заказ.
Один и тот же объект с течением времени приобретает различные статусы. Таким образом, статус – это переменный параметр, определяющий порядок работы с объектом. Понятно, что статус может быть функцией параметра "тип объекта".
3.3. "Настоящее местоположение" – переменный параметр, связанный со структурой, существующей в данный момент времени и используемый совместно с параметром "идентификатор пользователя".
3.4. "Время 1" – время (дата + время) приема объекта в настоящем местоположении.
3.5. "Время 2" – время (дата + время) передачи объекта в следующий узел структуры.
Три последние – параметры, последовательно записываемые и сохраняемые системой, – образуют историю движения объекта.
3.6. "Предыдущее местоположение" – переменный параметр, связанный со структурой, существующей в данный момент времени.
3.7. "Контрольное время" – параметр, определяющий срок автоматической передачи объекта в "местоположение 3".
3.8. "Местоположение 3" – параметр, определяющий узел структуры, в который должен быть передан объект по достижении контрольного времени.
3.9. "Конечное местоположение" – параметр, как правило соответствующий направлению в фонд.
4. Входные и выходные формы. Дисплейные и печатные формы, служащие для формирования объекта и его представления пользователю. Строго говоря, эти параметры привязываются не к объекту, а к узлам структуры, поскольку могут меняться в зависимости от местоположения объекта. Говоря математическим языком, входные и выходные формы являются функциями узлов системы и самого объекта.
Задача 2. Задание движения объекта
Движение объекта задается следующим образом. Каждый последующий узел структуры, в котором должен оказаться объект, однозначно определяется в "настоящем местоположении" либо автоматически, либо полуавтоматически – через задание контрольного срока и "местоположения 3", либо вручную.
Задача 3. Определение структуры
Определить структуру в нашем случае означает: определить ее узлы, функции в этих узлах и связи узлов.
1. Связи узлов. Определяются совокупностью возможных путей передачи объекта из "настоящего местоположения" в другие узлы. (О том, как организуется само движение по этим путям, говорилось в предыдущем разделе.)
2. Определение узлов. Наименьшие узлы структуры в нашем случае – это рабочие места, те же АРМ. Эти узлы объединяются в более крупные узлы, например в группы. Те в свою очередь могут объединяться в еще более крупные и т.д.
Наши традиционные модули – комплектование, каталогизация, фонды – получаются путем такого объединения узлов, как звенья одной цепи, а не создаются отдельно, как это делается обычно при модульном подходе. Иначе говоря, создание модуля – это настройка системы, а не написание программы.
В системе, работающей в настоящее время в РНБ, это делается при помощи программы-администратора. Руководитель подразделения сам может создавать необходимые подразделения более низкого уровня, а также АРМ, если это необходимо, а программа-администратор включает их в общую рабочую структуру.
3. Определение функций узлов.
3.1. Построение АРМ. Мы считаем, что первый шаг – определение узла, в данном случае АРМ – уже сделан, как это описывалось в предыдущем разделе, и необходимо лишь задать его функции.
Функции АРМ задаются совокупностью рабочих листов, объектов, выходных форм и форм представления объектов, приписываемых данному АРМ. Эта задача также решается с помощью программы-администратора.
3.2. Построение узлов более высокого уровня. Руководитель подразделения объединяет АРМ в более крупные узлы через задание связей. Связи узлов задаются в программе-администраторе в виде списка узлов, доступных данному АРМ. При этом любое из направлений может быть задано по умолчанию.
Таковы вкратце главные принципы, положенные в основу автоматизированной системы РНБ. В реальной жизни, конечно, не все так гладко и у нее еще много недостатков, но есть и несомненное достоинство – система дышит и развивается. И главное, она делает возможным то поэтапное изменение технологии, о необходимости которого говорилось выше.