CC BY
63
Б.А. Гладких, А.Д. Терра, Е.Н. Якунина
ТЕХНОЛОГИЯ
ОПЕРАТИВНОГО УПРАВЛЕНИЯ КОНТИНГЕНТОМ СТУДЕНТОВ В АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ВУЗА
Функция оперативного управления персоналом и обучающимися в вузе рассматривается с точки зрения автоматизированной технологии подготовки и прохождения приказов по личному составу. Предлагается безбумажная технология документооборота, основанная на концепции формализованного приказа. Описывается опыт реализации предложенной технологии в документоориентированной среде Lotus Domino /Notes.
Большой объем рутинной управленческой работы в вузе связан с реализацией функции оперативного управления обучающимися (студентами, аспирантами, слушателями) и сотрудниками. С точки зрения информационной системы это управление состоит в изменении юридически значимых атрибутов статуса личности посредством надлежащим образом оформленной процедуры. На уровне вуза в целом такой процедурой в подавляющем большинстве случаев является издание соответствующего персонального приказа ректора. Подсистема оперативного управления в автоматизированной информационной системе (АИС) вуза должна обеспечивать полный цикл прохождения персональных приказов (подготовка проектов, принятие решений по согласованию и утверждению, реализация приказов).
Процессы прохождения приказов по обучающимся и сотрудникам идентичны, меняется лишь состав реквизитов и причастных должностных лиц; мы будем иллюстрировать автоматизированную технологию на примере обучающихся, которых для краткости будем называть студентами.
Традиционная технология и ее недостатки
Традиционная (бумажная) технология работы с приказами состоит из семи этапов:
1) подготовка проекта;
2) визирование проекта;
3) сборка приказа;
4) согласование и подпись приказа;
5) рассылка;
6) разноска;
7) поиск в архиве.
Основанием к возбуждению процесса издания приказа могут быть либо инициатива студента (заявление), либо инициатива должностного лица (представление).
Проекты приказов готовятся в деканатах. В идеале проекты типовых приказов должны строго соответствовать стандартным шаблонам, однако на практике это выполняется лишь отчасти, так как шаблоны по всем типам и вариантам не разработаны; у каждого факультета сложился свой стиль. Проект приказа подписывается деканом и вместе с сопровождающими документами передается проректору по учебной работе. Проректор рассматривает документы и при согласии с ними накладывает визу «В приказ». При несогласии документы возвращаются в деканат с мотивировкой отказа.
Далее проекты передаются в группу приказов канцелярии. Инспектор канцелярии группирует проекты по их типам (зачислить, отчислить, перевести и т.д.) и печатает подлинник сборного приказа. На этой стадии происходит коррекция стиля проектов с целью их унификации. Если деканат сделал представление в нестандартном виде, то именно здесь рождается проект приказа.
Отпечатанный проект сборного приказа визируется по установленному перечню должностных лиц и
поступает на подпись ректору (первому проректору). Если в процессе визирования кто-то не согласен с содержанием проекта, соответствующий пункт (позиция) вычеркивается.
Подписанный приказ возвращается в канцелярию, регистрируется в журнале и размножается в нужном числе экземпляров. Подлинник направляется в архив для длительного (75 лет) хранения, а копии заверяются и рассылаются в соответствующие деканаты и функциональные службы.
Каждая служба, получив копию приказа, совершает определенные действия, называемые разноской. В студенческом отделе кадров готовится выписка и подшивается в личное дело; в бухгалтерии вносятся изменения в реестр для начисления стипендии; в военно-учетном столе изменения разносятся по карточкам воинского учета и т.д. В деканатах, в зависимости от уровня делопроизводства, приказ либо просто принимается к сведению, либо разносится по картотекам, компьютерным базам данных.
Очень часто возникает необходимость обратиться к архиву за справками по приказам определенного типа или по приказам, относящимся к определенному событию. Типичная ситуация - составление статистических отчетов. В принципе, поскольку все движение контингента студентов строго документировано приказами, проанализировав массив приказов за отчетный период, можно получить абсолютно достоверную статистику в любом разрезе. Однако вручную это сделать практически невозможно, поэтому при составлении отчетов приходится обращаться с запросами на факультеты.
Основные недостатки бумажной технологии - медлительность и ненадежность. Практика показывает, что с момента возбуждения инициативы до получения копии приказа проходит одна-две недели. При этом проекты иногда «зависают» в неопределенном состоянии. Ненадежность системы вызывается несколькими факторами. Прежде всего, как отмечалось выше, проекты приказов при бумажной технологии невозможно строго формализовать. Это чревато неоднозначной интерпретацией текста на последующих этапах. Кроме того, при рассылке и разноске приказов неизбежны технические ошибки, что приводит к недоразумениям, задержкам в выплате стипендий и т. п. Недостатком существующей технологии, и это тоже отмечалось, является сложность быстрого получения объективной статистики. И наконец, традиционный документооборот сопряжен с дублированием информационных массивов, что порождает дополнительные затраты труда, расход бумаги и др.
Проект безбумажной технологии
Предлагаемая автоматизированная технология в общих чертах совпадает с традиционной и основана на концепции публичного приказа - все действия по реализации приказа в деканатах и функциональных службах осуществляются на единственном основании - при появлении соответствующего объекта в базе данных ПРИКАЗЫ. Но имеется ряд принципиальных отличий.
Во-первых, предлагаемая схема основывается на безбумажной технологии делопроизводства с однократным вводом информации. Бумажный документ фигурирует в ней дважды - на входе (личное заявление, справка либо иной документ, являющийся юридическим основанием к приказу) и на выходе (твердая копия приказа, оформленная надлежащим образом и предназначенная для архивного хранения и как доказательство при спорах). Все промежуточные документы (проекты приказов, визы, пояснения) существуют в виде файлов и записей баз данных. Юридическая сила этих документов обеспечивается системой электронной подписи, что предусмотрено современным законодательством.
Во-вторых, и это самое главное, в системе реализован принцип формализованных типовых приказов. Компьютерная форма приказа содержит не только текст, понятный человеку, но и формальную схему (фрейм приказа), необходимую и достаточную для автоматизации последующей реализации приказа (разноска в публичные и локальные базы данных, начисление стипендии и т.д.). Вот как может выглядеть пункт приказа в нотации языка XML [1], наиболее подходящего для структурированного формального описания подобных объектов:
<пункт_приказа>
<текст>
ЗАЧИСЛИТЬ Иванова Петра Сидоровича в гр. 1401 2 курса факультета информатики, с 01.02.2002 г. в порядке перевода из ТУСУР на контрактной основе.
</текст>
<фрейм>
<номер_приказа>133с</номер_приказа> <дата_приказа>15.02.2002</ дата_приказа> <номер_пункта>6.17</номер_пункта> <тип_приказа>зачислить</тип_приказа> <мотивировка>перевод из
другого вуза</мотивировка> <факультет>информатики</факультет> <группа>1411</группа> <личн_номер>1401007</личн_номер> <фамилия>Иванов</фамилия>
<имя>Петр</имя>
<отчество>Сидорович</отчество> <дата_зачисления>01.02.2002</ дата_зачисления>
<статус>платный</статус> <стипендия>нет</стипендия> <подпись>ректор Майер</подпись>
</фрейм>
</пункт_приказа>
Еще одно отличие от бумажной технологии состоит в том, что каждый пункт приказа проходит технологический цикл независимо от других. Это позволяет совместить этапы визирования проекта, согласования
и подписи: приказ собирается в самом конце из согласованных и утвержденных пунктов. При этом разноска может начинаться до получения твердой копии сборного приказа, а процедура подписания подлинника превращается в юридическую формальность.
На рис. 1 представлена укрупненная схема автоматизированной системы, реализующая предлагаемую технологию работы с приказами. Основными элементами системы являются четыре базы данных (ПРОЕКТЫ ПРИКАЗОВ, ПРИКАЗЫ, СТУДЕНТЫ, БАЗА ЗНАНИЙ) и программные модули, обслуживающие рабочие места должностных лиц, включенных в цикл подготовки, принятия и реализации решений по оперативному управлению контингентом студентов.
Функционирование системы ясно из рисунка. Проект приказа рождается на рабочем месте секретаря факультета с помощью модуля ПОДГОТОВКА ПРОЕКТА на основе централизованной БАЗЫ ЗНАНИЙ. Проекты, поступившие из разных источников, собираются в «почтовом ящике» базы данных ПРОЕКТЫ ПРИКАЗОВ, где они становятся объектом внимания модуля УПРАВЛЕНИЕ ДОКУМЕНТАМИ. С его помощью проекты регистрируются, проходят формальную проверку на наличие ошибок и становятся в очередь на согласование и утверждение (каждому типу приказа могут быть поставлены в соответствие свои набор и последовательность подписей).
Технически процедура согласования может осуществляться в безбумажной форме с помощью модуля ЭЛЕКТРОННАЯ ПОДПИСЬ, установленного на компьютере каждого должностного лица. Руководитель просматривает на экране проекты, стоящие к нему в очереди, и фиксирует факт согласия электронной подписью. При желании руководитель может здесь же на экране (или на бумаге, тогда текст в компьютер внесет секретарь) написать резолюцию или комментарий, который вместе с проектом пойдет дальше по цепочке согласований. Несогласованные проекты отмечаются особым флажком, и авторы их через модуль УПРАВЛЕНИЕ ДОКУМЕНТАМИ извещаются об этом, а также о содержании резолюций и комментариев.
После прохождения полного цикла утверждения проекты приобретают юридическую силу приказа с соответствующими реквизитами (дата, номер) и направляются в публичную базу ПРИКАЗЫ, где они становятся доступными для разноски. Разноска приказа в функциональной подсистеме (отдел кадров, бухгалтерия, деканат) специфична для каждой подсистемы и инициируется ею путем выборки определенных типов приказов, касающихся данной подсистемы.
Кроме баз, оперирующих с приказами, и локальных баз функциональных подсистем, на рисунке показана еще одна публичная база данных СТУДЕНТЫ, назначение которой состоит в том, чтобы отслеживать текущее состояние и изменение статуса всех студентов. Процесс внесения изменений в эту базу называется главной разноской. Данная база является темпоральной, т. е. в отличие от обычных двумерных (реляционных) баз данных она оперирует третьим измерением - временем, отслеживая траектории изменения состояний регистрируемых объектов. Такое свойство дает принципиальную возмо-
к приказу
Рис. 1. Схема безбумажной технологии
жность получения отчетов не только по текущему состоянию базы, как это делается в современных системах управления базами данных (СУБД), но и по любым юридически значимым (основанным на приказах) изменениям объектов учета в прошлом.
Особую роль в системе играет БАЗА ЗНАНИЙ. Один раздел этой базы - шаблоны приказов, в которых хранятся типовые тексты и соответствующие им фреймы. Кроме того, база знаний содержит динамическое описание всех понятий (сущностей и связей), с которыми оперирует система: структуру университета и ее эволюцию, классификаторы должностей, профессий, специальностей, степеней и званий, географических объектов и т. д. Динамическое свойство базы знаний дает возможность формально интерпретировать динамическую базу данных СТУДЕНТЫ на длительных промежутках времени. Как известно, законодательство требует хранить персональные базы данных в течение 75 лет, а за это время могут существенно измениться структура университета, перечни специальностей и должностей и даже географические понятия.
Реализация
При разработке крупной и ответственной информационной системы, кроме обычных профессиональных требований, необходимо учитывать специфические требования организационно-технического характера:
- возможность поэтапной разработки и внедрения элементов системы, включения ее в существу-114
ющие автоматизированные технологии, безболезненное сопряжение автоматизированных и неавтоматизированных участков;
- возможность функционирования системы при отказе технических средств, защищенность от неосторожного или умышленного искажения информации;
- согласованность с действующими стандартами делопроизводства, юридическая значимость машинных документов.
Указанные требования заставляют чрезвычайно серьезно относиться к выбору среды реализации, тем более что разрабатываемая технология будет работать не автономно, а в окружении смежных действующих или разрабатываемых систем (АИС «Деканат», АИС «Ректорат»).
В соответствии с принятой в Томском государственном университете технической концепцией разработка подсистем АИС ТГУ основывается на трех базовых информационных технологиях:
- электронный документооборот и поддержка деловых процедур, реализуемых в клиент-серверной среде Lotus Domino/Notes [2]. В этой среде естественным образом решаются задачи организации взаимодействия пользователей на основе электронной почты, а также создания унифицированного пользовательского интерфейса для разнообразных приложений;
- система управления документальными базами данных, в качестве которой также выбрана среда Lotus. В этой системе решаются проблемы представления документов в рамках объектной модели, в том
числе в виде документов XML, задачи полнотекстового поиска, взаимодействия с Web, важнейшие вопросы аутентификации и защиты информации;
- корпоративные фактографические (реляционные) базы данных на основе СУБД Oracle. Реляционное представление является оптимальным для организации крупных хранилищ жестко структурированных данных; кроме того, оно создает хорошую базу для построения более сложных моделей данных, например темпоральных.
Применительно к рассматриваемой в настоящей статье технологии предполагается, что базы данных ПРОЕКТЫ ПРИКАЗОВ, ПРИКАЗЫ , частично БАЗА ЗНАНИЙ, программные модули ПОДГОТОВКА ПРОЕКТОВ, УПРАВЛЕНИЕ ДОКУМЕНТАМИ реализуются в среде Lotus, а база данных СТУДЕНТЫ будет создана в виде темпоральной надстройки над реляционной СУБД, однако этот вопрос выходит за пределы данной статьи.
В настоящее время автоматизированная технология работы с приказами по студентам реализована в среде Lotus Domino/Notes на уровне факультета и инкорпорирована в АИС «Деканат». На уровне ректората безбумажная технология пока прерывается, так как реальная работа с электронными документами на этом уровне требует длительной подготовки и обучения высокопоставленных должностных лиц. Предполагается, что это будет сделано при внедрении комплексной АИС «Ректорат».
Технология реализована в программных модулях ПОДГОТОВКА ПРОЕКТОВ и РАЗНОСКА ЛОКАЛЬНАЯ, которые мы кратко рассмотрим с двух позиций: с точки зрения пользователя (снаружи) и с точки зрения реализации в конкретной среде (изнутри).
Взгляд снаружи
Подготовка проекта приказа начинается с выбора нужной формулировки из предложенного списка (рис. 2). Открывается окно соответствующей формы. По этой форме можно подготовить проект как индивидуального, так и группового приказа. Это зависит от количества фамилий, выбранных в списке (рис. 3).
При построении проекта группового приказа слева вводится информация для всего списка, а справа появляются поля для уточнения данных отдельных членов выбранного списка, если это необходимо.
Действуют следующие правила: все поля, значения в которых слева и справа совпадают, выносятся в заголовок проекта группового приказа, остальные вносятся в соответствующие пункты для каждого студента индивидуально. Допускается введение текстовых вставок в автоматически подготовленный в соответствии с внутренним шаблоном текст, хотя это и нежелательно. Этап подготовки проекта приказа закончен.
Рис. 2. Предложения списка выбора формулировок приказов
Рис. 3. Форма «Проект приказа».
Открыто окно для выбора фамилий студентов
Проекты приказов, которые посвящены одному вопросу, далее будем называть простыми. Простые проекты можно объединить в сборный проект, при этом создается новый документ, содержащий текст для печати. Исходные проекты приклеиваются к этому тексту как дети этого документа. Сборный проект приказа редактировать нельзя. Если на этом этапе требуется произвести какие-либо изменения в одном из проектов, нужно выполнить операцию разборки сборного проекта на составляющие. После редактирования нужного документа заново формируется сборный проект.
Поскольку система пока функционирует в отдельно взятых подразделениях, безбумажная техно -логия работы, как мы уже отмечали, временно прерывается. Созданный проект печатается, подписывается деканом и передаётся далее по инстанциям, следуя привычным путем. Обратно на факультет возвращается уже приказ с номером, датой и другими реквизитами.
Все вновь приобретенные реквизиты добавляются в электронный документ операцией «Подтвердить приказ». Документ исчезает из вида «Проекты приказов» и появляется в виде «Приказы\подтвер-жденные». Все действия выполнялись над одним и тем же электронным документом, который просто дополнялся, меняя свой статус.
Далее формируются вторичные документы - выписки из приказа, при этом приказ отмечается специальным значком. Созданные выписки появляются в виде «Приказы\выписки» (рис. 4).
Рис. 4. Вид «Приказы\выписки»
Копии полученных выписок отправляются в базу «Приказы» при выполнении действия «Отправить в студприказы», а оригиналы отмечаются галочками для визуального контроля.
Приказы могут содержать информацию об изменении статуса студента (отчислен, пребывает в академическом отпуске; на бюджетной либо платной основе обучается и т.д.), регистрационные изменения (номер группы, курса, факультета, специальность), сведения о назначении или снятии стипендии и т.д. Все изменения, порождаемые приказами, необходимо отражать в личной карточке студента.
Наступает этап разноски приказов. Информация из приказов должна автоматически попасть в электронные личные карточки. Производимые изменения в полях карточки зависят от типа приказа и содержащейся в нем информации. Ссылка на выписку из приказа помещается в карточку студента, что позволяет просматривать все приказы по студенту непосредственно из личного дела.
Взгляд изнутри
Идея автоматической разноски приказов базируется на введении в документ частичной структуризации. Приказ состоит из текста и фрейма. В то время как текст допускает некоторую свободу изложения, фрейм приказа строго формализован. В нем содержится вся значимая информация, необходимая для создания текста, для разноски, для получения отчетности, статистики и т.д. Структура этой необходимой информации зависит от типа приказа.
При реализации очень пригодился механизм под-форм. Бланк приказа представляет собой форму с видимыми и невидимыми полями, которые необходимы в приказах любого типа (общая часть фрейма). Все различия вынесены в подформы. Для каждого типа приказа создается индивидуальная подформа с полями, необходимыми только в этом случае (настраиваемая часть фрейма). Текст приказа создается автоматически при нажатии кнопки «Создать проект» или «Изменить пункт». Каждая подформа имеет свою процедуру построения текста проекта приказа.
Затраты на создание приказа нового типа минимизированы и сводятся к разработке новой подформы с полями, которых нет в основной форме, и процедуры создания текста для этого приказа. Все повторяющиеся фрагменты оформлены как процедуры и хранятся в библиотеке. При подготовке очередного проекта из списка выбирается необходимая формулировка приказа, в форму автоматически вставляется соответствующая подформа, создавая готовый бланк для ввода данных.
Процедура ввода данных заключается в основном в выборе необходимых значений из предложенных списков. Используются списки мотивировок и дополнительных сведений, которые пользователь может пополнять самостоятельно, а также списки студентов, которые берутся из других баз данных - «СТУДЕНТЫ» или «ОТЧИСЛЕННЫЕ».
ЛИТЕРАТУРА
1. Питц-МоултисН., Кирк Ч. XML: Пер. с англ. СПб.: BHV, 2000. 736 с.
2. Дебби Линд, Стив Керн. Lotus Notes и Domino R5 - Энциклопедия пользователя. Киев: DiaSoft, 2000. 651 с.
Статья представлена кафедрой прикладной информатики факультета информатики Томского государственного университета, поступила в научную редакцию номера 3 декабря 2001 г.
