Думаю никого не стоит убеждать в необходимости организации архивного хранения информации. Постараемся более подробно осветить все аспекты.
Условно решение проблемы хранения информации можно разделить на следующие составляющие:
- Выбор носителя информации. Не будем подробно останавливаться на перечислении возможных вариантов. Их список велик: от глиняных табличек и зарубок на деревьях до применения современных информационных технологий, например, высокотехнологичных архивных накопителей;
- Организация условий хранения. Эта составляющая проблемы тесно связана с предыдущей и может быть реализована по-разному. Например, далекие предки пришли к тому, что надписи на скале лучше делать в пещере, чтобы их не смыл дождь. Ценные бумажные носители лучше хранятся при использовании соответствующего оборудования и системы создания микроклимата. Информацию в электронном виде целесообразно хранить опять же в соответствующих условиях, исключающих потери;
Организация доступа к информации и системы поиска. В разные времена существовали разные решения (поиск свитка в архиве по принципам, известным лишь одному хранителю, поиск по учетной книге или карточке — по автору, названию, теме, полке, шкафу и т. д.). Поскольку темой материала является создание электронных архивов, в основной части описывается поиск информации при использовании СУБД. Остановимся на этом вопросе подробнее. Число "единиц" хранения электронного архива может достигать сотен тысяч и даже миллионов. Для быстрого поиска обновления и удаления информации, современные СУБД используют универсальное средство — структурированный язык запросов — SQL. Причем операторы этого языка практически одинаковы для разных СУБД. Приведу простой пример, иллюстрирующий эффективность применения систем управления базами данных. Сервер Interbase, MsSQL или Oracle получает запрос следующего содержания: SELECT * FROM documents Where Doc_Name like '%статья%'. Переведем текст запроса на "общедоступный" язык и получим: "Выбрать из таблицы documents (таблица хранит записи о документах) все записи, имеющие в столбце Doc_Name (название документа) ключевое значение "статья". В процессе обработки запроса сервер выберет из миллионов документов только статьи и "отправит" результаты запроса клиентскому приложению, установленному, например, на рабочем месте системы архива. Конечно, время обработки запроса зависит от производительности конкретной СУБД, числа записей и ещё множества факторов. В любом случае оно крайне мало по отношению ко времени, которое пришлось бы затратить человеку на поиск всех статей среди огромного числа документов, хранящихся, например, на файловом сервере (без "помощи" СУБД)! Запросы формируются через интерфейс клиентского места системы архива и документооборота, например. Конечно, для формирования запросов пользователь не должен знать операторов SQL, он применяет "более привычные" элементы интерфейса — кнопки, поля, "выдвижные списки" запросных форм. В приведенном примере описан достаточно простой запрос. На самом деле SQL позволяет формировать запросы любой сложности. Кроме того, в перечисленных выше СУБД используются триггеры и хранимые процедуры, которые выполняют различные действия непосредственно на сервере, повышая производительность системы в целом. Например, триггеры "отвечают" за целостность данных (на преимуществах архитектуры клиент — сервер остановимся немного ниже). При создании системы электронного архива важно решить следующие задачи по доступности и разграничению доступа к информации:
- Необходимо, чтобы информация была доступна, её всегда можно было быстро найти и использовать. Иначе может произойти "утеря" полезных знаний и переход, говоря словами В. Высоцкого, в стадию "...дряхлость в архивах пылится..." в лучшем случае. В худшем же случае, возможен переход информации в стадию "глиняных табличек", содержащих необходимые знания и законы, которые из-за их "утери" приходилось "снова открывать";
- Необходимо, чтобы при доступности был реализован механизм ограничения доступа к хранимой информации, согласно правам пользователей. Неправильное разграничение прав доступа к информации может привести к убыткам и потерям для Вашего бизнеса. Например, древний жрец или шаман допускал к своим знаниям только учеников. Если так можно выразиться, он "защищал свой бизнес".
Дело в том, что данный материал посвящен больше хранению информации предприятия, в том числе и бизнес — информации. Оговоримся сразу, под "бизнес — информацией" в статье подразумевается не только информация о финансовых и материальных потоках предприятия, ограниченная складской, бухгалтерской документацией, коммерческими предложениями, договорами.
Если даже Ваше предприятие занимается лишь торгово-закупочной деятельностью, все равно всегда присутствует некая информация, которая прямо или косвенно влияет на успех бизнеса, но не относится к перечисленным категориям. Если же Вы занимаетесь разработкой, обслуживанием, производством, ремонтом чего-либо, то Вашей основной ценностью может являться технологическая, техническая, инженерная, проектная информация.
Ценность именно такой информации наиболее высока. В качестве примера можно привести строительство серии кораблей для ВМС Индии и Китая на судостроительных предприятиях. При этом "самая ценная" информация, связанная с этими контрактами, содержится как раз не в счетах-фактурах и "платежках", а в технологической, проектной, инженерно-конструкторской документации;
- Организация учета хранимой информации. Думаю не стоит приводить подробные причины необходимости этого пункта. Стоит лишь указать, что правильный учет облегчает доступность, поиск необходимой информации и исключает её "потери";
- Организация пополнения информации. Способы пополнения напрямую зависят от реализации всех вышеперечисленных пунктов;
- Создание единой "архивной" системы, объединяющей все вышеперечисленные пункты. Система должна позволять не только использовать всю информацию в режиме "просмотра" (чтения, изучения), "пополнения" и "редактирования". Важной задачей является разработка новых знаний на основе полученных в системе, их регистрация. Забегая немного вперед, приведу пример: в системе электронного архива может быть быстро найден необходимый документ, создана его новая версия. Это делается для того, чтобы не "портить", например, ранее разработанный офисный, бухгалтерский документ, договор, чертеж и т. д. В новую версию вносятся необходимые изменения. В договоре, например, меняется сумма и название организации, а в чертеж модернизированного изделия вносится новый элемент. После регистрации новой версии уже все перечисленные действия системы (хранение, учет, поиск, доступ и т. д.) применимы и к новому документу.
Рассмотрим основные способы хранения информации, которые применяются в наше время, не затрагивая пока систем электронного архива.
Способ хранения информации в бумажном виде — самый распространенный. Причина этого, прежде всего, в том, что из всех описываемых способов он "самый старый". Глупо было бы описывать то, что всем знакомо с детства. Просто перечислим преимущества и недостатки. Основным преимуществом является "наглядность и привычность". Действительно, никто не станет возражать, что работать с книгой или листом бумаги удобно. Отсутствует всякое дополнительное оборудование между Вами и носителем информации. Все воспринимают Ваши зрение и мозг. Для "корректировки" бумаги достаточно лишь наличие карандаша или ручки.
Недостатки же данного способа заключаются в большом физическом объеме архива. Бумага имеет свойства выцветать, протираться от многократных прикосновений, рваться. Информация на поврежденных бумажных носителях может быть частично или полностью утеряна. Учет информации бумажного архива при помощи книг или карточек тоже довольно громоздок, не говоря о поиске необходимой книги, документа. Довольно громоздким является процесс извлечения наконец-то найденного из шкафов и полок. Тиражировать информацию бумажных носителей достаточно неудобно.
С перечисленными недостатками существуют определенные "способы борьбы". Для уменьшения объема бумажных масс, например, успешно применяются стеллажи специальной конструкции, перемещающиеся на рельсах. В "сложенном виде" такой стеллаж занимает гораздо меньший объем (за счет отсутствия проходов между полками).
Для хранения особо ценной информации на бумаге можно создать систему микроклимата.
Для тиражирования документации бумажных носителей применяют копировальные аппараты. Пионером в их разработке и производстве является небезызвестная фирма Xerox, благодаря которой и возник термин "ксерокопия". Для копирования сшитых документов, книг достаточно эффективно применение копиров Minolta. При копировании "с бумаги на бумагу" объем "бумажных масс" растет. При всем уважении к данной технологии, отметим: если качество подлинника низкое и часть информации уже потеряна, то на копии это повторится. Улучшение качества таких копий без использования информационных технологий невозможно.
Сделать более удобным учет "на бумаге", упростить процесс быстрого доступа к информации, создать эффективную систему тиражирования (копирования) с возможностью повышения качества и даже восстановления информации (в пределах разумного) уже невозможно.
Микрофильм имеет ряд преимуществ перед традиционным "бумажным" носителем. Применение микрофильмирования позволяет иметь значительно меньший "физический" объем носителя. В "шпионских" фильмах 50-х — 60-х годов часто одним из трюков сюжета являлась передача злодеями микропленки, несущей объемную и важную информацию. Действительно, в те годы кибернетика в Советских энциклопедических изданиях трактовалась как "лженаука". Более "компактного" носителя информации, чем микрофильм не существовало. Технология микрофильмирования получила серьезное развитие.
Основным преимуществом технологии микрофильмирования по сравнению с хранением информации на бумаге, является снижение "физического" объема архива. Для просмотра и тиражирования микрофильмов требуется специальное оборудование. Далеко не всегда целесообразно оборудовать рабочее место пользователя архива ставшим привычным компьютером и, например, устройством для просмотра микрофильмов. Как выяснилось, микрофильмы подвержены "уксусному синдрому". Такое название получили необратимые химические процессы, происходящие в настоящее время с микрофильмами 60-х годов. Эти процессы ведут к частичной или полной потере информации. Название "синдрома" произошло от запаха уксуса, сопровождающего процесс разложения материала.
Прочими недостатками микрофильмирования является, опять же, отсутствие системы быстрого поиска и быстрого тиражирования информации. Система учета архива на микрофильмах мало чем отличается от системы учета "бумажного" архива. Предпринимались и предпринимаются попытки "борьбы" с этими недостатками. Все они ведут, опять же, к использованию информационных технологий и к созданию систем электронного архива. Например, целесообразнее организовать систему учета с использованием СУБД, а подверженные необратимым процессам микрофильмы не "переснимать", а переводить в электронный вид специальными сканерами. Далее можно осуществлять необходимую работу по восстановлению информации на электронных изображениях. Появляется возможность разграничения по правам пользователей, внесения изменений в создаваемые версии документов и их быстрого тиражирования.
Бурное развитие информационных технологий способствует автоматизации практически всех сфер человеческой деятельности. Разработка новых знаний стала более эффективной и "быстрой". Никто не станет отрицать, что создать "офисный" документ проще и удобнее в соответствующем приложении пакета MS Office. Сложные инженерные и проектно — конструкторские данные удобно создавать не при помощи карандаша и кульмана, а при использовании соответствующих "двухмерных" или 3D — средств. Финансовое и бизнес — планирование, экономические и бухгалтерские расчеты быстро и надежно производятся при помощи соответствующих программ.
Но так ли все "хорошо и безоблачно"? Рассмотрим "обратную сторону медали". Доступность и скорость разработки новых документов при помощи электронных средств приводят к росту их электронного "объема" и количества. Представим, что механизмы поиска, учета, хранения, управления разработкой отсутствуют. В этом случае дальнейшее внедрение информационных технологий на Вашем предприятии может перестать приносить экономический эффект. Начиная с определенного времени, наоборот, эффективность процессов может снижаться. Говоря проще, можно быстро "захлебнуться" в информационных потоках, потерять управление ими.
Другой проблемой, с которой приходится сталкиваться на любом предприятии, является наличие большого количества информации на "традиционных" бумажных носителях. Единое информационное пространство невозможно без включения в него такой информации.
Конечно, можно, используя имеющиеся средства разработки электронных документов, "переиздать" бумажный архив. Этот способ далеко не лучший, т. к. связан с достаточно большими затратами рабочего времени и средств. Сколько сил, времени и средств необходимо для "перепечатывания" всей административной документации предприятия за последние десять лет, например, в текстовом редакторе MS Word? А сколько для "перечерчивания" всей инженерной документации по изделиям судостроительной верфи за такой же период при помощи, например, AutoCAD? Может быть "махнуть на все рукой" и отказаться от использования таких документов? Это невозможно, поскольку информация, содержащаяся в них, используется в настоящее время и является "базовой" для создания новых документов.
Решение проблемы использования информации "бумажных" носителей, а также микрофильмов в электронном виде существует. Наиболее оптимальным является их быстрый перевод в электронный вид. Для этого существует различное сканирующее оборудование: от обычного планшетного сканера до промышленного сканера, позволяющего, например, сканировать до 180 страниц/минуту.
Как правило, "на выходе" сканера создается информация в графических электронных форматах. В любом случае такую информацию можно включать в систему электронного архива. При необходимости перед включением полученных электронных документов в систему архива возможна их обработка, например, распознавание. Способы обработки зависят от дальнейшего использования. Если, например, Вы вдруг решите, что просто необходим полнотекстовый поиск "внутри" отсканированного документа, то его придется "распознать", то есть перевести из графического формата в текстовый. Если же Вам достаточно быстро найти сам документ для вывода на экран компьютера или принтер, то лучше оставить его в графическом формате.
В этом месте изложения материала стоит остановиться на достаточно ошибочном мнении об "огромных размерах" файлов в графических форматах и "неприменимости" их использования для хранения информации в электронном виде.
Рассмотрим требования, выдвигаемые при сканировании, например, произведения искусства (картины, фолианта, гравюры). В этом случае важным требованием является полнота цветопередачи. Действительно, цвета красок картины являются одной из основных "информационных" составляющих, которая определяет восприятие. Для качественной цветопередачи неприменимо использование алгоритмов сжатия. Необходима передача информации о цвете каждой точки полотна. Действительно, размер такого файла огромен. Автору приходилось работать со сканирующим оборудованием, "на выходе" которого "получался" файл размером до 1 Гигабайта! Такой файл несет полную информацию о цвете. Но чаще можно использовать, так называемые, алгоритмы сжатия (компрессии). Не будем углубляться в их механизмы, но приведем пример: размер файла можно "уменьшить" неограниченно, если не записывать в него данные о цвете каждой точки изображения, а, "переведя с машинного на человеческий язык", сказать, например, так: "Эта точка и следующие за ней 10000 точек красные".
Когда же мы говорим об использовании отсканированных документов в электронном архиве предприятия, в большинстве случаев цвет не является существенным фактором. Основную информацию документа, как правило, несут не цвета, а тексты, линии и т. д. Все эти элементы изображения могут быть и черно-белыми. В случае использования алгоритмов сжатия для черно-белых монохромных файлов, их размер может быть еще меньшим, чем размер компрессированного "серого" или "цветного". Действительно, при записи информации о цвете в монохромном файле существует лишь 2 варианта цвета. В двоичной же системе исчисления для записи о двух цветах достаточно применение 1 bit.
Например, если Вы распечатаете страницу, созданную в текстовом редакторе Word, отсканируете её, получите сжатый файл формата TIFF G4 Monochrome и сравните с файлом исходного документа формата DOC, то большой "разницы" в размере этих файлов Вы не обнаружите.
При решении вопроса создания архивных систем во все времена приходилось решать проблему физического объема носителей. Например, уменьшалась толщина, формат бумаги, размер шрифта. Бумажные носители прошли длительный путь эволюции. Текст увесистого древнего фолианта, оказалось, можно "уместить" в достаточно "тонком" журнале. Причем "информативность" такого носителя ничуть не уменьшается.
Текст книги или журнала впоследствии удавалось разместить на гораздо меньшем по физическому размеру микрофильме, опять же, без нанесения ущерба "информативности". Но всему есть предел. Например, невозможно неограниченно уменьшать размер шрифта или толщину бумаги.
При переходе на электронное хранение опять же наблюдается ряд "ступеней эволюции". Например, для уменьшения объема файлов графического изображения возможно применение алгоритмов сжатия. Постоянно велись и ведутся разработки в области физического "уменьшения" размеров самого носителя. Например, еще 10 лет назад жесткий диск объемом в 20 Gb считался фантастикой, а сегодня такой объем уже "староват". Объем информации предприятия, даже при использовании всех "ухищрений", направленных на его уменьшение (не в ущерб "информативности"), может исчисляться в терабайтах. При таких объемах использование "привычных" жестких дисков нецелесообразно. В связи с этим разрабатывались новые технологии хранения данных и устройства: ленточные, магнитооптические, CD, DVD. Например, современная DVD-RAM роботизированная библиотека образует "большой сетевой диск" размером до 6 терабайт.
Какой тип носителя электронной информации наиболее приемлем в Вашем случае? Все зависит от ряда факторов. Методика определения целесообразности той или иной технологии, типа носителя, устройства хранения описывается в основной части материала.
В процессе накопления информации всегда приходилось решать проблемы её совместного использования, разграничения прав доступа к различным разделам. В "бумажном" архиве эти проблемы решались лишь организационными мерами. Решение вопросов совместного использования, разграничения прав доступа к разделам "электронной" информации осуществляется средствами администрирования операционной системы сервера сети. Действительно, для Вашего системного администратора нет ничего проще, чем создать каталог на жестком диске сервера и указать, кому из пользователей можно просматривать и редактировать его содержимое, кому лишь просматривать, а кому вообще данный каталог недоступен.
Реализовать возможность групповой работы с архивом, используя лишь сетевые средства, недостаточно. Для решения проблем учета информации, разграничения прав доступа, быстрого поиска, доступа, регистрации новой информации, обеспечения управления процессами разработки новых данных в системах электронных архивов широко используются системы управления базами данных — СУБД. Опять же не будем подробно останавливаться на их описании, истории и эволюции развития.
Большинство современных СУБД имеют все необходимые для работы в системе электронного архива механизмы и свойства. В зависимости от решаемых задач возможно использование таких средств, как Oracle, MsSQL, MySQL, Interbase, Paradox и даже MsAccess. Перечень далеко не полный. Все СУБД объединяет то, что они представляют, по сути, наборы связанных таблиц. Таблицы состоят из вертикальных колонок — "полей", "столбцов" и горизонтальных — "записей". В каждую ячейку таблицы можно производить запись данных в том или ином формате. Формат зависит от указанного формата ячейки. Например, можно записать набор символов, слово или целый документ в электронном виде, а некоторые СУБД, например, Oracle, позволяют записывать в одну ячейку не только документ, но и целую таблицу, содержащую, в свою очередь, записи. Главное свойство таблиц СУБД — возможность быстрого поиска информации при использовании языка запросов. Изложение реляционной теории баз данных не входит в рамки материала, но именно перечисленные свойства СУБД являются основными и необходимыми для учета, разграничения прав доступа, быстрого поиска, доступа, регистрации новой информации, обеспечения управления процессами разработки новых данных.
Кроме того, могут использоваться файл — серверные и клиент — серверные решения. В первом случае, например, при использовании файл — серверной СУБД Paradox производительность системы относительно невелика, сеть "более загружена". Все вычисления, как правило, ведет "клиентская" программа. Во втором случае, например, при использовании СУБД Oracle, MsSQL, Interbase клиентская программа только формирует запрос и отображает результат "ответа" от сервера. Всю обработку производит сервер. Производительность системы гораздо выше. С другой стороны, невысоки требования к "клиентскому" ПО (программе, через которую происходит Ваше "общение" с базой). Кроме того, такие СУБД, как, например, Oracle и MsSQL имеют дополнительные средства снятия нагрузки с клиентских машин — выполняемые на сервере хранимые процедуры и триггеры. Самым идеальным случаем является использование привычного WEB-навигатора, например, Internet Explorer (IE), когда работа с электронным архивом напоминает работу с Internet — сайтом! В этом случае на рабочем месте системы архива не требуется установки дополнительного ПО. Достаточно лишь знать адрес в Internet или интрасети, имя пользователя и пароль для работы в системе электронного архива. Пользователь подключается по этому адресу к WEB-серверу. Через интерфейс WEB — страниц, отображаемых, например, в IE производится формирование запросов (используются элементы запросных форм). WEB — сервер, получив запрос, автоматически "отправляет" его через соответствующий интерфейс взаимодействия с СУБД. Например, для взаимодействия IIS с MsSQL используется ODBC. Взаимодействие между "не Microsoft — овскими" WEB серверами и СУБД осуществляется другими способами, но логика работы системы остается такой же. Получив через соответствующий интерфейс запрос от WEB — сервера, сервер СУБД формирует ответ, отправляя его "назад". В конце концов, результат ответа сервера СУБД, преобразованный в "понимаемый" WEB — навигатором формат, отправляется на клиентскую машину (проще, в окне IE отображается WEB — страница, содержащая результат запроса). Существует несколько технологий взаимодействия WEB — сервера с сервером СУБД (IDC, PHP, ASP и т. д.), их подробное описание не входит в рамки статьи. Все эти технологии объединяет, прежде всего, возможность работы как в локальной сети, так и через Internet, простота использования клиентских частей (WEB — навигатор), минимальные загруженность клиентских машин и требования к их ресурсам.
Какие же СУБД предпочтительнее использовать в Вашей системе электронного архива? Все зависит от реально стоящих задач. Например, если создаваемой системой пользуются несколько человек, объем информации — несколько мегабайт, а число "единиц хранения" — несколько сотен, то возможно даже эффективное использование MS Access. Если же Ваш архив имеет объем в несколько терабайт, миллионы записей, сотни пользователей, причем часть из них расположена за пределами Вашего предприятия, а возможно и страны, то Вам, скорее всего, лучше использовать Oracle или MSSQL и обратиться к WEB — технологиям.
При современном развитии производственных и технологических процессов в России, бессмысленно говорить о полностью "безбумажной" технологии. Например, в наших стандартах пока отсутствует четкое понятие "модель". Современные же средства проектирования позволяют создать трехмерную модель изделия. Данная модель не только представляет собой трехмерное изображение объекта, но и позволяет получать сечения в различных плоскостях с высокой точностью, получить любой чертеж. По сути, такая модель является полным источником информации об изделии. К сожалению, на момент написания статьи, ни один стандарт в нашей стране не говорит, что комплект документации об изделии может являться такой моделью (хотя, так оно и есть). Сложно судить о причинах, но факт остается фактом. Даже при высокой степени автоматизации производства, когда применяются станки с ЧПУ, работающие с трехмерной моделью (станок не читает бумаг!), все равно основные документы на изделие — спецификация и чертеж.
В случае же более низкой степени автоматизации, говорить о полностью "безбумажной" технологии вообще бессмысленно, т. к., например, сборщику судовых корпусов нужен чертеж и технология на бумаге. Поэтому и существует необходимость иметь в системе электронного архива модуль тиражирования документов.
Приведу другой пример. Один из музеев в свое время принял революционное решение. Суть его заключалась в переходе на электронную форму учета экспонатов. В принципе, любой человек, интересующийся информационными технологиями, не найдет в этом ничего "революционного". Итак, была создана несложная поисковая система на основе файл-серверной СУБД. Система хранила записи об экспонатах, повторяя, по сути, карточки учетного каталога в электронном виде. Учетным каталогом на бумажных карточках вскоре прекратили заниматься, а потом большую часть уничтожили (в этом-то и была "революционность"). Электронная система учета в один прекрасный день просто перестала существовать по техническим причинам. Резервных копий не делалось, бумажных документов не было...
"Стоп!", — скажете Вы, — "человек говорит об электронных архивах и приводит примеры, опровергающие его же слова о пользе таких решений!". Позволю себе пояснить, создание любых решений должно производиться обдумано, с учетом окружающей реальности — пока сборщиком судовых корпусов используется бумага и пока в приведенном музее не способны создать нормальную систему резервного копирования говорить о "полностью безбумажной" технологии работы с информацией рано.
Рассмотрим способы создания электронных архивов. Все они имеют право на существование и ни один нельзя назвать "единственно правильным". Все определяет конкретно стоящая задача по использованию информации, множество факторов, и, наконец, "цена вопроса". Способы перечислены согласно их "эволюции", но ни один из них нельзя назвать "тупиковой ветвью".
Этот способ заключается в том, что организуется хранилище (хранилища) для документов, либо сразу создаваемых в электронном виде, либо переводимых в электронный вид, например, из "бумажного" архива или архива микрофильмов при сканировании. Хранилищем является любой локальный или сетевой диск либо более "объемное" устройство, например, магнитооптическая или DVD — библиотека.
Для упрощения поиска необходимого документа информация "внутри хранилища" структурируется по вложенным каталогам, названия которых говорят пользователю о содержащихся в них документах. Права доступа к разделам информации определяются при администрировании разделов устройства хранения.
Основным преимуществом такого способа, пожалуй, является достаточная простота реализации и обслуживания. Возможно такой способ целесообразен при "начальной стадии" накопления информации в электронном виде.
При увеличении числа "единиц хранения" подобного архива рано или поздно наступит момент, когда число вложенных папок тоже придется увеличивать для удобства поиска. Далее, число вложенных папок и степень вложенности могут стать очень большими, и поиск необходимого документа станет долгим и превратится в проблему.
Приведем пример, иллюстрирующий работу при таком способе создания системы электронного архива. Представьте, что Вы пришли в библиотеку, а там ввели режим самообслуживания. Вам предоставляется возможность самому найти и взять необходимую книгу. Только вот никакого, хотя бы традиционного карточного каталога в библиотеке нет! Вы знаете, что необходимая литература присутствует, поэтому, расталкивая таких же несчастных читателей, ищете литературу на стеллажах. Иногда Вам кажется, что цель близка, поскольку существует некая логика — стеллажи имеют свои названия, да и по тематике книг на полках можно ориентироваться. В конце концов, Вы так ничего не находите. На следующий день Вы уличаете своего подчиненного в том, что в рабочее время он зачитывается той самой книгой. Вы проводите беседу, стиль которой сложно угадать, а вот смысл, наоборот, предельно ясен. Вскоре выясняется, что книга в библиотеке с самообслуживанием взята Вашим сотрудником еще на прошлой неделе...
При достаточно несложной реализации такого способа создания электронного архива, следует отметить следующие свойства:
- Отсутствие системы поиска;
- Отсутствие системы учета, регистрации документов;
- Отсутствие возможности быстро получить сам документ (его необходимо достаточно долго искать);
- Отсутствие управления процессами создания новых документов с маршрутизацией разрабатываемого документа между пользователями, участвующими в процессе разработки, процессах проверок и утверждения;
- Отсутствие ведения истории разработки документа;
- Отсутствие создания новых версий документов (для дальнейшего использования информации ранее разработанных документов во вновь создаваемых).
Более серьезные составляющие полной системы архива и документооборота, например, обеспечение соответствия стандарту качества ISO9000.
Следующим способом создания электронных архивов является создание системы, прежде всего, для учета документов, позволяющей быстро найти записи о них. Говоря проще — создание электронной картотеки. Для реализации данного решения широко применяются файл -серверные и клиент — серверные приложения, использующие СУБД. Программа — клиент позволяет внести записи о документах по ключевым полям, заполнить электронную карточку документа.
Информация, вносимая в электронную карточку, записывается в таблицы СУБД и может быть быстро "извлечена" при помощи механизма запросов. Результаты запросов, как правило, выводятся в удобном для пользователя виде (таблица или набор электронных карточек). Работа с такими карточками напоминает работу с карточками библиотечного каталога. Существенное отличие заключается в том, что в "привычной" бумажной карточке присутствует лишь определенный набор атрибутов, а в хорошей электронной картотеке, пользователь сам может устанавливать необходимые атрибуты для разных типов документов. К тому же всю работу по быстрому поиску карточки выполняет СУБД и (или) клиентское приложение. Права доступа к тем или иным разделам могут определяться СУБД. Учетные записи содержат не только описания документа, но и указывают на место его хранения в "бумажном" или электронном виде.
В зависимости от прав пользователя, существует возможность редактирования учетных записей, внесения изменений.
Основные достоинства такого способа организации хранения:
- Возможность быстрого поиска информации о документе, записи о месте его расположения;
- Возможность внесения информации о новых документах, редактирование информации о ранее зарегистрированных в системе "единицах хранения".
Основным недостатком такого подхода является отсутствие быстрого доступа непосредственно к самому документу. Найдя учетную запись об искомом документе, даже если она и содержит информацию о месте нахождения, процесс "доставки самого документа пользователю" не автоматизирован.
Такой способ организации хранения можно проиллюстрировать следующим примером. Библиотека пытается усовершенствовать режим самообслуживания и предоставляет пользователям возможность работать с карточным каталогом, причем не только с "бумажным", но и электронным! Вы находите карточку искомой книги (после разговора с Вами, читавший её в рабочее время сотрудник вернул книгу в библиотеку). Найдя карточку, вы убеждаетесь, что книга присутствует и даже указано место хранения! Как и в прошлый раз, расталкивая растерянных читателей, Вы пытаетесь найти нужный шкаф и полку. Через определенное время, Вам это удается. Далее необходимо затратить усилия на поиск лестницы — стремянки (полка высоко). В конце концов, через час — другой Вы решаете все проблемы и получаете желаемое.
Прочими свойствами такого способа хранения являются:
- Отсутствие автоматизации процесса получения самого документа;
- Отсутствие самого документа в электронном виде;
- Отсутствие ведения истории разработки документа;
- Отсутствие управления процессами создания новых документов с маршрутизацией разрабатываемого документа между пользователями, участвующими в процессе разработки;
- Отсутствие возможности создания новых версий документов (для дальнейшего использования информации ранее разработанных документов во вновь создаваемых).
Более серьезные составляющие полной системы архива и документооборота, например, обеспечение соответствия стандарту качества ISO9000 не перечисляются, т. к. в такой реализации системы о них также говорить все еще нет смысла.
Этот способ организации системы электронного архива гораздо ближе к совершенству и объединяет два вышеописанных (файловый массив и картотека). Учет ведется при помощи использования клиент — серверных или файл — серверных приложений и СУБД. Результат поиска содержит не только записи "карточки" документа, но и предоставляет возможность вывода на экран или устройство печати самого документа.
Сравним данный способ с той же библиотекой. Вскоре после экспериментов по внедрению самообслуживания библиотека решила, что лучше будет автоматизировать свою деятельность. Наиболее "читаемые" издания переведены в электронный вид, внесены в базу данных и "выложены" в Internet. Доступ к базе — по имени и паролю. Имя и пароль приобретаются за отдельную плату и ограничиваются по сроку действия. Вы узнаете об этом совсем случайно, увидев, что сетевой принтер в Вашем офисе распечатывает последнюю главу книги. Да — да, ту самую главу той самой книги, которую не дочитал Ваш сотрудник — книголюб (после разговора об использовании рабочего времени)...
Как и в описываемом примере, способ имеет возможность разграничения прав доступа к разделам (например, пароль и имя пользователя). В отличие от Internet — библиотеки, способ не исключает возможности регистрации пользователем в архиве электронного документа или записи о "бумажном" документе или микрофильме, который пока не переведен в электронный вид.
К прочим свойствами, характеризующим описываемый способ создания системы электронного архива, можно отнести:
- Отсутствие ведения истории разработки документа;
- Отсутствие механизма использования хранимых документов не только для просмотра, но и для создания новых (с автоматической регистрацией в архиве), отсутствие управления процессами создания новых документов с маршрутизацией разрабатываемого документа между пользователями, участвующими в процессе разработки.
На самом деле, при кажущейся "разнородности" задач хранения и создания новой информации на основе хранимой, данные задачи успешно реализуются "внутри" одной системы. Тем самым, всячески исключаются случаи "открытия законов заново", упомянутые выше. В рамки материала не входит подробное описание самих программных продуктов. Это отдельная и очень большая тема. Но такие продукты существуют, успешно внедрены и продолжают внедряться на предприятиях.
Не секрет, что некоторые узлы устройств и механизмов, например, в судостроении, приборостроении и ряде наукоемких областей были разработаны еще пол века назад. С одной стороны, при разработке новых проектов нет смысла "изобретать велосипед", с другой же, использовать изделие, созданное по технологии полувековой давности не всегда целесообразно. Например, появились новые материалы, изменилась технология. Поэтому в системе электронного архива и возникает следующая задача — не только быстро найти необходимые документы и вывести их на экран или устройство печати, но и "позволить" создать новый документ на основе информации, содержащейся в документе ранее зарегистрированном. Причем новый документ должен автоматически быть "занесен" в архив, а "старый" документ ни в коем случае не должен быть изменен.
Описываемый способ объединяет все перечисленные ранее и добавляет в них возможность управления процессами создания документов с маршрутизацией между пользователями, подписями, проверками, утверждениями, анализом прохождения документа и т. д. Следует отметить, что все перечисленные в предыдущих способах "положительные стороны" существуют и здесь. Например, совсем не обязательно регистрировать в подобной системе документ, разрабатываемый "с нуля". Можно зарегистрировать и ранее разработанный и утвержденный документ.
В отличие от первых трех способов, этот подразумевает использование системы на всех рабочих местах участников процесса разработки, проверки, утверждения документов. Действительно, когда мы говорим об архиве, описанном в предыдущем пункте, достаточно, например, в каждом подразделении установить по 1 "клиентскому месту". С этого "места" осуществляется доступ к документам архива и регистрация новых. Описываемый же в этом пункте способ имеет модуль WorkFlow, который организует "документооборотную" часть системы. Основным назначением этого модуля является организация групповой работы над документом с учетом реальных обязанностей и должностной структуры предприятия, маршрутизацией документа между пользователями. Говоря проще, модуль позволяет пройти электронному документу все инстанции, маршруты, которые производились бы при разработке обычного "бумажного" документа. Хотя в подразделениях, не участвующих в процессе разработки, проверки и утверждения документов, может быть установлено всего по 1 "клиентскому месту" системы.
Как правило, предприятие имеет несколько информационных потоков. Деление достаточно условно и определяется реальной деятельностью и структурой. Подобные системы имеют важное преимущество — управление всеми информационными потоками предприятия с отображением логических связей. Как это происходит? Рассмотрим пример (возможно, он далек от Вашего предприятия, но, скорее всего, без особого труда Вы также сможете выделить несколько информационных потоков).
Итак, пусть предприятие — судостроительный завод. Как и на любом предприятии можно выделить "административный" поток. К нему относятся привычные "канцелярские" документы. Естественно, предприятие имеет цеха, оборудование и соответствующую инженерную документацию на них. Причем достаточно часто происходят процессы модернизации и переоборудования (хотя бы в небольших объемах). Все изменения должны вноситься и в соответствующие инженерно — конструкторские документы. То есть, правомерно будет сказать и о наличии инженерно-конструкторского информационного потока. Причем, как правило, процессы модернизации сами по себе не начинаются, а происходят согласно неким приказам и распоряжениям на предприятии. Приказы и распоряжения, в свою очередь, документы "административного" потока. Иными словами, существует логическая связь между изменениями в инженерно-конструкторском документе (принадлежащем к инженерно-конструкторскому потоку информации) и приказом по предприятию, который относится к "административному" потоку.
В составе вашего судостроительного завода работает КБ, проектирующее корабли. Поэтому можно выделить еще один поток информации — проектные данные. Предположим, что на некое спроектированное и произведенное устройство приходит письмо — рекламация. Естественно, письмо приходит на адрес приемной и попадает в "административный" информационный поток. При этом логическая связь с проектными данными неоспорима.
В разных системах подобные логические связи отображаются по-разному. Некоторые имеют возможность объединения под одной учетной записью, например, чертежей, проектных данных, приказов, распоряжений, переписки, маркетинговой и прочей информации, относящейся, в нашем случае, к некоему изделию. Некоторые системы отображают логические связи по-другому. В них существуют логические объединения (например, "проект"), группирующие документы разных информационных потоков по принципу принадлежности к одному объекту, проекту, изделию и т. д.
Кроме того, как правило, учитывается, что один документ любого потока может принадлежать к нескольким проектами. В этом случае, существуют два пути: если при включении зарегистрированного документа в проект не требуется корректировать документ (вносить изменения), то документ для экономии места и времени не копируется системой. В этом случае, создается ссылка. Для пользователя процесс создания ссылки выглядит как "появление" в проекте нового документа. Второй способ используется, когда в новый проект необходимо внести измененный документ, созданный на основе уже имеющегося. В этом случае система позволяет создать новую версию документа, произвести необходимые изменения. Документ извлекается из электронного архива, создается его версия. Изменения производятся только в версии, сам же документ изменить нельзя! Система позволяет, например, создать новый приказ на основе старого, изменив даты; создать новый договор, изменив сумму и дату или "дорисовать" часть чертежа модернизированного изделия. После внесения изменений новый документ, созданный на основе "старого", помещается в архив.
Процесс использования систем подобного уровня в случае просто "архивного" использования, т. е. без системы документооборота, полностью повторяет использование систем "третьего способа", описанных выше. Не будем останавливаться подробно на этом вопросе.
Рассмотрим использование модуля WorkFlow ("документооборотную" часть системы).
На любом предприятии, чаще в разработке документа принимают участие несколько человек. Если Вам близка инженерно — конструкторская деятельность, то Вы не можете не согласиться, что изделие разрабатывают несколько человек. В процессе разработки осуществляются нормоконтроль, проверки и утверждения документов и чертежей изделия, подтверждаемые подписями. Часто возникает необходимость отправки на доработку. Документ необходимо возвратить разработчику той части, которая не удовлетворяет в целом проекту. Таким образом, окончательное утверждение всего проекта происходит только после утверждения всех его составляющих, прохождения всех проверок. После окончания разработки документы должны быть помещены в архив.
Такие же правила существуют и при написании, например, коммерческих предложений, неких комплексных проектов, когда один человек не может достаточно подробно и качественно описать разные стороны предлагаемого решения.
Даже в небольших организациях, занимающихся только торгово-закупочной деятельностью, менеджер отдела продаж, как правило, предъявляет свои предложения своему руководителю, коммерческому директору и т. д. Опять же документ должен быть подписан, утвержден или возвращен с необходимыми пометками и замечаниями на доработку. После прохождения всех проверок и утверждений документ используется по назначению, а его копия помещается в "бумажном" или электронном виде в архив.
Именно такой принцип и поддерживается "документооборотной" частью системы. Сначала указывается произвольный список возможных статусов того или иного документа. Под статусом подразумевается некая реальная стадия, в которой может находиться документ, например, "зарегистрирован", "разработан", "проверен", "утвержден", "возвращен на доработку" и т. д. Для каждого типа документов указываются способы обработки. Под способом обработки или маршрутом документа подразумевается реально существующий "путь" документа между пользователями. Способ обработки (маршрут) делится на "подмаршруты". При описании способов обработки указывается какой пользователь и как может менять статус документа. "Подмаршруты" содержат списки обязательных действий, прежде всего, указывается изменение статуса. Могут указываться и другие обязательные действия, например, рассылка документов пользователям, визирование документов электронной подписью, автоматическое создание извещений об изменении и т. д. Причем часть обязательных действий производится системой автоматически (например, при пересылке о присвоении статуса "разработан" документ может быть автоматически отправлен вложенным файлом "встроенной" электронной почты пользователю системы, ответственному за проверку). Некоторые действия в принципе не могут быть произведены автоматически (например, документ "визируется" электронной подписью после изучения и введения соответствующего ключа — пароля на подпись). Сложно и запутано? Тогда Вы, скорее всего, никогда не сталкивались с системами документооборота и следует привести пример. Поскольку статья рассчитана на представителей самых различных по роду деятельности предприятий, в примере отсутствуют всякие намеки на возможные информационные потоки и типы конкретных документов.
Представьте себя в роли главы большой семьи. Перед самым Новым Годом Вы получили премию. Дома Вы просите жену поговорить с детьми о новогодних подарках, а сами начинаете думать над вопросом, что подарить жене и теще. Ваши дети начинают высказывать самые фантастические желания ("создавать документы", подтверждая их "подписями" — довольно настойчивыми требованиями и отсылая эти "подписанные документы — пожелания" Вашей жене). Часть пожеланий (не самая фантастическая!) сразу приобретает статус "проверка пройдена" и входит в состав вышестоящего документа — списка подарков для детей, создаваемых Вашей супругой. Остальная часть пожеланий приобретает статус "отправлен на доработку" и возвращается автору с пометками (объяснениями, что этот подарок "не нужен"). В конце концов, после всех "доработок", новый документ — список подарков для детей приобретает статус "проверено и утверждено женой" и "маршрутизируется" к Вам. Пока происходит создание списка подарков для детей, Вы составляете список подарков для жены и тещи, который после серьезных раздумий принимает статус "утвержден". Теперь из двух документов Вы пытаетесь создать единый "проект" — производите все проверки, переводите оба документа в статус "окончательно утверждено", "ставите свою подпись", приняв решение еще занять денег (премии недостаточно). Хотя может оказаться что один из двух списков будет "возвращен на доработку" с пометкой — указанием максимально возможной суммы. Тут решать только Вам...
Логика работы "документооборотной" части системы ничем не отличается от приведенной в примере. Следует добавить, что способов обработки — маршрутов — можно создавать сколь угодно много. Главное, чтобы они отвечали тем, что реально приняты у Вас на предприятии. Для "просто записи в архив" можно тоже создать маршрут "регистрация ранее утвержденного документа" без задания подмаршрутов и обязательных действий. В этом случае при регистрации ранее утвержденного документа, если указать ему такой способ обработки, система "просто запишет" документ в архив, то есть будет реализован принцип создания архива "третьим способом".
Добавлю, что подобные системы также позволяют вести учетные записи о бумажных документах и задавать любые атрибуты для карточки документа. Эти атрибуты в дальнейшем используются для поиска документов, их версий, листов и т.д.
Ниже рассматривается четвертый способ решения проблемы создания электронного архива, учитывающего возможность создание новой информации на основе хранимой. Если Вы не собираетесь автоматизировать процесс разработки новых документов, на основе находящихся в архиве, то необходимо просто исключить те или иные пункты из дальнейшего описания.
Основные перспективы развития систем архива, документооборота и управления потоками информации предприятия связаны, прежде всего, с внедрением последних достижений в области информационных технологий. Представим, что предприятие имеет территориально разнесенные подразделения или работает с партнерами по неким совместным проектам. В этих случаях необходимым является создание единого информационного пространства, позволяющего иметь доступ ко всей базе электронного архива (в случае территориально удаленных подразделений) или к части базы, касающейся совместных проектов (для использования партнерами).
В наше время лучшим решением является использование WEB — технологий и XML. Об использовании WEB — технологий говорилось выше, при описании взаимодействия СУБД с WEB — сервером. В этом случае работа в системе электронного архива напоминает работу с обычным сайтом. Клиентским приложением является привычный WEB — навигатор (например, Internet Explorer). Преимущества такой организации доступа к СУБД перечислены выше. Остановимся на использовании XML — языка Расширяемой Маркировки — eXtensible Markup Language. Для создания WEB-страниц широко использовался и используется язык HTML, позволяющий достичь "высокохудожественных", с точки зрения WEB — дизайна, представлений страниц в окне. Для работы же с данными, получаемыми WEB — сервером от СУБД, возможно применение, например, технологии ASP или IDC. Дело в том, что HTML не всегда способен представить не только содержание страниц (с точки зрения дизайна), а и сами данные, например, полученные от СУБД. Вопрос представления данных в разных технологиях решается по-разному. Например, в IDC результат запроса "вставляется" в соответствующий шаблон (файл *.htx), а сам запрос хранится на WEB — сервере (в виде файла *.idc). В технологии ASP страница генерируется при помощи файла ASP, используется язык VBS. Создание приложений, позволяющих работать через WEB — интерфейс без использования XML достаточно трудоемко. Не буду глубоко вдаваться в сам XML, а только приведу пример: для создания базы в интрасети по технологии ASP или IDC приходится (по личному опыту) приложить немало усилий, написать "вручную" сотни, тысячи строк, "разбросанных" по многим файлам. Такую же систему можно создать гораздо быстрее и эффективнее при использовании XML. Так, например, ряд компонентов Delphi 5 и 6, использующих XML, позволяет создать достаточно неплохие приложения без написания вообще хотя — бы одной строчки кода! Кроме того, всё приложение представляет собой 1 исполнимый файл, хранящийся на сервере и генерирующий страницы (в отличии от десятков-сотен файлов, которые применяются, например, в хорошей системе, созданной по технологии ASP).
При использовании WEB — технологий, удаленные подразделения или партнеры имеют доступ к архиву и системе документооборота через Internet. "Клиентским" приложением для них является "обычный" навигатор. Головное подразделение, в интрасети которого установлен сервер системы, "может работать" как через навигатор, так и через обычное "клиентское приложение".
Примером внедрения единого информационного пространства является использование системы DDM/PDM9000 в корпорации AZO. Именно по такому принципу организованно единое информационное пространство для территориально разнесенных (на разных материках!) подразделений и партнеров. Предприятия и партнеры корпорации расположены в Европе и Америке. Физически сервер системы установлен на головном предприятии. Система использует СУБД MSSQL. Доступ к базе в пределах головного предприятия осуществляется через соответствующие клиентские приложения. Для удаленной работы с базой используется технология "WWW+SQL". "Клиентским приложением" для удаленной работы является навигатор.
Как правило, при определении предприятия — подрядчика Заказчик "пристально изучает" все аспекты организации деятельности предприятия. Особо важная роль при этом отводится вопросам обеспечения качества производимой продукции. В материал не входит подробное описание стандарта ISO9000. Поясним кратко причины "проявления" иностранными заказчиками такого пристального внимания к вопросу. Дело в том, что в "годы железного занавеса" и "социалистических принципов Советского производства" часто игнорировались достаточно рациональные подходы "загнивающего буржуазного общества" к решению ряда вопросов. Это касалось, в том числе, и системы обеспечения качества. В нашей стране в годы "Исторического материализма" была принята система ОТК, военных и прочих приемок.
Основной алгоритм действий той системы качества был достаточно прост. Он заключался в том, что в основном производились проверки качества уже выпущенных изделий. По результатам проверок делались заключения о "пригодности" продукции. "Непригодная" часть отбраковывалась. То есть практически не уделялось внимания обеспечению качества непосредственно в процессе разработки и производства, ответственности каждого участника процесса за качество на "своем" участке. Ведь, в конце концов, качество всего изделия зависит от качества каждого "участка" — от разработки до поставки и внедрения, включая, казалось, такие "банальности" как упаковка и т. д. Советский подход часто приводил к высокому проценту брака и необоснованным затратам на производство изделий, которые заведомо не могут быть добротными. Например, если очень ответственно, соблюдая технологию и трудовую дисциплину собирать автомобиль из некачественных комплектующих, то, несмотря на все усилия бригады Коммунистического труда сборочного цеха, такой автомобиль много не проедет.
Для обеспечения качества производимой продукции с учетом ответственности каждого участника процесса и разработан стандарт ISO9000. Хотя выше приведено далеко не все его описание. Стандарт имеет четко определенные пункты, по наличию и правильной реализации которых можно судить о качестве продукции предприятия.
Читатель вправе спросить: "А при чем тут система архива и документооборота?". Отчасти он будет прав. Действительно, ошибочно говорить, что внедрение некоего решения позволит сразу сертифицировать предприятие, добившись соответствия ISO9000. Решение лишь способно обеспечить выполнение некоторых пунктов стандарта и даже автоматизировать их (при грамотном внедрении и использовании). Но установка ПО и аппаратных средств сами по себе ничего не дают, а лишь помогают выполнить требования модели качества.
Рассмотрим подробнее обеспечение некоторых элементов стандарта ISO при внедрении решения:
- Ответственность руководства. Элемент определяет ответственность руководства предприятия и персонала за качество продукции. Одним из требований элемента является создание должностной структуры и распределение обязанностей между сотрудниками. В системе архива и документооборота выполнению этого пункта способствует:
- Разграничение прав доступа, прав по разработке документов между пользователями;
- Описание маршрутов разработки документов, определение пользователей и конкретных обязанностей по разработке, проверке, утверждению;
- Возможность просмотра реального состояния дел (например, всегда можно увидеть стадию документа, понять на каком из подмаршрутов и по какой причине произошел "затор");
- Встроенная система электронной подписи (также способствует определению ответственности конкретного лица).
Документооборот в системе качества. Думаю, не стоит подробно останавливаться на принципах работы системы документооборота, они описаны выше. Добавим лишь, что система документооборота способствует разработке любых документов, в том числе и документов системы качества (перечень подробно приводится в стандарте), разрабатываемых соответствующими группами (их наличие, опять же, определено стандартом);
Управление проектированием. При реализации этого пункта, опять же, используются возможности системы, описанные выше;
Управление продукцией, поставляемой потребителем. Подразумевает ситуацию, когда продукция поставляется покупателем поставщику для сборки, объединения и обусловленных целей. Документы, регламентируемые этим элементом — методологические инструкции на работу с предоставленной Заказчиком продукцией, могут разрабатываться в системе документооборота, а информация о продукции регистрируется в архиве;
Управление закупками. Регламентирует управление закупками в случае, когда используются стандартные комплектующие, которые не поставляются покупателем поставщику для сборки, а закупаются у сторонних производителей и поставщиков. Такие комплектующие могут быть также зарегистрированы в системе архива как стандартные компоненты с описанием поставщика, производителя, возможных замен, условий закупки и прочих необходимых атрибутов.
Два последних пункта тесно связаны с дальнейшими путями расширения функциональности системы и подробно излагаются при описании механизма взаимодействия со складскими и бухгалтерскими программами при использовании механизмов экспорта-импорта и API — интерфейсов.
Добавим, что описание всех пунктов стандарта ISO является отдельной и объемной темой.
Не секрет, что комплексная автоматизация процессов предприятия всегда представляет интерес. Рассмотрим основные направления и пути расширения функциональных возможностей системы архива и документооборота и решения проблемы комплексности автоматизации.
Именно так, пожалуй, стоит назвать попытки автоматизации всех сторон деятельности предприятия при помощи одной системы. Преимуществом такого подхода является "идеальная универсальность". Возможность реализации подобного решения определяется, прежде всего, спектром деятельности предприятия.
Если Вы ведете лишь торгово-закупочную деятельность, то, действительно, спектр не очень велик: бухгалтерия, склад, зарплата, финансовое планирование и небольшая система архива и документооборота как "пристройка" к имеющейся системе. Все сравнительно несложно создать внутри даже одного программного продукта и набора аппаратных средств.
Предположим, что Вы занимаетесь еще и разработкой, внедрением, сопровождением, производством чего — либо. Спектр решаемых задач настолько велик, что не "уместится" в рамки одного программного продукта. Все попытки решить проблему автоматизации "всего и вся" внутри одной системы напоминают скрещивание "коня с трепетной ланью", "поиск философского камня" или создание "перепетум мобиле". В самом лучшем случае получается громоздкая и неадаптированная к качественному решению всех задач система.
Например, любая домохозяйка, сравнив работу отдельно произведенной электромясорубки и мясорубки, входящей в состав кухонного комбайна такого же класса, скажет, что первая — лучше. Если Вы приобретаете аппарат, включающий факс, телефон, копир, принтер, сканер и еще что-либо (например, настольную лампу или компьютер), то все эти устройства, как правило, работают хуже, чем созданные отдельно, даже тем же производителем, не говоря уже об удобстве в работе. Это связано с тем, что используются некие "общие" части, например, корпус, система питания и многое другое. Назначение этих "общих" частей одинаковое. Требования же устройств, входящих в решение "все в одном", к этим "общим" частям разные. Можно еще привести множество примеров, которые ассоциируются с подобным путем, но не будем заниматься этим.
Отметим, что здесь ни в коей мере не стоит путать понятие одной системы и единого информационного пространства! Как раз единое информационное пространство при использовании разных "специализированных" систем и является оптимальным решением! Но об этом ниже.
Другим путем повышения функциональности является создание систем, состоящих из небольшого числа "разнородных" составляющих, адаптированных к конкретной нише предприятий. Преимущество подобных решений состоит в том, что они все-таки решают разнородные задачи и "части" адаптированы друг к другу.
В качестве примера подобных систем можно привести довольно оригинальное устройство — глобус с подсветкой. Возможно Вам приходилось видеть такое. Благодаря небольшому числу "функциональных составляющих" — настольная лампа и глобус, устройство хорошо выполняет две разнородные задачи, являясь одновременно источником света и пособием по географии.
Недостатки же в том, что все равно весь спектр деятельности предприятия не автоматизируется и процесс комплексной автоматизации нельзя назвать завершенным. Ведь кроме глобуса и настольной лампы Вам нужен письменный прибор, сам стол и многое другое. Где же выход из создавшейся ситуации? Как, не превращая систему в устройство "все в одном", получить наибольшую функциональность? Оказывается существует решение и этого вопроса.
Как правило, большинство современных систем автоматизации различных сфер деятельности предприятия хранят записи в табличном виде и используют СУБД для внесения новых записей, редактирования старых, поиска необходимых. Над "извлеченными" из таблиц СУБД — записями, той или иной системой автоматизации производятся различные действия, например, финансовые, бухгалтерские или статистические расчеты и т. д. После этих действий производится либо изменение старой, либо внесение новой записи.
Вернемся снова к описанию некоторых возможностей современных СУБД. Таблицы, в которых хранятся данные, могут содержаться как в отдельных файлах, так и "внутри" одного файла. Думаю, что не стоит подробно останавливаться на том, что файлы могут иметь соответствующие форматы или расширения.
Начнем рассмотрение с идеального случая. Пусть Вы используете систему архива и документооборота и некую складскую систему, хранящие информацию в таблицах "одинаковых" СУБД. Причем некоторые таблицы, например, содержащие данные о списках комплектующих производимых изделий, имеют одинаковые поля. Например, изделия, хранящиеся на складе и "относящиеся" к складской программе, имеют номер, название и прочие атрибуты, которые содержит документация на эти изделия, "относящаяся" к системе архива и документооборота. Для того, чтобы информационное пространство стало единым, а списки "общими" необходимо периодически их "синхронизировать". Существует несколько способов синхронизации. От простой "подмены" таблиц до автоматической репликации. В последнем случае "ведущая" система передает в "ведомую" информацию из "общих" таблиц.
В случае, когда в двух приведенных выше системах используются различные СУБД, применяются имеющиеся в современных СУБД механизмы экспорта-импорта. Например, таблицу *.db СУБД Paradox достаточно просто экспортировать в таблицу базы СУБД MSSQL Server. При этом процесс, опять же, может быть полностью автоматизирован.
Самый "сложный" случай возникает, когда СУБД обеих систем не поддерживают экспорта-импорта "друг в друга" или вообще "никакого экспорта-импорта". В первом случае возможен экспорт-импорт через некий "промежуточный формат", "воспринимаемый" обеими СУБД. А еще лучше для первого и второго случаев создать программный конвертор, позволяющий осуществлять автоматический экспорт-импорт. Его создание может быть для Вас весьма проблематичным, если, например, таблицы одной из систем имеют формат, "придуманный" производителем самой системы. Но, так или иначе, своими силами или при помощи производителя вопрос решаем!
Отметим, что описания приведены только в "первом приближении". Некоторые поля в таблицах одной системы, например, "неинтересны" для другой и наоборот. Существуют способы решения и подобных проблем. Процессы импорта-экспорта являются отдельной и объемной темой, которая значительно превышает объем статьи.
Другим, "вполне пригодным", способом для создания единого информационного пространства является использование API. Для "более продвинутых" читателей нет смысла подробно описывать API. С другой стороны, поскольку объем материала ограничен (в отличие от темы API), для "менее продвинутых" читателей констатируем лишь следующие факты: существует "специальный" API, через него осуществляется взаимодействие между приложениями и операционной системой. Часть сервисов, предоставляемых API, обеспечивает возможность обмена информацией между двумя или более системами.
Расширение функциональности систем и создание единого информационного пространства наиболее оптимально при организации взаимодействия между разными системами автоматизации через механизмы экспорта-импорта и через API. Почему так рациональнее, чем пытаться строить "универсальную систему"? Приведу пример.
Представьте, что компьютеры Ваших сотрудников вдруг по техническим причинам отключились от локальной сети. Подчиненные просят срочно установить на каждый компьютер по модему для работы с электронной почтой. Вы вряд ли пойдете на это (имея выделенный канал или хотя бы сеть, подключенную через один модем!).
Вы не станете обеспечивать каждого сотрудника таким решением (превращая его компьютер в устройство "Все в одном"). Скорее всего Ваш системный администратор выполнит работу по восстановлению "экспорта-импорта" информации (передачи и приема почтовых сообщений по локальной сети с маршрутизацией их в Internet и в локальную сеть). Работа будет проведена методом восстановления доступных ему "интерфейсов" и механизмов "экспорта-импорта" почты между Internet и локальной сетью, и "внутри" локальной сети. В этом случае "Интерфейсами" и механизмами "Экспорта—импорта" почты являются сетевое оборудование и программное обеспечение.
Наконец, устройство питания сетевого маршрутизатора, вывалившееся из розетки ("хозяйка офиса" во время утренней приборки случайно задела), вновь подключено. Все механизмы, отвечающие за работу системы, восстановлены! Удалось избежать превращения компьютеров в устройства "Все в одном", избежать проблемы с вечно занятыми десятками модемов телефонными линиями и, наконец, материальных затрат.
Именно такой по своей логике подход к "Универсальности решения" реализуют системы электронного архива с настраиваемыми механизмами экспорта — импорта и использующие API — интерфейсы. Этот подход можно выразить другой народной мудростью о том, что "Сапоги должен точить сапожник, а пироги печь — пирожник". Пусть складская или бухгалтерская система будет решать свои специфические задачи по учету материальных и денежных средств, а специфические задачи по созданию систем архива и документооборота решает соответствующая система. Причем через механизмы экспорта — импорта осуществляется "синхронизация" таблиц СУБД. Например, списки постоянно закупаемых элементов для производимых изделий или самих изделий могут "быть общими" для обеих систем, но складская программа ведет учет наличия на складе, а система архива и документооборота ведет и хранит любую "административную" или инженерно-техническую документацию по этим изделиям.
Виртуальные VPS серверы в РФ и ЕС
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
