19-11-2017

Перспективы развития систем электронного архива

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

В наше время лучшим решением является использование 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". "Клиентским приложением" для удаленной работы является навигатор.

Соответствие стандартам качества ISO

Как правило, при определении предприятия — подрядчика Заказчик "пристально изучает" все аспекты организации деятельности предприятия. Особо важная роль при этом отводится вопросам обеспечения качества производимой продукции. В материал не входит подробное описание стандарта ISO9000. Поясним кратко причины "проявления" иностранными заказчиками такого пристального внимания к вопросу. Дело в том, что в "годы железного занавеса" и "социалистических принципов Советского производства" часто игнорировались достаточно рациональные подходы "загнивающего буржуазного общества" к решению ряда вопросов. Это касалось, в том числе, и системы обеспечения качества. В нашей стране в годы "Исторического материализма" была принята система ОТК, военных и прочих приемок.

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

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

Читатель вправе спросить: "А при чем тут система архива и документооборота?". Отчасти он будет прав. Действительно, ошибочно говорить, что внедрение некоего решения позволит сразу сертифицировать предприятие, добившись соответствия ISO9000. Решение лишь способно обеспечить выполнение некоторых пунктов стандарта и даже автоматизировать их (при грамотном внедрении и использовании). Но установка ПО и аппаратных средств сами по себе ничего не дают, а лишь помогают выполнить требования модели качества.

Рассмотрим подробнее обеспечение некоторых элементов стандарта ISO при внедрении решения:

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

    Управление проектированием. При реализации этого пункта, опять же, используются возможности системы, описанные выше;

    Управление продукцией, поставляемой потребителем. Подразумевает ситуацию, когда продукция поставляется покупателем поставщику для сборки, объединения и обусловленных целей. Документы, регламентируемые этим элементом — методологические инструкции на работу с предоставленной Заказчиком продукцией, могут разрабатываться в системе документооборота, а информация о продукции регистрируется в архиве;

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

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

Добавим, что описание всех пунктов стандарта ISO является отдельной и объемной темой.

Немного о подходе к дальнейшему расширению функциональных возмож- ностей, созданию "Универсальной" системы

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

"Все в одном". Конь и трепетная лань

Именно так, пожалуй, стоит назвать попытки автоматизации всех сторон деятельности предприятия при помощи одной системы. Преимуществом такого подхода является "идеальная универсальность". Возможность реализации подобного решения определяется, прежде всего, спектром деятельности предприятия.

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

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

Например, любая домохозяйка, сравнив работу отдельно произведенной электромясорубки и мясорубки, входящей в состав кухонного комбайна такого же класса, скажет, что первая — лучше. Если Вы приобретаете аппарат, включающий факс, телефон, копир, принтер, сканер и еще что-либо (например, настольную лампу или компьютер), то все эти устройства, как правило, работают хуже, чем созданные отдельно, даже тем же производителем, не говоря уже об удобстве в работе. Это связано с тем, что используются некие "общие" части, например, корпус, система питания и многое другое. Назначение этих "общих" частей одинаковое. Требования же устройств, входящих в решение "все в одном", к этим "общим" частям разные. Можно еще привести множество примеров, которые ассоциируются с подобным путем, но не будем заниматься этим.

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

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

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

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

Недостатки же в том, что все равно весь спектр деятельности предприятия не автоматизируется и процесс комплексной автоматизации нельзя назвать завершенным. Ведь кроме глобуса и настольной лампы Вам нужен письменный прибор, сам стол и многое другое. Где же выход из создавшейся ситуации? Как, не превращая систему в устройство "все в одном", получить наибольшую функциональность? Оказывается существует решение и этого вопроса.

Создание систем архива и документооборота с развитыми и настраиваемыми механизмами экспорта — импорта информации, использование API

Как правило, большинство современных систем автоматизации различных сфер деятельности предприятия хранят записи в табличном виде и используют СУБД для внесения новых записей, редактирования старых, поиска необходимых. Над "извлеченными" из таблиц СУБД — записями, той или иной системой автоматизации производятся различные действия, например, финансовые, бухгалтерские или статистические расчеты и т. д. После этих действий производится либо изменение старой, либо внесение новой записи.

Вернемся снова к описанию некоторых возможностей современных СУБД. Таблицы, в которых хранятся данные, могут содержаться как в отдельных файлах, так и "внутри" одного файла. Думаю, что не стоит подробно останавливаться на том, что файлы могут иметь соответствующие форматы или расширения.

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

В случае, когда в двух приведенных выше системах используются различные СУБД, применяются имеющиеся в современных СУБД механизмы экспорта-импорта. Например, таблицу *.db СУБД Paradox достаточно просто экспортировать в таблицу базы СУБД MSSQL Server. При этом процесс, опять же, может быть полностью автоматизирован.

Самый "сложный" случай возникает, когда СУБД обеих систем не поддерживают экспорта-импорта "друг в друга" или вообще "никакого экспорта-импорта". В первом случае возможен экспорт-импорт через некий "промежуточный формат", "воспринимаемый" обеими СУБД. А еще лучше для первого и второго случаев создать программный конвертор, позволяющий осуществлять автоматический экспорт-импорт. Его создание может быть для Вас весьма проблематичным, если, например, таблицы одной из систем имеют формат, "придуманный" производителем самой системы. Но, так или иначе, своими силами или при помощи производителя вопрос решаем!

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

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

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

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

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

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

Именно такой по своей логике подход к "Универсальности решения" реализуют системы электронного архива с настраиваемыми механизмами экспорта — импорта и использующие API — интерфейсы. Этот подход можно выразить другой народной мудростью о том, что "Сапоги должен точить сапожник, а пироги печь — пирожник". Пусть складская или бухгалтерская система будет решать свои специфические задачи по учету материальных и денежных средств, а специфические задачи по созданию систем архива и документооборота решает соответствующая система. Причем через механизмы экспорта — импорта осуществляется "синхронизация" таблиц СУБД. Например, списки постоянно закупаемых элементов для производимых изделий или самих изделий могут "быть общими" для обеих систем, но складская программа ведет учет наличия на складе, а система архива и документооборота ведет и хранит любую "административную" или инженерно-техническую документацию по этим изделиям.

Класс!
колонтитулы в word 2007, 000000111
нумерация страниц в word 2007, 00000011111
Яндекс.Метрика
Копирование возможно при указании прямой индексируемой гиперссылки
п»ї