CC BY
95
УДК 658.012.-11.56:061.5/.6; 681.5.01:658.5
Б.А. Гладких, С.П. Сущенко
КОНЦЕПЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПОДДЕРЖКИ ТИПОВЫХ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ ВУЗА
Излагаются принципы построения автоматизированной системы организационного управления вуза. Сформулжрованы критерии отбора автоматизируемых функций. Дана характеристика типовых функций управления. Предложена ижформа-ционная технология, реализующая организационно-технический базис процесса управления. Рассмотрены вопросы создания современной программной среды для реализации предложенной информационной технологии.
1. Системный анализ функций управления
Теория и практика создания автоматизированных систем управления (АСУ) убедительно показывают, что структура системы на верхнем уровне должна быть привязана не к существующей в данный момент организационной схеме управления, а к основным функциям управления, которые являются относительно устойчивыми к личным вкусам чиновников и разработчиков. На нижнем уровне АСУ должна распадаться на совокупность АРМов (автоматизированных рабочих мест) отдельных должностных лиц, четко
привязанных к их потребностям и возможностям. Успех внедрения системы зависит от того, насколько АРМы облегчают работу конкретных шсполнителей во всем диапазоне должностных обязанно>стей.
Для выявления основных функций управляющей системы применяется методика системнюго подхода [1], основанная на модели деятельности объекта управления. На рис. 1 приведена системная модель университета, построенная по общему принщипу декомпозиции производственных систем: процесс труда -это целенаправленное триединство средств труда, предметов труда и рабочей силы.
РАБОЧАЯ СИЛА
(кадры)
СРЕДСТВА ТРУДА
(ресурсы)
Рис. 1. Системная модель объекта управления
Исходя из данной модели функции управляющей системы на верхнем уровне могут быть декомпозированы по двум основаниям: по элементам производительных сил (управление кадрами; управление материальными ресурсами; управление информационными ресурсами) и по видам деятельности (управление учебным процессом; управление научными исследованиями; управление производственной деятельностью; управление социальной деятельностью).
2. Объект автоматизации
Следующий этап системного проектирования АСУ - отбор функций управления, подлежащих автоматизации. Хотя однозначных правил на этот счет не существует, можно руководствоваться следующими практическими критериями:
1) включаемые функции должны быть существенными с точки зрения руководства, т.е. они должны
150
занимать значительную долю времени и внимания при повседневном принятии решений по управлению университетом;
2) они должны быть объемными с точки зрения исполнителей, т.е. охватывать большое число должностных лиц в общеуниверситетском масштабе и, будучи автоматизированными, заметно облегчить их работу;
3) они должны быть алгоритмизируемыми, т.е. относиться к числу стандартных, рутинных процедур с однозначной интерпретацией всех действий.
Другая группа критериев связана с конкретными условиями реализации проекта:
4) включаемые функции должны быть реализуемыми на доступной программно-технической базе (технический аспект);
5) при детализации автоматизируемые функции должны быть привязаны к АРМам тех должностных лиц, которые организационно и психологически гото-
вы к внедрению новых информационных технологий (субъективный аспект);
6) включаемые в проект функции должны быть небезразличны для разработчиков, опираться на их знания, научные интересы, практический опыт и имеющийся задел (профессиональный аспект).
Последний и, возможно, решающий фактор, влияющий на выбор объектов автоматизации, ограниченность ресурсов (материальных, временных, трудовых), которые могут быть выделены на разработку. Поэтому имеет смысл говорить не о системе вообще, а о конкретном этапе разработки, ограниченном по времени и ресурсам. Это обстоятельство диктует еще один критерий:
7) включаемые в текущий проект АСУ функции должны быть не разрозненными, а, наоборот, как можно более тесно связанными между собой с точки зрения всех аспектов реализации (техническая база, информационные массивы, технология проектирования и эксплуатации).
С учетом всех изложенных критериев, основываясь на текущем состоянии разработки и имеющемся заделе, предлагается основным объектом автоматизации АСУ ТГУ на планируемом этапе (3-5 лет) выбрать блок функций управления человеческим компонентом производительных сил по всем видам деятельности.
Определив объект автоматизации на самом верхнем, абстрактном уровне, следует проводить дальнейшую декомпозицию и отбор функций управления до тех пор, пока они не лягут в русло конкретной (реальной или проектируемой) технологии управления, детализированной до АРМ должностных лиц.
Следующим стандартным основанием декомпозиции является типовой цикл организационного управления: планирование, оперативное управление, отчетность. Применяя это основание к выбранному объекту, получаем набор автоматизируемых функций:
1) планирование контингента обучающихся и штатов сотрудников;
2) оперативное управление всеми категориями сотрудников и обучающихся (абитуриенты, студенты, аспиранты, докторанты, соискатели, слушатели);
3) составление оперативных сводок и статистической отчетности по сотрудникам и обучающимся;
4) управление нормативными информационными ресурсами, имеющими отношение к принятию решений по предыдущим двум функциям.
Функция планирования контингента сводится к работе со штатным расписанием: первичный расчет, внесение изменений, оперативное отслеживание вакансий.
Основной объем управленческой работы в университете связан с реализацией функции оперативного управления обучающимися и сотрудниками. Оперативное управление личностями состоит в изменении их статуса посредством надлежаще оформленной юридической процедуры. Если речь идет об университете в целом, то такой процедурой в подавляющем большинстве случаев является издание соответствующего персонального приказа ректора.
С формальной точки зрения процессы прохождения приказов по сотрудникам и студентам идентичны, меняется лишь состав реквизитов и причастных долж-
ностных лиц. Функция оперативного управления может рассматриваться как функция, реализующая полный цикл прохождения персональных приказов (подготовка проекта, принятие решений по согласованию и утверждению, реализация приказов).
Функция составления оперативных сводок и статистической отчетности может рассматриваться как производная от предыдущей. Если процесс прохождения приказов формализован и автоматизирован, то, изучив пакет приказов за отчетный период, можно получить любую сводку в произвольном разрезе.
Нормативные информационные ресурсы создают устойчивый организационный и технологический базис для управления и составления отчетных документов. Ключевое значение здесь имеют стандарты на формы коллективной деятельности (управленческие стандарты), определяющие внутренние управленческие законы учреждения [2]. Управленческие стандарты должны образовывать целостную систему, полно и непротиворечиво регламентировать взаимодействие участников процесса управления. Они являются основным системообразующим элементом информационной технологии, определяя состав, правила интерпретации и способы обработки информации.
На примере прохождения приказов по студентам рассмотрим содержание блока функций управления.
3. Технология работы с приказами Структура текста приказа
Приказы могут быть простыми и сборными. Простой приказ посвящен одному (как правило, крупному) вопросу, который готовит одно подразделение. Пример - приказ о зачислении на факультет. Сборный приказ состоит из отдельных элементов, слабо связанных между собой. Большинство приказов являются сборными.
Сборный приказ состоит из разделов, каждый из которых соответствует определенному юридическому действию, например, зачислить, отчислить, назначить на стипендию, а разделы - из пунктов. Каждый пункт приказа соответствует определенной инициативе, подтвержденной документально, т.е. проекту приказа.
В примере на рис. 2 разделы 1 и 3 состоят из нескольких пунктов, раздел 2 - из единственного (можно считать его нулевым). Каждый пункт приказа может быть индивидуальным, посвященным одному студенту, или групповым (последний пункт). В групповом приказе имеется список, состоящий из позиций, каждая из которых относится к одному человеку.
Разделение приказа на разделы, пункты, позиции, является чисто техническим, имеющим целью облегчение чтения и экономию бумаги. В логическом отношении каждая позиция сборного приказа представляет собой отдельный приказ, однозначно идентифицируемый совокупностью признаков: Дата приказа, Номер приказа, Раздел, Пункт, Позиция. В базе текстов приказов каждая позиция должна храниться и обрабатываться автономно, сборный приказ существует только в виде твердой копии. Предлагаемый принцип позволяет легко формировать вторичный документ - выписку из приказа, которая имеет вид, приведенный на рис. 3.
151
1. ЗАЧИСЛИТЬ
1.1. Иванова Ивана Ивановича на 2 курс факультета информатики вода из ТГАС А. гр. 1471 с 1.09.98 в порядке пере-
1.2. Петрова Петра Петровича на 2 курс юридического факультета гр. 672 с 1.09.98 на платной основе как имеющего высшее образование. 2. ОТЧИСЛИТЬ
Симонова Сергея Львовича (646083), студ. гр. 1451 факультета собственному желанию. 3. ПРОДЛИТЬ СЕССИЮ 3.1. Студентам радиофизического факультета по болезни: 1) Иванову П.С. (111111), гр. 751 - до 15.10.98 2) Лазареву М.С. (123456), гр. 752 -до 20.10.98 информатики с 1.09.98 по
Рис. 2. Пример группового приказа
Государственный комитет РФ по высшему образованию Томский государственный университет ВЫПИСКА ИЗ ПРИКАЗА
12.09.98 № 140с
п. 3.1
ПРОДЛИТЬ СЕССИЮ
Студентам радиофизического факультета по болезни:
2) Лазареву М.С. (123456), гр. 752 -до 20.10.98
Ректор Г.В. Майер
Верно: Декан радиофизического факультета С.В. Малянов________________
Рис. 3. Пример выписки из приказа
Подавляющее большинство приказов, относящихся к студентам, являются типовыми, реализующими стандартный набор юридических действий: зачислить, отчислить и т.д. Все нестандартные приказы можно отнести к особому типу - нетиповой. Классификация приказов по типам представляет собой очень непростую задачу. Несмотря на накопленный опыт и традиции, удовлетворительный классификатор еще не создан. По нашему мнению, приказы должны относиться к одному типу, если они имеют:
- одинаковый шаблон текста;
- единый механизм согласования (маршрут визирования);
- единый алгоритм разноски.
Традиционная (бумажная) технология работы с приказами состоит из семи этапов: подготовки проекта; визирования проекта; сборки приказа; согласования и подписи приказа; рассылки; разноски; поиска в архиве.
Подготовка проекта. Основанием к возбуждению процесса могут быть либо инициатива студента (заявление), либо инициатива должностного лица (представление). Проекты приказов по студентам готовятся в деканатах. Имеющие место исключения (например, подготовка проектов кафедрой физвоспитания) нужно законодательно запретить. В идеале проекты типовых приказов должны строго соответствовать шаблонам, на практике это выполняется лишь отчасти, так как шаблоны по всем типам и вариантам не разработаны, у каждого факультета сложился свой стиль. Проект приказа (а иногда и неформальное представление) подписывается деканом или его заместителем и вместе с сопровождающими документами передаются проректору по учебной работе.
Визирование проекта. Проректор или замещающее его должностное лицо рассматривает документы и при согласии накладывает визу «В приказ». При несогласии документы возвращаются в деканат с мотивировкой отказа. Далее проекты с сопровождающими документами передаются в группу приказов канцелярии. В очевидных
152
случаях секретарь проректора сразу передает проекты в канцелярию, минуя визу проректора.
Сборка приказа. Инспектор канцелярии группирует проекты и печатает подлинник сборного приказа. На этой стадии происходит коррекция стиля представления для их унификации. Если деканат сделал представление в нестандартном виде, то именно здесь рождается проект приказа.
Согласование и подпись приказа. Отпечатанный подлинник сборного приказа визируется по установленному перечню должностных лиц в восходящем порядке (отдел кадров, бухгалтерия, юрисконсульт, проректор) и поступает на подпись ректору (первому проректору). Если в процессе визирования кто-то не согласен с содержанием проекта, соответствующий пункт (позиция) вычеркивается. Подписанный приказ возвращается в канцелярию.
Рассылка. В канцелярии приказ регистрируется в журнале, затем размножается в нужном числе экземпляров (как правило 6). Подлинник направляется в архив для длительного (75 лет) хранения. Проекты с сопровождающими документами направляются в архив в дело «Основания к приказам», где хранятся несколько лет. Копии заверяются и рассылаются в службы (ОК, бухгалтерия, ПФУ, военно-учетный стол, другие службы, смотря по типу входящих в сборный приказ пунктов) и соответствующие деканаты.
Разноска. Каждая служба, получив копию приказа, совершает определенные действия, называемые разноской. В студенческом отделе кадров готовится выписка и подшивается в личное дело. В бухгалтерии стипендиальная группа вносит изменения в компьютерную базу данных. В военно-учетном столе изменения разносятся по карточкам и т.д. В деканатах, в зависимости от уровня делопроизводства, приказ либо просто принимается к сведению, либо разносится по картотекам, базам данных и т.п.
Поиск в архиве. Часто возникает необходимость обратиться к архиву за справками по приказам опре-
деленного типа или по приказам, относящимся к определенному событию. Типичная ситуация - составление статистических отчетов. В принципе, поскольку все движение контингента студентов строго документировано приказами, проанализировав массив приказов за отчетный период, можно получить абсолютно достоверную статистику в любом разрезе. Однако вручную это сделать практически невозможно, поэтому при составлении отчетов приходится обращаться с запросами на факультеты.
Недостатки традиционной технологии
Основные недостатки бумажной технологии - медлительность и ненадежность. Практика показывает, что с момента возбуждения инициативы до получения копии приказа проходит одна-две недели. При этом проекты иногда «зависают» в неопределенном состоянии.
Ненадежность системы вызывается несколькими факторами. Прежде всего, как отмечалось выше, проекты приказов при бумажной технологии невозможно строго формализовать. Это чревато неоднозначной интерпретацией текста на последующих этапах. Кроме того, при рассылке и разноске приказов неизбежны технические ошибки, что приводит к недоразумениям, задержкам в выплате стипендий и т.п.
Недостатком существующей технологии, и это тоже отмечалось, является невозможность быстрого получения объективной статистики. И, наконец, традиционный документооборот сопряжен с дублированием информационных массивов (одна и та же база данных хранится в бухгалтерии, отделе кадров, военно-учетном столе, деканатах, библиотеках и т.д.). Это порождает дополнительные затраты труда, расход бумаги и пр.
4. Проект безбумажной технологии
При разработке крупной и ответственной информационной системы, кроме обычных профессиональных требований (однократный ввод информации, гибкость алгоритмов и т.п.), необходимо учитывать специфические требования организационно-технического характера:
- возможность поэтапной разработки и внедрения системы, безболезненного сопряжения автоматизированных и неавтоматизированных участков;
- возможность функционирования системы при отказе технических средств;
- защищенность от неосторожного или умышленного искажения информации;
- согласованность с действующими стандартами делопроизводства, юридическая значимость машинных документов.
Предлагаемая безбумажная технология в общих чертах совпадает с традиционной и состоит из пяти этапов: подготовки проекта; согласования и подписи проекта; сборки, выпуска и рассылки; разноски; поиска в архиве.
Основное отличие от бумажной технологии состоит в том, что каждый пункт приказа проходит технологический цикл независимо от других. Это позволяет совместить этапы визирования проекта, согласования и подписи приказа: приказ собирается в самом конце из согласованных и утвержденных пунктов. При этом разноска может начинаться до получения твердой копии сборного приказа, а процедура подписания твердой копии превращается в юридическую формальность.
На рис. 4 представлена укрупненная схема автоматизированной системы, реализующая предлагаемую технологию работы с приказами.
Рис. 4. Структурно-функциональная схема автоматизированной системы
Основными элементами системы являются пять общедоступных (публичных) баз данных: Нормативные акты; Проекты приказов; Приказы персональные; Сотрудники и студенты; База знаний; АРМы должностных лиц, включенных в цикл подготовки, принятия и реализации решений по управлению персоналиями: АРМ ректора (проректора); АРМ декана (руководителя иного основного структурного подразделения); АРМ начальника ПФУ; АРМ главного бухгалтера; АРМ
юрисконсульта; АРМ ученого секретаря ученого совета ТГУ; АРМ работника канцелярии, ответственного за прохождение приказов; АРМ функциональных служб, ответственных за реализацию персональных приказов (отдел кадров, бухгалтерия, военно-учетный стол, отдел аспирантуры и т.д.); АРМ администратора АСУ.
Предлагаемая схема реализует принцип безбумажной технологии делопроизводства с однократным вводом информации. Бумажный документ фигурирует в
153
ней дважды - на входе (личное заявление, справка либо иной документ, являющийся юридическим основанием к приказу) и на выходе (твердая копия приказа, оформленная надлежащим образом, предназначенная для архивного хранения и служащая доказательством при спорах). Все промежуточные документы (проекты приказов, визы, пояснения) существуют в виде файлов и записей баз данных. Юридическая сила этих документам обеспечивается системой электронной подписи, что предусмотрено современным законодательством.
Принципиальной особенностью предлагаемой системы является то, что все действия по реализации приказа делаются на единственном основании - при появлении соответствующей записи в публичной базе данных Приказы персональные. Для этого шаблон типового приказа содержит не только стандартный текст, но и формальную модель (фрейм приказа), необходимую и достаточную для автоматизации последующей реализации приказа (разноски в публичные и локальные базы данных, начисления зарплаты и т.д.).
Реализация приказа в функциональной подсистеме (отдела кадров, бухгалтерии) специфична для каждой подсистемы и инициируется ею путем выборки определенных типов приказов, касающихся данной подсистемы.
Кроме локальных баз функциональных подсистем, существует публичная база данных Студенты и сотрудники, которая обслуживается администратором системы; внесение изменений в эту базу называется главной разноской. Данная база является несколько необычной с точки зрения современной технологии СУБД. В отличие от двумерных (реляционных) статических баз данных она оперирует третьим измерением - временем, отслеживая полные траектории изменения состояний регистрируемых объектов. Такое свойство дает принципиальную возможность получения отчетов не только по текущему состоянию базы (как это делается в современных СУБД), но и по любым юридически значимым (т.е. основанным на приказах) изменениям объектов учета в прошлом.
Особую роль в системе играет База знаний. Один фрагмент этой базы - шаблоны приказов, в которых хранятся типовые варианты приказов. Кроме того, база знаний содержит динамическое описание всех понятий (сущностей и связей), которыми оперирует система: структура университета и ее эволюция, классификаторы должностей, профессий, специальностей, степеней и званий, географических объектов и т.д. Динамическое свойство базы знаний дает возможность формально интерпретировать динамическую базу данных Сотрудники и студенты на больших промежутках времени. Как известно, законодательство требует хранить персональные базы данных в течение 75 лет, а за это время могут существенно измениться структура университета, перечни специальностей и должностей и даже географические понятия.
Рассмотрим основные этапы безбумажной технологии работы со студенческими приказами.
Подготовка проекта. Под проектом приказа в безбумажной технологии будем понимать строго формализованный текст, записанный в определенном формате (см. ниже) на техническом носителе. Все остальные документы на бумажном носителе (в том чи-
154
еле распечатка проекта) считаются основаниями (приложениями) к проекту. Подготовка проекта происходит один раз (принцип однократного ввода информации), но место этой операции зависит от уровня технической оснащенности деканата.
«Отсталый» деканат работает по традиционной технологии и может подготовить лишь основание к проекту (как при существующем документообороте). Формальный проект приказа составляется инспектором учебного отдела (или канцелярии) с помощью программного модуля Подготовка проектов приказов.
«Передовой» деканат предполагается оснащенным собственным компьютером, работающим автономно или в сети. На нем устанавливается аналогичный программный модуль. Формальный проект, подготовленный этим модулем, передается в виде файла на дискете или по сети в учебный отдел. Туда же пересылаются приложения (в том числе распечатка проекта), которые требуются руководителю для обоснованного решения, а затем они, как обычно, сдаются в архив.
Распечатка проекта удостоверяется обычной подписью декана или его заместителя, а файл проекта на техническом носителе - его электронной подписью. Этим гарантируется достоверность и неизменность проекта на всех этапах технологического цикла: без согласования с автором проекта в нем невозможно изменить ни один символ.
Согласование и подпись проекта. Проекты, поступившие из разных источников, собираются в «почтовом ящике» базы данных, где они становятся объектом внимания модуля Управление документами. С его помощью проекты регистрируются, проходят формальную проверку на наличие ошибок и становятся в очередь на согласование и утверждение (каждому типу приказа могут быть поставлены в соответствие свои набор и последовательность подписей).
Технически процедура согласования осуществляется в безбумажной форме с помощью модуля Электронная подпись, установленного на компьютере каждого должностного лица. Руководитель просматривает на экране проекты, стоящие к нему в очереди, и фиксирует факт согласия электронной подписью. При желании руководитель может здесь же на экране написать резолюцию или комментарий, который вместе с проектом пойдет дальше по цепочке согласований.
Несогласованные проекты отмечаются особым флажком, и авторы их через модуль Управление документами извещаются об этом, а также о содержании резолюций и комментариев.
В модуле Электронная подпись должен быть предусмотрен определенный сервис дня руководителя: возможность получения справок по приказам, которые изменяются или отменяются данным проектом и т.д.
После получения всех необходимых виз проект считается утвержденным и становится пунктом приказа (пока без номера), хотя твердой копии еще нет. Предполагается, что руководитель проявляет принципиальность и, поставив электронную подпись, не откажется от обычной.
Сборка, выпуск и рассылка приказа. Когда утвержденных проектов накапливается достаточное количество (за этим следит модуль Управление документами), автоматически готовится сборный приказ.
Однотипные пункты собираются в разделы, происходит их нумерация, собранный приказ получает порядковый номер и дату издания. Готовый приказ отправляется в базу данных Приказы; одновременно готовится твердая копия подлинника, которая отправляется на подпись всем лицам, участвовавшим в безбумажном согласовании (идентичность ранее согласованного и бумажного варианта гарантируется технологией).
Вариант - отправлять приказ в базу данных после рукописной подписи, что дает принципиальную возможность отказаться от электронной.
Здесь же готовятся копии приказа, причем новая технология позволяет на этом этапе сэкономить много драгоценной бумаги, так как бумажные копии нужны только отсталым, некомпьютеризированным подразделениям, но даже отсталые подразделения заинтересованы не во всех, а лишь в отдельных пунктах приказа, отобранных либо по имени подразделения (факультеты), либо по типу приказа (бухгалтерия, военно-учетный стол и т.п.).
Разноска. Безбумажная технология позволяет достичь принципиально нового качества делопроизводства - автоматической разноски приказов. Это возможно из-за высокой формализации приказа. Как мы покажем в дальнейшем, каждый проект (а следовательно, и пункт приказа) состоит из двух частей: неформальной (текста) и формальной (фрейма). Текст предназначен для восприятия человеком и допускает определенные стилистические вольности и комментарии, не искажающие смысла. Фрейм приказа строго формализован, в нем содержатся значения всех параметров, необходимые и достаточные для однозначной интерпретации содержания. Анализируя фрейм, модули разноски вносят соответствующие изменения в обслуживаемые ими базы данных.
На рис. 4 изображены три модуля разноски: Разноска главная, Разноска специальная и Разноска на факультете.
Под Разноской главной подразумевается функция обслуживания базы данных Студенты, содержащей общие сведения о контингенте студентов университета. Вопросы построения и функционирования этой базы выходят за рамки нашего изложения и здесь не рассматриваются.
Разноска специальная означает обслуживание локальной базы данных в некотором функциональном подразделении. Примером может служить разноска стипендиальных приказов в базы данных бухгалтерии и отдела кадров.
Третий пример - Разноска на факультете. Имеются в виду выборка всех приказов, относящихся к студентам определенного факультета, и формирование на их основе локальной базы данных о студентах факультета.
Основной принцип действия любого модуля разноски - проявление инициативы снизу. База данных Приказы персональные является общедоступной. Задача модуля разноски - выбрать новые, еще не обработанные приказы и, анализируя содержание их фреймов, выполнить соответствующие действия по актуализации своих баз данных.
Поиск в архиве. Специальные модули, осуществляющие эту функцию, на схеме не показаны, потому
что они не являются специфическими для какого-либо подразделения. Проблема поиска архивного приказа может возникнуть везде: и при подготовке проекта, и при согласовании, и при разноске (новый приказ может изменить или отменить один из старых). Это значит, что должен существовать универсальный модуль поиска, легко подключаемый к остальным модулям системы.
5. Вопросы реализации Имеющийся задел
Предлагаемый проект родился не на пустом месте, а является переосмыслением практического опыта, полученного в результате проектирования и эксплуатации двух прототипов: систем «Приказы по сотрудникам» и «Проекты приказов».
Система «Приказы по сотрудникам» проектировалась в 1991-1993 гг. и находится в эксплуатации в отделе кадров и НИЧ ТГУ с 1994 г. Через нее проходит подавляющее большинство приказов по ППС, УВП, сотрудникам НИЧ. При внедрении системы была проделана большая подготовительная работа: введена система табельных номеров, разработаны классификаторы подразделений, должностей, групп персонала и т.п.; разработаны шаблоны типовых приказов по кадрам.
Техническая база, которой располагал университет к моменту начала работы системы, была весьма примитивной: отсутствовала вычислительная сеть, компьютеры пользователей были маломощными. Это не позволило реализовать начальный замысел в полном объеме (отсутствовала система электронного визирования, не реализованы функции архивного поиска и функциональной разноски и др.), что резко снижало эффект от работы системы. В практике АСУ давно доказано, что, если набор функциональных возможностей системы меньше некоторого порогового значения, то пользы от нее меньше, чем дополнительных затрат, и только после превышения этого порога наблюдается реальный положительный эффект. Так и здесь - система долгое время балансировала на грани выживания, и только энтузиазм и настойчивость отдела кадров позволили пережить нелегкий период становления.
Сейчас система работает устойчиво, она практически подтвердила правильность принципов, положенных в ее основу. К настоящему времени ее функциональные возможности исчерпаны, к тому же она морально устарела с точки зрения реализации (технология CLIPPER в MS DOS). В связи с этим возник вопрос о радикальной перестройке системы на базе новых идей и новых информационных технологий (клиент-серверные технологии, графический пользовательский интерфейс, объектно-ориентированное и визуальное программирование, макетные технологии реализации и др.).
Другая система - «Проекты приказов» - была создана в 1993-1995 гг. как подсистема АСУ деканата факультета информатики. Она была реализована макросредствами интегрированного пакета FRAME-WORK и с самого начала замышлялась как модель для опробования новых идей в области автоматизации делопроизводства. Эту функцию система выполнила и, кроме того, она приносит ощутимую практическую
155
пользу: все проекты приказов по студентам, поступающие в ректорат от факультета информатики, готовятся этой системой, а на факультете в результате автоматической разноски поддерживается актуальная база данных о контингенте студентов факультета.
Современная среда реализации
Современные приложения и инфраструктура информационных технологий развиваются существенно различными темпами [3]. Обычно приложения появляются значительно быстрее, чем соответствующая инфраструктура для них. К тому же быстрое моральное старение средств вычислительной техники приводит к необходимости постоянного развития технической базы информационных технологий. В общем случае срок службы системно-технической инфраструктуры в несколько раз выше, чем у приложений
[4]. Одним из наиболее эффективных способов сохранения инвестиций и устранения несоответствия уровня развития инфраструктуры организации требованиям приложений является использование идеи сервероцентрических вычислений [3,5]. Данная архитектура основана на принципе «сверхтонкого клиента» [6] и состоит из трех компонентов: серверного программного обеспечения, клиент-серверных протоколов, независимых от транспортного протокола, и клиентского программного обеспечения [3]. Такой подход позволяет обеспечить независимость ОС клиента от приложения и тем самым продлить жизнь рабочим местам клиентов на базе устаревающих настольных систем. Кроме того, это дает возможность снизить требования к пропускной способности сети, поскольку само приложение выполняется на сервере, а на стороне клиента отображаются только результаты обработки. Важно также то, что при этом существенно снижается
стоимость владения системой за счет сокращения трудоемкости администрирования (особенно заметного при миграции пользователей по различным настольным системам). Наиболее полно архитектура сервероцентрических вычислений реализована в продуктах Windows NT 4.0 Terminal Server Edition и Metaframe фирм Microsoft и Citrix. Применение этой архитектуры допускает совместное использование «толстого», «тонкого» и «сверхтонкого» клиента [6]. Данные продукты являются основой современного воплощения рассмотренной концепции.
Для реализации функций хранения и доступа к данным в современной версии автоматизированной системы используется реляционная СУБД Oracle 7.3, а для организации коллективной работы с информацией и документооборота - продукт Lotus Domino 4.6, имеющие наиболее развитую функциональность в среде сервера приложений Windows NT. Данные программные средства являются мощным инструментом автоматизации деловых процессов. Продукт Lotus Domino 4.6 имеет открытый инструментарий для интеграции информационной деятельности учреждения в мировое информационное пространство сообщества Интернет, позволяя с помощью единого интерфейсного фильтра работать с документами организации, «публиковать» их для «внешнего мира» (Web-публикации) и «видеть» информационные фонды «внешнего мира» (Web-фонды). Методы «публикации» существенно ориентированы на издание баз данных с динамически меняющимся содержанием. При этом естественно решаются вопросы аутентификации и защиты конфиденциальной информации с помощью методов электронной подписи и шифрования с открытым ключом, задачи ограничения и контроля доступа к базам данных учреждения.
ЛИТЕРАТУРА
1. Гладких Б.А. и др. Системное проектирование АСУ хозяйством области. М.: Статистика, 1977. 159 с.
2. Ананьин В. И. Корпоративные стандарты - точка опоры автоматизации // СУБД. 1998. № 5-6. С. 4-16.
3. Липпис Н. Серверо-центрические вычисления // Журнал сетевых решений LAN. 1998. Т. 4, № 9. С. 19-20.
4. Ладыженский Г. М. Архитектура корпоративных информационных систем // СУБД. 1998. №5-6. С. 17-24.
5. Дерфлер Ф. Тонкие клиенты, надежные серверы, крепкие сети // PC magazine RE. 1998. № 10. С. 127-135.
6. Ша Р. Энциклопедия моделей сетевых систем // Computerworld. 1998. № 39. С. 34-36.
Статья представлена ученым советом и деканатом факультета информатики Томского государственного университета, поступила в рабочую научную редакционную группу «Проблемы компьютеризации» 20 ноября 1999 г.
156
