Документооборот государственного значения

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

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

От концепции к реальным продуктам

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

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

Имея на руках готовый план действий, прежде всего необходимо было задуматься о выборе программной платформы. Напомним, что это был конец 1994 года. В то время многие серьезные игроки в лице зарубежных компаний, и по сей день продолжающих проникновение на российский рынок систем управления документами (СУД), еще не развернули свою деятельность в нашей стране. Значительно беднее, чем сейчас, было и предложение со стороны отечественных компаний. На мысль об использовании платформы Lotus Notes руководство управления информационно-технологического обеспечения Думы натолкнуло посещение одной из компьютерных выставок, где демонстрировалось простейшее приложение, обеспечивающее логическую связь документов в системе Notes. И на тот момент выбор вряд ли мог оказаться существенно иным. Отметим, что и по прошествии нескольких лет весьма устойчивого развития отечественного рынка систем документооборота Lotus продолжает занимать на нем уверенные позиции, в особенности, пожалуй, в секторе государственных организаций. После переговоров с главой московского представительства Lotus Development (в то время еще самостоятельной компании), руководство, отвечающее за проект, окончательно убедилось в серьезности намерений фирмы на российском рынке. Таким образом было принято стратегическое решение о выборе платформы Notes для дальнейших разработок. В начале пути речь шла только о мониторинговой составляющей, или, иными словами, об отслеживании движения документов, относящихся к законотворческой деятельности. Задача работы с документом как со структурированной единицей, о чем мы скажем ниже, на первом этапе вообще не рассматривалась. Единой компьютерной сети в Государственной Думе, как ни странно это выглядит сегодня, тоже не существовало. “Мы начинали с того, что соединили два компьютера с помощью последовательного интерфейса и пробовали возможности групповой работы Notes в таком режиме”, — говорит советник Государственной Думы Владимир Иванович Медведь, по сути возглавлявший проект с самого начала. Сразу скажем также, что данная система полностью создавалась внутри организации и единственной сторонней услугой была консультационная поддержка компании InterTrust (http://www.intertrust.ru) по вопросам использования продуктов и технологий Lotus.

Lotus Development Corp. http://www.lotus.ru

Один из ведущих игроков рынка корпоративного ПО в трех областях: системы электронной почты и коллективной работы, управления знаниями и системы поддержки дистанционного обучения (принадлежит корпорации IBM). В числе основных продуктов Lotus — набор клиент-серверных приложений Lotus Domino и Notes. В совокупности это коммуникационная инфраструктура, объединяющая почтовую среду корпоративного масштаба, глобальные средства доступа и распространения информации, средства быстрой разработки и развертывания приложений коллективной работы, а также средства создания инфраструктуры сетей интранет. Сегодня Lotus предлагает новые решения на рынке систем передачи сообщений и совместной работы за счет стандартизации всего набора продуктов на основе открытых протоколов Интернета.

Вступая в стадию зрелости

Все, о чем говорилось до сих пор, было по сути реализацией общепринятой и практически стандартной схемы выбора решения, которая, исходя из требований элементарного здравого смысла, диктует необходимость изначальной проработки концепции и последующего поиска подходящей программной базы для ее реализации. Естественно, с этого начинается любая работа. По мере того как информационный проект врастает в структуру повседневной деятельности организации, его ветви начинают образовывать более сложные сплетения в виде технологических и организационных подзадач, требующих адекватного решения. До 1996 года обсуждаемый здесь проект внедрения мониторинговой составляющей работы с документами развивался без перехода на новую качественную ступень. “После этого в аналитическом управлении Госдумы выявилась пара энтузиастов — сотрудников, занимающихся концептуальными вопросами организации законодательных процедур, которые вплотную начали работать вместе с нами над общей задачей”, — говорит Владимир Медведь. Выражаясь в терминах проектного бизнеса, в Государственной Думе образовалась группа внутренних консультантов — профессионалов, имеющих долгосрочный опыт в той предметной области, которую предстояло автоматизировать. В силу того, что законотворчество есть одна из основных функций Думы, концептуальными вопросами занялись непосредственно сотрудники ее аппарата. Однако чаще постановщиков приходится привлекать со стороны, а при внедрении наиболее упрощенных схем электронного управления документами и вовсе обходятся без них. Но на вопрос о том, важна ли работа с консультантами на развитой стадии проекта, специалисты управления информационно-технологического обеспечения Думы однозначно дают утвердительный ответ.

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

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

Однако мониторинговая составляющая системы, нацеленная прежде всего на отслеживание движения документов в организации, как утверждает Владимир Медведь, выполняет лишь часть задач. Наряду с этим необходимо обеспечивать автоматизированное создание самих документов, особенно типовых. Часть системы АСОЗД, отвечающая за данную функциональность, в настоящее время проходит тестирование в нескольких комитетах. “Первая задача, которую мы себе поставили, — это обеспечение автоматизированного формирования повестки дня, протокола и комплекта документов в комитете по законопроекту”, — говорит Владимир Медведь. Речь идет о том, чтобы в ходе заседания комитета или сразу после него средствами информационной системы обеспечить создание пакета документов, необходимых для направления законопроекта в Совет Думы. Эти документы должны быть подготовлены в соответствии с регламентированными формами, а также с протоколом заседания комитета. Протокол, кстати, представляет собой интегральный документ, полностью формируемый из пунктов повестки и решений, принятых комитетом по рассмотренным законопроектам. С первого взгляда все это может показаться довольно сложным. Однако подчеркнем, что возложение задачи формирования типовых документов на информационную систему — это одна из наиболее типичных проблем в проектах по внедрению СУД.

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

Документ и его структура

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

Естественно, необходимость в структуризации текста законопроекта, или, иными словами, возможности оперативно манипулировать отдельными его частями, неоднократно возникала и в ходе обсуждаемого проекта. Частично это относится к ранее рассмотренному нами примеру с автоматизированным формированием повестки заседания комитета и документов, являющихся результатом его работы. Еще одна проблема, требующая структурированного представления текстовой информации, как утверждают специалисты Государственной Думы, — это работа с поправками к законопроекту. Необходим механизм логической разбивки соответствующего текста на главы, статьи, пункты, подпункты и т.д., который был бы понятен и пользователю, и обрабатывающей программе. “Мы должны предоставить субъекту права законодательной инициативы такой механизм формирования поправок, который не вызывал бы у него трудностей при их создании применительно к любому элементу законопроекта: названию, абзацу, слову и т.д., а также облегчил бы ответственному комитету их обработку, что является очень актуальной задачей”, — утверждает г-н Медведь. По его мнению, в теории хорошим решением могло бы стать использование заранее разработанных и затем программно сформированных шаблонов — если бы такой подход, увы, не был на практике нежизнеспособен. Дело в том, что значительная часть законопроектов поступает в Думу вообще в машинописном виде, и в этих условиях вести речь о строго унифицированных электронных форматах весьма затруднительно. Обратим внимание на то, что мы опять упираемся не столько в технологию, сколько в организационную проблему.

Государственная Дума Федерального Собрания Российской Федерации http://www.duma.gov.ru

Высший законодательный орган страны. Впервые Дума была созвана в 1906 году. В истории постсоветской России вновь избранная Государственная Дума приступила к работе в 1994 году. Депутатский корпус насчитывает около 450 человек, входящих, помимо независимых депутатов, в 9 фракций и депутатских групп. В структуре Госдумы имеется более 40 профильных комитетов и комиссий.

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

Интернет есть, а остальное приложится

В высшем законодательном собрании нашей страны активно приветствуется и применение Интернет-технологий. Web-сайт системы АСОЗД, функционирование которого обеспечивает сервер приложений Lotus Domino, — это один из внутренних, или интранет-узлов Государственной Думы. Его внедрение — отнюдь не дань моде, даже с позиций сегодняшнего дня, не говоря уже о будущем развитии информационной системы. В настоящее время интрасеть используется для доступа ко всей имеющейся законодательной информации, прежде всего со стороны Государственной Думы и Совета Федерации, что сопровождается сопутствующим сервисом: разграничением доступа, поисковым механизмом, использованием стандартных элементов Web-интерфейса и т.д.

Относительно развития концепции интрасети специалисты управления информационно-технологического обеспечения Госдумы имеют четко определенные планы. Весьма характерно, что они почти идеально сочетаются со стратегическими планами развитию продуктов у ведущих производителей ПО. Такое совпадение устремлений случается далеко не всегда. “Одна из основных задач, стоящих перед нами сейчас, — это переход от клиентской программы Notes, в которой готовится основная часть документов, к использованию Web-браузера, — говорит Владимир Медведь. — Мы не можем обязать всех региональных пользователей нашей интрасети приобретать Notes, а Интернет и браузер есть у всех”. Нынешние усилия производителей по пропаганде использования тонкого клиента и серверных платформ с сильным акцентом на Интернет-технологии также не могут оставаться незамеченными. Характерно также, что с клиентской частью проблем больше, что, впрочем, отразилось и на развитии продуктовой линейки Lotus. Следует сказать, что технологическая стратегия такого перехода пока еще не ясна руководству управления информационно-технологического обеспечения Думы во всех деталях, но надо думать, что с серверной составляющей здесь скорее всего также будет меньше проблем, чем с организацией рабочего места в стиле интранет у конечного пользователя.

Какие специалисты необходимы

В заключение полезно еще раз вернуться к организационным вопросам, которые, как мы уже не раз отмечали, зачастую становятся более серьезным препятствием на пути к отлаженной работе информационных систем, чем проблемы технологические. По мнению советника Госдумы Владимира Ивановича Медведя, чтобы обеспечить грамотное внедрение и последующую эксплуатацию СУД, необходимо иметь три группы специалистов, деятельность которых, несмотря на их тесное взаимодействие между собой в ходе проекта, необходимо административно разделить. Две из них уже упоминались выше: это аналитики, или постановщики задач — специалисты в предметной области; и технологи, работающие над программной реализацией задуманного. Третья группа должна представлять собой организационное подразделение, отвечающее за полноту, своевременность и достоверность информации. Фактически речь здесь идет о стадии эксплуатации, и, как утверждают сами сотрудники Думы, последнее направление на сегодняшний день — самое слабое. Думается, что это справедливо отнюдь не только для рассматриваемого проекта. О важной роли консультантов и разработчиков во внедрении корпоративного ПО говорится немало, сфера их ответственности также достаточно четко просматривается. Со стадией эксплуатации в основном связывают обучение пользователей, при этом затушевывая вопрос о конечной ответственности за вышеперечисленные факторы: полноту, достоверность и своевременность предоставления данных. А это, в свою очередь, достигается за счет не только дисциплины персонала и даже не только уровня его квалификации. Это требует еще и хорошо проработанного комплекса организационных мер, который должен гарантировать четкое функционирование информационной системы, прямо скажем, государственного значения.