Воройский Ф.С. Основы проектирования автоматизированных библиотечно-информационных систем

Подождите немного. Документ загружается.

131

• контроль выполнения регламентных задач на базах данных различными категориями

исполнителей по формальным признакам (времени, количеству обращений и т.п.);

• контроль внутрибиблиотечного движения литературы (в том числе документов на маши-

ночитаемых носителях);

• электронная подпись, подтверждающая факт приёма литературы (от читателя или из

другого подразделения библиотеки).

Задачи контроля пользователей

• обеспечение доступа зарегистрированных пользователей в библиотеку, а также к элек-

тронному каталогу и другим информационным ресурсам общего пользования (в локаль-

ном и удалённом режимах);

• защита от несанкционированного доступа ко всем видам информационных ресурсов

библиотеки лицам, не имеющим на это права;

• защита баз данных АБИС от разрушения;

• разграничение пользователей по формам библиотечно-информационного обслуживания;

• получение исходных данных для многоаспектного анализа (в том числе статистического)

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

вателей АБИС;

• электронная подпись пользователя, подтверждающая факт заказа на литературу или ус-

лугу АБИС, а также их получение.

Аутентификфция персонала и пользователей обеспечивается комплексным использо-

ванием:

• программных средств, входящих в состав операционных систем (локальных и сетевых);

• программных средств, входящих в состав ПО АБИС;

• средств штрихового кодирования, включённых в состав программного и технического

обеспечения АБИС.

Степень реализации средств контроля и управления доступом к информационным ресур-

сам библиотечно-информационных систем в разных версиях специализированного программ-

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

можности даже существующих средств используются полно. Однако определённый опыт соз-

дания и практического применения этих средств уже имеется и развитие их использования в

перспективных системах не является проблематичным. Исключение в указанном плане пред-

ставляют средства реализации электронной подписи, которые применяются в других видах

автоматизированных систем (например, банковских). В настоящее время для ПО АБИС они

являются достаточно сложными и дорогими, поэтому их использование пока ещё ограничено

(подробнее см. [7 - 9]).

3. Автоматизированные средства контроля технологических и других процессов на-

чали широко использоваться в АСУ и наиболее развитых АСНТИ ещё 20-30 лет назад. При

этом программно-технический комплекс указанных систем настраивается на выдачу требуе-

мых данных (в том числе и статистических) по заданной номенклатуре контролируемых пара-

метров как в регламентном режиме, так и по индивидуальному запросу соответствующих кате-

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

входных документальных потоков в ВИМИ его автоматизированная система (ИСИО) начиная с

1970-х гг. еженедельно выдавала следующие сведения:

• количество поступивших на её вход документов разных видов

;

• количество документов каждого вида, обработанных в основных узлах технологической

цепи с соблюдением технологических норм;

• количество документов каждого вида, обработанных в основных узлах технологической

цепи с нарушением установленных сроков обработки;

• количество необработанных документов, задержанных в каждом звене системы и т.п.

Аналогичные справки автоматически формировались и выдавались руководству и по дру-

гим направлениям деятельности ВИМИ, в частности, по разным формам справочно-

информационного обслуживания пользователей. В АСУ различного назначения аналогичным

Для каждого «вида документа» (например, отчётов по НИОКР, информационных и регистрацион-

ных карт, книг, статей из периодических изданий и т.д.) устанавливались свои технологические

нормы времени обработки на каждом этапе.

132

образом формируются справки по всем наиболее важным показателям финансовой, органи-

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

С сожалением следует отметить, что подобного уровня сервис задач управления про-

граммно-техническими комплексами АБИС до сих пор не реализуется. Последнее утвержде-

ние отнюдь не означает, что возможности выполнения анализа различных процессов (в том

числе статистического), в программном обеспечении современных АБИС не заложены (см., в

частности, работы [10, 11]). Однако, как правило, получение нужных справок требует выпол-

нение ряда достаточно трудоёмких операций, связанных, например, с поиском массива или

массивов данных по группе признаков, выборкой найденных данных, загрузкой их в заранее

подготовленные формы, сортировкой, производством расчетов и статистической обработки

данных и т.п. Для выполнения указанной работы у руководителей библиотек и крупных их

подразделений нет времени, а чаще – и необходимых знаний и навыков. Современная АБИС

должна обеспечивать получение требуемых справок по заданной номенклатуре показателей

«нажатием одной-двух кнопок».

В зависимости от характера объекта автоматизации и условий его работы состав задач

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

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

ции средствами программного обеспечения АБИС.

Задачи, связанные с выдачей справок по комплектованию фондов:

• распределение заказов литературы по тематике и видам документов;

• распределение финансовых средств на заказы литературы;

• плановые календарные сроки поставки литературы и заключённым договорам;

• распределение полученной литературы по совокупности признаков (сроки, поставщики,

виды документов и т.д.);

• сведения о недопоставках литературы по заказам;

• распределение поступившей литературы по подразделениям библиотеки (в том числе

и её филиалам);

• неудовлетворённые заказы на литературу подразделений библиотеки и т.д.

Задачи, связанные с выдачей справок по работе подразделений обработки литературы

• количество документов, обработанных подразделениями или отдельными сотрудника-

ми в заданный период времени;

• статистические данные по срокам обработки входных документов разных видов под-

разделениями библиотеки (средних, минимальных, максимальных);

• количественные данные о необработанных документах разных видов и времени их на-

хождения в обработке.

Задачи, связанные с выдачей справок по работе подразделений обслуживания читателей:

• количество читателей и их состав (возрастной, профессиональный, образовательный

и т.п.);

• количество посещений библиотеки и отдельных её подразделений (в том числе фи-

лиалов) в заданный промежуток времени;

• количество и виды оказанных услуг пользователям в заданный промежуток времени

подразделениями и/или отдельными сотрудниками библиотеки;

• количество и характер неудовлетворённых запрос пользователей (с указанием причин

отказов) в заданный промежуток времени;

• тематические и другие формы статистического распределения заказов на литературу

(например, на литературный жанр, отдельных авторов или их произведения);

• читатели - нарушители сроков сдачи литературы и принятых штрафных санкциях;

• статистические данные о поступлении и расходовании средств, связанных с платными

услугами.

Средствами обеспечения автоматического решения задач управления и контроля явля-

ются:

• программно-технические средства АБИС;

• специализированные БД и электронный каталог, дополненный технологическими поля-

ми и (при необходимости) словарями терминов для заполнения нормированных полей

указанных баз данных.

133

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

жении, могут служить меню, дополненные окнами для установки параметров выдаваемых

данных.

Очевидно, что в процессе разработки ТЗ на проектирование АБИС и средств её про-

граммного обеспечения (см. Главу XIV) список задач автоматизированного контроля может

быть как существенно расширен, так и сокращён. В частности, это касается не приведенных

нами задач контроля работы подразделений хранения фондов. Тем не менее мы видим сво-

ей целью обратить внимание как потенциальных представителей заказчиков разработок

АБИС, так и их исполнителей на важность реализации в новых системах решения задач ука-

занного класса.

4. Телекоммуникационные средства диагностики и контроля работы и исполь-

зования основных программных и технических средств появились в 1996-1999 гг. в ре-

зультате выхода на рынки вычислительной техники вначале «сетевого ПК», а затем – «корпо-

ративного ПК».

Сетевой ПК [NetPC] представляет собой персональную ЭВМ, ориентированную на работу

массовых пользователей в распределенных и глобальных сетях, например Интернет. С ини-

циативой разработки эталонной платформы “сетевой ПЭВМ” в октябре 1996 г. выступили кор-

порации Intel и Microsoft при поддержке ведущих производителей аппаратных и программных

средств (Compaq, Dell, Digital, Gateway 2000, Hewlett-Packard, Nec, Texas Instruments и

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

приобретения ПК и сократить расходы на его техническую поддержку. Исходная конфигурация

включала: Pentium-100 Мгц; RAM-16 Мбайт; монитор-VGA; модем-28,8 Кбит/с; сетевой ре-

жим Ethernet или Token Ring. Предполагается также, что каждой NetPC изначально присваи-

вается идентифицирующий шифр [12].

В начале 1996 г. фирма Getway 2000 выпустила совершенно новую разновидность ПК

Destination, которая может также служить в качестве большого телевизора [13]. В 2000 г. поя-

вились так называемые legacy-free PC - архитектуры упрощенных ПК, являющихся Интернет-

приставками. Основной отличительной особенностью «ПК, лишённых наследства» является

то, что они используют основное программное обеспечение и внешнюю память, установлен-

ные на сервере Интернет-провайдера. Эти ПК привлекательны простотой обслуживания,

ориентированной на неопытных пользователей, и возможностью хранить данные «вне дома».

Однако их функциональные возможности весьма ограничены [14].

«Корпоративные ПК» [Corporate PC] представляют собой разновидность «Сетевого

ПК», снабженного средствами дистанционного управления и, в определенном смысле, – об-

служивания. Иногда его называют также «управляемым ПК». Современные ПК этого класса

располагают средствами учета и отслеживания всех системных ресурсов, аппаратного мони-

торинга, обнаружения попыток взлома системного блока, включения ПК по ЛВС, дистанцион-

ного включения и отключения питания. Помимо сказанного эти ПК могут использовать специ-

альные программные средства (например, Insigt Manager) для отслеживания состояния дисков

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

средств позволяет также производить дистанционное обновление BIOS, блокировать отдель-

ные компоненты системы и даже запирать корпус системного блока. Подробнее о современ-

ных конструкциях и моделях корпоративных ПК, их характеристиках и выборе см. [14-17].

В настоящее время опыт использования подобного рода программно-аппаратных средств

в автоматизированных библиотечно-информационных системах отсутствует, однако возмож-

ности, которые несут в себе указанные средства для решения задач автоматизации библио-

течно-информационных процессов трудно переоценить. Эти средства приобретают особое

значение в условиях жёсткого дефицита в библиотеках и информационных органах высоко-

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

лённых (в том числе корпоративных) библиотечных и информационных систем.

5. Дополнительные сервисные средства автоматизации контроля и управления

АБИС представляют собой совокупность средств программного, технического, информа-

ционного и лингвистического обеспечения, позволяющих руководящему составу и персоналу

системы производить поиск массивов необходимых данных, их сортировку, редактирование,

выполнение арифметических операций, формирование стандартных и нестандартных форм

документов и заполнение этих форм отобранными массивами данных. В настоящее время

134

накоплен значительный опыт проектирования, реализации и использования этих средств и

поэтому отдельного рассмотрения здесь не требует.

СПИСОК ЛИТЕРАТУРЫ

1. Воройский Ф.С. Аналитико-синтетическая обработка и переработка информации в

автоматизированных системах НТИ: основы организации и технологии. М.: ИПКИР, 1991.

217 с.

2. Система интегрированной обработки информации. Аналитико-синтетическая обработка

документов: Инструкция по эксплуатации. 7Т1.900.011-ИЭ14. М.: ВИМИ, 1983. 24 с. (На

правах рукописи).

3. ИСИО. Технология предварительной и аналитико-синтетической обработки зарубежных

изданий: Инструкция по эксплуатации. 7Т1.901.005-ИЭ17. М.: ВИМИ, 1983. 18 с. . (На

правах рукописи).

4. ИСИО. Технология предварительной и аналитико-синтетической обработки

отечественных материалов: Инструкция по эксплуатации. 7Т1.902.005-ИЭ2. М.: ВИМИ,

1983. 15 с. (На правах рукописи).

5. Воройский Ф.С. Интеграция технологических процессов и повышение эффективности

автоматизированных систем научно-технической информации // НТИ. Сер. I. 1988. № 12.

С.6-10.

6. Воройский Ф.С., Замараев В.И. Технология прямого ввода документов в БД автоматизи-

рованных систем НТИ: Норм. и метод. материалы. Сер. Орг. информ. деятельности. М.:

ВИМИ, 1988. вып. 5 (16). 38 с.

7. Воройский Ф.С. Информатика. Новый систематизированный толковый словарь-

справочник по информатике. М.: Liberея, 2001. 535 с.

8. Arms William Y. Digital Libraries. Cambridge, Massachusetts, London, England.: The MIT

Press, 2000. 287 p.

9. Егор Поваляев. Лексикон 5.0 – Русский стандарт // КОМПЬЮТЕР-ПРЕСС. 2000. N 6. С.

168-171.

10. Шрайберг Я.Л., Воройский Ф.С. Автоматизированные библиотечно-информационные

системы России: состояние, выбор, внедрение, развитие. М.: 1996, “Liberея”, 271 с.

11. Шрайберг Я.Л., Воройский Ф.С. Новые модификации известных отечественных автома-

тизированных библиотечно-информационных систем (Разработки ГПНТБ России, Разра-

ботки БЕН РАН, Разработки ГИВЦ МК РФ, Разработки ДИТ, Разработки НПО “Информ-

система” // С компьютером на Ты. М.: Liberея. 1998. Вып.1. С. 36-49.

12. Борзенко Андрей. “Железные” прогнозы // КОМПЬЮТЕР ПРЕСС. 1997. N1. С. 8-12.

13. Маккрэкен Гарри. Масштабы Gateway 2000 // МИР ПК. 1997. N12. С. 94.

14. Мец Кейд. Корпоративные ПК // PC MAGAZINE (Russian edition). 1999. N 1. С. 56-77.

15. Литтмен Дэн. Утончённые и вызывающие // МИР ПК. 2000. N 12. С. 28 — 36.

16. Мейц Кейд. Корпоративные управляемые ПК 9х // PC MAGAZINE (Russian edition). 2000.

N 3. С. 45-63.

17. Денисов Олег, Назаров Сергей. Высокопроизводительные ПК российских произво-

дителей // КОМПЬЮТЕР-ПРЕСС. 2000. N11. С. 58-68.

135

ЛАВА

XIV. В

ЫБОР И РАЗРАБОТКА СРЕДСТВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

АБИС

14.1. РАЗРАБАТЫВАТЬ ИЛИ ВЫБИРАТЬ ГОТОВОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ АБИС?

При ответе на поставленный вопрос нам менее всего хотелось бы, чтобы успех отдель-

ных организаций в создании программного обеспечения АБИС стал аргументом в пользу раз-

вития необоснованных инициатив в этой области. Тех руководителей и проектировщиков, ко-

торые желают создать свою разработку ПО АБИС, здесь уместно предупредить, что удачных

решений очень немного. Особенно, если соотнести их число с количеством организаций, сту-

пивших на этот путь: по имеющимся у нас данным соотношение жизнеспособных инициатив-

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

1:100. Опять же следует оценить экономическую целесообразность требуемых на оригиналь-

ную разработку затрат: известно, что эти затраты даже в самом благоприятном случае в де-

сятки и сотни раз выше затрат на приобретение готовых разработок.

Уместно отметить в рассматриваемом аспекте, что очень часто основным аргументом ЗА

разработку «своей системы» (и не только АБИС!) служит наличие в организации штатных про-

граммистов. Тратить деньги на приобретение в этих условиях «чужих» программных продук-

тов признается нецелесообразным. Это же относится к другим связанным с автоматизацией

затратам: консультативным услугам, обучению работников библиотеки, модернизации и под-

держки средств ПО и т.д.

Народная пословица гласит: «Скупой платит дважды». В нашем случае он платит во

много раз дороже! Помимо сказанного нелишним напомнить, что тот, кто решит создавать

своё оригинальное ПО АБИС, рискует затянуть его разработку на многие годы, затратить

впустую массу средств и дискредитировать идею автоматизации в лице не только сотрудни-

ков библиотеки, но и её пользователей!

Причины и последствия этого «феномена» хорошо известны в мировой и отечественной

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

пать к разработке, рекомендуем (как минимум!) обратиться к монографии Г.Р. Громова [1], её

разделам: “Школа относительной тяжести ошибок по фазам проекта” и “Макет прикладной

программы”. К этому следует лишь добавить, что отрицательные последствия будут тем серь-

езнее, чем ниже профессиональная готовность «конечных пользователей» (в нашем случае —

работников библиотеки и/или информационного органа) выступать в роли постановщиков за-

дачи на проектирование системы. Степень их «компьютерной грамотности» далеко не исчер-

пывает требования к профессиональным постановщикам задач на создание ПО. Не лучше и

другой путь: воспитать постановщиков задачи автоматизации библиотеки из программистов,

не владеющих библиотечными и информационными технологиями. Причины этого также хо-

рошо известны. Некоторые из них — в различии понимания «своих» и «чужих» профессио-

нальных задач или проблем и отношения к ним [2, 3].

С учётом сказанного мы рекомендуем при проектировании АБИС не разрабатывать её

программное обеспечение, а выбирать уже готовое из имеющихся в стране промышленных

разработок, которые хорошо зарекомендовали себя в течение достаточно длительного пе-

риода эксплуатации во многих библиотеках и информационных органах России (см., в частно-

сти [3, 4]). Последнее, однако, не означает, что конкретным объектам автоматизации не может

потребоваться создание отдельных дополнительных программных модулей. Поэтому в рам-

ках данной главы мы рассмотрим также вопросы их создания на уровне разработки ТЗ на со-

ответствующее программное обеспечение.

Возвращаясь к вопросу о выборе ПО для создания АБИС, следует выразить наше отно-

шение к трём ситуациям, достаточно часто встречающимся, на пути лиц, принимающих от-

ветственные решения.

1. Каждый разработчик ПО АБИС считает свой программный продукт самым лучшим и

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

процесс представления своих разработок часто сопровождается некорректными высказыва-

ниями в адрес программных продуктов конкурентов. В условиях рыночной экономики подоб-

ная позиция владельцев ПП с определёнными допущениями может быть понятна. Она к тому

же усиливается следующим:

• сами разработчики ПО АБИС, как правило, не пользуются собственными ПП для реше-

ния своих производственных задач и поэтому в ряде их практических приложений не в

состоянии относится к ним объективно;

136

• разработчики весьма поверхностно ознакомлены с возможностями и характеристиками

альтернативных средств ПО АБИС.

В указанных условиях может вызывать лишь сожаление тот факт, что очень многие руко-

водители принимают решение о выборе того или иного ПО АБИС только на основании сведе-

ний, полученных от его разработчика.

2. Неоднократно делались попытки, которые впрочем продолжаются и в настоящее вре-

мя, объявить ту или иную разработку ПО АБИС «самой лучшей». Некорректность такого под-

хода определяется следующими обстоятельствами:

• не существует «универсальных» прикладных программных продуктов – те из них, кото-

рые могут быть наиболее приемлемыми для внедрения в одни системы, могут оказать-

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

рактере объектов автоматизации и их возможностей (в том числе чисто экономических)

эксплуатировать, поддерживать и модернизировать эти средства;

• часто ранжирование версий ПО АБИС по их «качеству» производится людьми, проте-

жирующими конкретных разработчиков и их ПП.

Поэтому, возвращаясь к выбору АБИС на основе кем-то установленной оценки «лучшей

системы», рекомендуем их потенциальным пользователям быть очень осторожными. Что ка-

сается собственно ранжирования разработок и придания им статусов «лучшей» или «одной из

лучших», то оно, если и должно проводиться, то очень осторожно и тщательно аргументиро-

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

только оценка АБИС для признания их пригодности к эксплуатации и при том — без привеши-

вания ярлыков!

Бесперспективность безотносительной к условиям использования ПО АБИС его ка-

чественной оценки очевидна (подробнее об этом см. [2, 3]).

3. На отечественном рынке ПП для АБИС с той или иной степенью активности работают

зарубежные фирмы, при этом обращает на себя внимание их

наступательная политика,

которая

чётко проявляется в следующих тактических приемах:

• предоставление инвестиций через поддерживающие эти фирмы международные благот-

ворительные и им подобные фонды организациям, которые изъявили согласие приобре-

сти их продукцию

28)

;

• гибкое маневрирование условиями поставки и ценообразования;

• активная пропаганда своих разработок в среде потенциальных пользователей ПО и

должностных лиц, которые определяют возможность размещения заказов;

• предоставление различного рода услуг, в том числе оплачиваемых разовых зарубежных

поездок руководителей, принявших желательное для фирмы решение и т.п.

Анализируя имеющиеся публикации и выступления на совещаниях и конференциях специа-

листов, связанных с эксплуатацией зарубежных АБИС в России, можно отметить следующее:

a) Высокое качество разработок ПО АИБС зарубежных фирм не вызывает сомнения и при-

менительно к их использованию в условиях западных библиотек может считаться доста-

точно эффективным. Однако они не только не ориентированы на отечественную техно-

логию библиотечной деятельности, но многие предоставляемые ими преимущества ос-

танутся не востребованными на весь период жизненного цикла существующей версии

ПО. Это - объективная реальность, обусловленная нехваткой финансирования библио-

тек и отсутствием высококвалифицированных и, соответственно, высокооплачиваемых

кадров.

b) С учётом сказанного выше ни одна из зарубежных разработок ПО АБИС, внедренных в Рос-

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

результате в библиотеках для подготовки ряда обязательных для них форм документов

и обеспечения соответствующих функций (комплектование, ведение отчетно-

бухгалтерской документации и т.п.) сотрудники вынуждены повторно производить необ-

ходимые записи и операции вручную или использовать другие средства, в том числе

машинопись. Практически все ППП АБИС зарубежного производства нуждаются помимо

руссификации интерфейса в выполнении доработок, связанных с настройкой на входные

)

Известны примеры, когда предоставление инвестиций ставится в зависимость от усло-

вия приобретения зарубежных ПП.

137

и выходные формы документов, требуемых российскими стандартами и нормативными

документами. Сказанное также относится к составу и структуре полей данных, необхо-

димости сопряжения с другими программными средствами и средами, используемыми в

России. В частности, последнее относится к выполнению требований Российского, а в

ряде случаев и международных коммуникативных форматов предоставления библио-

графической информации (RUSMARC, UNIMARC, MARC 21 соответственно).

с) Ряд библиотек, которые некоторое время назад сделали ставку на зарубежные ПП и затем

вложили в их адаптацию значительные средства, в настоящее время существенно отстают

в вопросах автоматизации своей технологии. Это связано с тем, что, в дополнение к уже

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

ленные фирмой, передавшей систему, либо не имели средств для завершения работ по

адаптации и внедрению системы, либо не имели этих средств для перехода на новые вер-

сии ПО. В результате эти библиотеки «потеряли темп» и вынуждены во многом начинать

работу заново, переходя на другое программное обеспечение. К сожалению, у многих из

таких библиотек возникают или могут возникнуть проблемы с сохранением наработанных

информационных ресурсов и в первую очередь – электронных каталогов. Последнее, в ча-

стности, означает, что со сменой ПО эти библиотеки рискуют снова оказаться на самой на-

чальной стадии своей автоматизации.

Любой руководитель, принявший решение о переводе библиотеки на автоматизированный

режим работы, должен отдавать себе отчет, что, наряду с первоначальными затратами, связан-

ными с приобретением «базовой» версии ПО АБИС (будь то отечественный или зарубежный

продукт), потребуются ежегодные затраты на поддержку системы и ее развитие.

Поскольку каждая система в процессе своей эксплуатации постоянно видоизменяется

(появляется необходимость решения новых задач, предоставления новых видов сервиса, из-

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

онных систем и техники и т.д.), начальная предпродажная настройка системы поставщиком не

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

ция, которая приобрела ПО АБИС, попадает в жёсткую зависимость от поставщика и должна

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

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

затраты применительно к зарубежным системам несоизмеримо (как правило на несколько поряд-

ков) выше по сравнению с отечественными разработками. Очевидно также, что оплатить вызов

специалиста - консультанта из-за рубежа не по карману ни одной отечественной библиотеке, а

содержание центров поддержки ПО АБИС, укомплектованных зарубежными специалистами, по-

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

Что же касается привлечения российских специалистов для поддержки своих систем, то зару-

бежные фирмы идут на это весьма не охотно. Подробнее о проблемах, связанных с внедрением

зарубежных разработок ПО АБИС см. [2, 3, 5-7].

14.2. РЕКОМЕНДАЦИИ ПО ВЫБОРУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРОЕКТИРУЕМОЙ АБИС

Материалы данного раздела адресованы в первую очередь руководителям и персоналу

библиотек и информационных органов, являющихся потенциальными пользователями а, воз-

можно, и разработчиками создаваемой автоматизированной системы. Именно им придётся

испытывать на себе все позитивные и отрицательные результаты выбора ПО АБИС. Поэтому

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

емся непосредственно к «субъектам автоматизации».

Образно говоря, принцип выбора программного обеспечения автоматизированной систе-

мы, как и заключения брака “по любви с первого взгляда”, на основании только первых впе-

чатлений от привлекательности претендента(ки) и настойчивых доводов со стороны его (ее)

“родителей и родственников”, мы отвергли еще в самом начале обсуждения данной темы. Это

отнюдь не означает, что “можно и без любви…” или “стерпится — слюбится”! Мы видим свою

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

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

отношения.

Чтобы избежать этих неприятностей, придется детально знакомиться с наиболее вероят-

ными кандидатами в партнеры и их ближайшим окружением — разработчиками и (хотя бы

некоторыми!) близкими по виду деятельности Вашей организации библиотеками или служба-

ми, которые имеют опыт эксплуатации данного программного продукта.

138

Однако подобно любому здравомыслящему человеку, решившему вступить в законный

брак, не рассчитывайте и на полное соответствие будущего партнера вашим представлениям

об идеальном(ой) супруге. И как бы того ни хотелось, готовьтесь внести коррективы в свои

планы и преждевременно не слишком усердствуйте в их разработке (хотя бы до знакомства с

“объектом”!).

Другой вопрос — насколько соответствует (или не соответствует) тот или иной кандидат

вашим главным целям, возможностям и представлениям об их реализации. Чтобы определить

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

• коммуникативные свойства;

• соответствие функциональным задачам объекта автоматизации;

• адаптивность;

• эксплуатационные характеристики и стоимость;

• “доброжелательность и привлекательность”;

• “личность разработчика”.

Ниже остановимся на этих характеристиках подробнее.

14.2.1. Коммуникативные свойства

В процессе предпроектного обследования (см. Главу V) мы уже выяснили:

• от кого, какую и в каком виде мы должны или хотим получать информацию;

• кому, куда, какую и в каком виде мы должны или хотим передавать информацию;

• какими средствами обеспечения (в том числе программного, технического, информа-

ционного, лингвистического и т.д.) располагают наши реальные и потенциальные парт-

неры по информационным связям.

Признаками, которыми обеспечиваются коммуникативные свойства ПО АБИС яв-

ляются:

• собственно программная совместимость с указанными системами и используемыми

ими средствами приема и передачи данных;

• совместимость средств технического обеспечения;

• совместимость форматов данных, поддерживаемых программным обеспечением взаи-

модействующих систем и ПО создаваемой АБИС;

• совместимость поддерживаемых ПО лингвистических средств.

Наиболее полное и простое удовлетворение указанных требований достигается путем

прямого выбора такого же ПО, как у наиболее перспективных партнеров по информационному

взаимодействию, или его версии (например, отдельных программных модулей).

В более сложных случаях (например, трудно выявить приоритеты среди партнеров с раз-

нородными программными средствами или данное ПО не удовлетворяет другим критериям)

для выработки оптимального решения рекомендуем обратиться к помощи квалифицирован-

ных программистов.

Однако программная совместимость сама по себе не гарантирует коммуникабельных

свойств вашей системе, если останутся несогласованными структуры обрабатываемых в ней

данных (форматы) и словарные средства (лингвистика) с соответствующими средствами ре-

альных и потенциальных партнеров по информационному взаимодействию. Понимание важ-

ности данного факта порождает разработку и реализацию в системных решениях заинтересо-

ванных групп организаций, объединенных по разным признакам (видам деятельности и/или

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

лежности и т.п.), коммуникативных форматов и согласованных словарей. В качестве примера

можно привести меры, принимаемые по обеспечению информационной и лингвистической

совместимости в корпоративных библиотечных системах, например Москвы. В связи с по-

следним замечанием уместно отметить, что наибольшие трудности при обеспечении совмест-

ной работы участников корпоративных систем возникли в ходе конвертирования библиогра-

фических записей их электронных каталогов [8-10].

Противоречия и несогласованность, неизбежно возникающие в борьбе интересов различ-

ных организаций и их групп, при создании упомянутых средств должны сниматься в первую

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

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

совместимости взаимодействующих автоматизированных систем. В частности, стандарты вы-

139

сокого уровня не предусматривают (да и не могут предусматривать!) единых правил, связан-

ных, например, с составом специальных технологических полей и структурой их записи, тре-

буемых входных и выходных форм большинства видов документов и данных, используемых

видов статистической обработки данных и т.п. Поэтому при выборе ПО АБИС следует убе-

диться в возможности реализации его средствами настройки на указанные особенности парт-

нёров.

Решением проблем форматной совместимости создаваемых электронных каталогов часть

публичных библиотек Москвы начала заниматься ещё с 1994 г. Несмотря на то, что все участ-

ники этой работы использовали единый формат USMARC, поддерживаемый ПО АБИС

«МАРК» (разработчик НПО «ИНФОРМ-СИСТЕМА»), буквально с первых месяцев эксплуата-

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

коммуникативные свойства. С целью недопущения этого участниками инициативной группы

библиотек-пользователей данного программного продукта совместно с его разработчиком

были приняты организационные и технологические решения, согласующие интересы разных

библиотек и их групп. В результате был получен «USMARC-подобный» формат НПО «ИН-

ФОРМ-СИСТЕМА», который не противоречил оригинальному обменному формату USMARC и

удовлетворял пользователей данного ПО.

В 1999 г. при создании Корпоративной сети публичных библиотек Москвы (КСПБМ) в неё

вошли библиотечные системы, использующие разные программные платформы и форматы. К

ним помимо упомянутого выше «МАРК» относятся библиотеки-пользователи ПО Системы ав-

томатизации библиотек ИРБИС, ориентированный на работу в формате UNIMARC, и «Liber»,

имеющего свой внутренний формат, не согласованный ни с одним из международных комму-

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

держки нового формата RUSMARC, который по существу является версией международного

коммуникативного формата UNIMARC. Всё вышеизложенное вызвало потребность разработки

как в Москве, так и других регионах России, ряда конверторов, обеспечивающих преобразова-

ние записей в координатах форматов UNIMARC↔RUSMARC↔USMARC

В плане рассматриваемой здесь проблемы важно отметить, что несмотря на «родствен-

ные» корни MARC-подобных форматов, обеспечить стопроцентно корректное взаимное кон-

вертирование из USMARC в UNIMARC и обратно пока не удалось. Наибольшие проблемы при

этом возникли с конвертированием в коммуникативные форматы библиографических записей,

выполненных в библиотеках, использующих ПО «Liber». И если проблемы взаимного конвер-

тирования БЗ, выполненных в одном из упомянутых выше коммуникативных форматов, техни-

чески преодолимы, то для «Liber» оснований для оптимизма нет.

Что означает описанная выше ситуация для библиотеки, выбирающей тот или иной вид

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

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

случае и другую не менее важную задачу. Речь идёт о создании условий сохранения нарабо-

танных информационных ресурсов в случае возникновения необходимости смены ПО своей

АБИС. Известно, что потеря этих ресурсов и в первую очередь электронных каталогов практи-

чески означает возвращение на начальный уровень автоматизации всех библиотечно-инфор-

мационных процессов. Восстановление тех же электронных каталогов — процесс весьма дли-

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

навшие через несколько лет эксплуатации непригодность выбранного ранее ПО своей АБИС,

вынуждены мучительно решать для себя дилемму: перейти ли на более пригодный вид ПО и

остаться без электронного каталога или продолжать работать на старом ПО, оставаясь его

заложником.

14.2.2. Соответствие ПО функциональным задачам объекта автоматизации

Соответствие разрабатываемой системы и средств ее программного обеспечения функ-

циональным задачам библиотеки и/или информационной службы (см. Главу IV) является цен-

тральным требованием, охватывающим и рассмотренный выше вопрос обеспечения коммуни-

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

кладывать новые проектные решения на сложившуюся в условиях старой или “традиционной”

технологии организационную структуру и соответствующие ей функции подразделений. Такой

C 2000 г. формат USMARC заменён форматом MARC 21.

140

подход, если и может быть признан приемлемым, то лишь как временная мера и только на

переходный период к полномасштабному внедрению средств автоматизации.

Считая сделанное предупреждение достаточно важным, скажем, что организационная

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

средствами, призванными обеспечить оптимальное выполнение главных задач всего объекта

автоматизации. При этом должны быть учтены особенности обслуживаемых субъектов, их

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

связанные с решением этих задач при использовании той или иной информационной техноло-

гии. Понятно поэтому, что не только сам факт внедрения новых программных средств, но и их

характер будет существенным образом влиять на новую организационную структуру объекта

автоматизации, распределение функций его подразделений и/или рабочих групп. Грубо гово-

ря: какую систему выберешь, такую организацию и получишь!.

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

мационной службы, определяющие основные требования к АБИС и её программному обеспе-

чению, условно можно отнести либо к группе «сервисных» (ориентированных непосредствен-

но на обслуживание читателей и других внешних пользователей системы), либо к «служеб-

ным» или внутрисистемным, являющимся средствами поддержки реализации «сервисных»

задач.

Ведущее значение сервисных задач при выборе средств ПО системы связано с тем,

что они определяют:

• видовой, тематический и количественный состав документов и данных, необходимых

для удовлетворения запросов пользователей (в том числе читателей);

• необходимые виды обработки, переработки, хранения, поиска, сортировки и формы

выдачи документов и данных пользователям, а также связанные с ними количествен-

ные показатели;

• состав сведений о пользователях, необходимый для поддержания эффективности

работы библиотеки или информационной службы, способы сбора и обработки этих

данных, их актуализации, переработки, сортировки и выдачи;

• требования к программно-технологическому комплексу системы в части обеспечения

оперативности получения и выполнения заказов (запросов) на литературу, другую

информационную продукцию и услуги;

• требования к средствам обеспечения защиты документов и данных от несанкциони-

рованного доступа и разрушения;

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

ванием фондов, обработкой и хранением документов и данных, управлением библио-

текой или информационной службой и т.п., а также требования к условиям их реали-

зации.

В детализированном виде указанные сведения составляют основу технического задания

или тендера как на автоматизацию системы в целом, так и отдельных ее звеньев, узлов и/или

рабочих мест

. Сказанное в полной мере относится и к средствам ПО АБИС. И только де-

тальное сопоставление ТЗ с реальными возможностями, предоставляемыми анализируемым

программным продуктом и поддерживаемыми или совместимыми с ним средствами формат-

ного, лингвистического и технического обеспечения, позволяет определить степень его соот-

ветствия или несоответствия поставленным задачам автоматизации вашей организации или

службы.

14.2.3. Адаптивность

Как уже указывалось ранее, под «адаптивностью» мы понимаем способность системы и

средств, поддерживающих её работу (в рассматриваемом случае — программных), видоизме-

няться или перенастраиваться в соответствии с изменением условий эксплуатации.

Рассматриваемое свойство средств ПО нас интересует по крайней мере в двух ас-

пектах:

1. Насколько полно анализируемое ПО можно изначально «настроить» на состав и

структуру данных (внутренний и коммуникативные форматы), словари (лингвистиче-

Примеры составления ТЗ и тендера на систему см. в Приложениях 1 и 2.