CC BY
176
УДК 004.9
В. О. Демиш 1, Б. Н. Пищик 2, Г. Г. Козьменко 3
Новосибирский государственный университет ул. Пирогова, 2, Новосибирск, 630090, Россия E-mail: 1 narh@ngs.ru; 2 pbn@post.nsu.ru; 3 galina@nsu.ru
ПРОБЛЕМЫ АВТОМАТИЗАЦИИ УПРАВЛЕНИЯ ОБРАЗОВАТЕЛЬНЫМ УЧРЕЖДЕНИЕМ *
Автоматизация образовательных учреждений - актуальная и сложная задача, которая в настоящее время решается различными путями во многих учреждениях. На примере Новосибирского государственного университета рассматривается специфика такой автоматизации. Обсуждаются проблемы разработки и сопровождения программного обеспечения для решения основных управленческих задач, включая бухгалтерский учет, управление персоналом и расчет зарплаты. Основываясь на опыте отдела информационных систем Новосибирского государственного университета, дан ряд рекомендаций по автоматизации образовательных учреждений.
Ключевые слова: автоматизация образовательных учреждений, технологическая платформа автоматизации, управленческие задачи образовательного учреждения, управление учебным процессом.
Введение
Автоматизация образовательных учреждений (ОУ) является одним из приоритетных направлений национального проекта «Образование» и Федеральной целевой программы «Развитие образования на 2006-2010 гг.», поэтому создание и поддержка таких систем является актуальной задачей всех образовательных учреждений.
Образовательное учреждение в качестве объекта автоматизации можно рассматривать как специальный вид производственного предприятия, основным продуктом которого являются выпускники учебного заведения. Поэтому в решениях 1, предлагающих комплексную автоматизацию образовательных учреждений (ОУ) часто выделяются две группы компонентов: компоненты поддержки основных управленческих задач и компоненты управления учебным процессом, отражающие специфику ОУ.
Примерный состав автоматизированной системы управления образовательных учреждением (АСУ ОУ) может быть представлен набором следующих компонентов:
• портал руководства ОУ;
• подсистема управления персоналом;
• подсистема планово-финансового управления;
• подсистема бухгалтерского учета;
• подсистема учебно-методического управления;
• подсистема приема и обучения;
• подсистема административно-хозяйственного управления.
В зависимости от структуры ОУ и уровня его автоматизации перечисленные подсистемы могут содержать расширенный или более узкий набор функциональных модулей, а также дополнительные подсистемы, такие, например, как научно-исследовательская работа, редак-ционно-издательская деятельность, профком студентов.
Рынок систем комплексной автоматизации образовательных учреждений не очень объемный. Большинство систем, позиционирующихся как системы автоматизации ОУ, содержат в основном компоненты, автоматизирующие учебный процесс 2.
* Работа поддержана грантами РФФИ № 09-07-00277-а, 08-07-00229-а, 07-07-00271-а.
1 См. об этом: Галактика Управление вузом (корпорация «Галактика») - http://www.galaktika.by/pages.php?pid=688.
2 См. подробнее об этом: eduCORE - Комплексная информационная система управления учебным заведением (научно-производственный комплекс «ФАТУМ»): http://www.educore.ru/; Naumen University (компания «Naumen»): http://www.naumen.ru/go/solutions/naumen_university; Система комплексной автоматизации учебного процесса «GS-Ведомости» (компания ООО «Гуру-Софт»): http://vedomosti.guru-soft.ru/about.
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2009. Том 7, выпуск 3 © В. О. Демиш, Б. Н. Пищик, Г. Г. Козьменко, 2009
Можно отметить, что на нем присутствуют предложения как от крупных ИТ-компаний (корпорация «Галактика»; компания «Naumen»), на основе их продуктов для автоматизации бизнес-процессов и управления деятельностью предприятий, так и фирм, разработавших специальные решения (компания ООО «Гуру-Софт»).
Для ОУ, начинающих комплексную автоматизацию или готовых к радикальному реинжинирингу своих систем автоматизации, компании предлагают современные интеграционные платформы [1; 2], основанные, как правило, на продуктах фирмы для создания корпоративных информационных систем.
В некоторых образовательных учреждениях созданы собственные системы комплексной автоматизации .
Таким образом, для автоматизации управления ОУ есть много вариантов решений, в той или иной степени подходящих конкретному учреждению. Однако фирмы пока не предлагают типового продукта, решающего все задачи автоматизации ОУ. Образовательное учреждение может иметь достаточно сложную структуру, имея в подчинении множество специфических структур: производственные отделы (например, собственный редакционно-издательский центр), столовые, точки розничной продажи и т. д. Специфику каждого ОУ очень трудно заранее предусмотреть и реализовать в готовом решении (или это решение будет очень сложным и объемным). Поэтому важной характеристикой средств автоматизации крупных ОУ является наличие в них не только компонентов, реализующих базовые бизнес-процессы, но компонентов, обеспечивающих наименее трудоемкое (по сравнению с другими системами) сопровождение и последующий реинжиниринг.
История проблем автоматизации НГУ
На примере Новосибирского государственного университета, как крупного образовательного учреждения, можно продемонстрировать основные проблемы, возникающие при автоматизации ОУ.
Автоматизация управленческих задач НГУ началась в 1975 г. с использования расчетных программ на М-222. В 1979 г. расчет зарплаты был переведен на ЕС ЭВМ.
С 1994 г. в связи с переходом на персональные компьютеры были введены в эксплуатацию продукты фирмы «Базис»: Зарплата, Стипендия, Банк, Касса, Дебиторы (все разработаны на FoxPro).
В этом же году сотрудниками отдела «информационных систем» был разработан и внедрен программный продукт, решающий задачи учета материалов и основных средств, а в 1996 г. была внедрена система ИНФОНЕТ, решающая задачу кадрового учета (в том числе и профессорско-преподавательского состава). Все указанные разработки сделаны в актуальной на тот период среде: операционной системе MS-DOS и СУБД Paradox.
Поскольку для автоматизации разных процессов использовались различные программные продукты, постоянно росла сложность задачи обмена информацией между ними. А независимое друг от друга использование этих продуктов не решало задачи автоматизации в целом. Кроме того, средства их реализации (Borland Paradox, FoxPro) к определенному моменту стали критически отставать от прогрессирующего аппаратного оборудования и стремительно развивающихся новых информационных технологий. По этой причине в 2004 г. было принято решение о переводе системы на современную платформу, которая позволила бы реализовать все нужные для автоматизации компоненты и обеспечить достаточную производительность.
Как отмечалось выше, комплексную систему автоматизации ОУ часто делят на 2 подсистемы: подсистема основных управленческих задач и подсистема управления учебным процессом.
3 См. подробнее об этом: Управление учебным заведением (консалтинговая группа «GAVAH»): http://gavah.com.ua/ru/sales/soft//.
Сложность реализации комплексной системы автоматизации НГУ в рамках единой инструментальной среды и необходимость сокращения сроков запуска в эксплуатацию основных управленческих задач явились причиной появления двух проектов.
Реинжиниринг подсистемы управления учебным процессом завершился реализацией сотрудниками отдела «открытых систем» ЦНИТ НГУ в 2006 г. университетской информационной системой (УИС) 4. Среда реализации - Java и СУБД DB2.
Для реализации подсистемы основных управленческих задач была выбрана платформа 1С: Предприятие .
Возможность использования типовых прикладных решений от 1С для этой платформы позволила избежать необходимости решать большинство стандартных задач автоматизации. К сожалению, на тот момент не было готовых решений для использования на бюджетных предприятиях (таковые появились лишь в 2009 г.). Из существующих разработок за основу была взята конфигурация 1С «Управление производственным предприятием» (УПП) 6. УПП является прикладным решением, охватывающим основные контуры управления и учета на производственном предприятии.
Для перевода конфигурации на бюджетный бухгалтерский учет, а также для других работ по изменению УПП, связанных с ее использованием в НГУ, были привлечены сторонние специалисты. После сдачи разработанных блоков их сопровождением и модификацией занимается отдел информационных систем НГУ (ОИС). Ниже коснемся множества проблем, возникающих при передаче готовых блоков на сопровождение.
Специфические проблемы различных подсистем
Рассмотрим специфику и сложность разработки различных подсистем, автоматизирующих ту или иную часть работы университета.
Выделим основные блоки системы автоматизации.
1. Бюджетный бухгалтерский учет.
2. Управление персоналом (учет кадров и планово-финансовое управление).
3. Расчет зарплаты.
4. Платные услуги.
5. Стипендия.
Эти блоки (за исключением блока расчета зарплаты, находящегося сейчас на стадии завершающего тестирования) внедрены в НГУ и находятся на сопровождении отдела ОИС. Помимо этого, составлен набор заданий по налоговому учету, разрабатывается блок по работе с аспирантурой, а также производственный блок редакционно-издательского центра.
Блок расчета стипендии является наименее объемным из перечисленных выше и проблемы его сопровождения являются общими для всех блоков.
Для платных услуг стоит отметить потенциальную опасность дублирования одних и тех же данных при вводе информации и, как следствие, недостоверность информации по оплате услуг.
Наиболее крупными и трудоемкими в плане сопровождения являются первые три блока. Поэтому проведем обзор проблем, стоящих при их первоначальной разработке, и остановимся на проблемах сопровождения.
Бюджетный бухгалтерский учет
Основную структуру подсистемы бухгалтерского учета (в том виде, в котором она реализована в УПП) можно схематично изобразить следующим образом (рис. 1).
4 См.: Университетская информационная система «УИС» - http://uis.nsu.ru/.
5 См.: Платформа 1С: Предприятие 8: http://www.v8.1c.ru/overview/.
6 См.: Конфигурация «Управление производственным предприятием» - http://v8.1c.ru/enterprise/.
План счетов
Общие модули
А
Документы
Регистр бухгалтерии
[ > Отчеты
Рис. 1. Общая структура подсистемы бухгалтерского учета
При обращении к общим модулям, в которых определены основные операции по формированию бухгалтерских проводок (в соответствии с заданным планом счетов), документы формируют нужные движения в регистре бухгалтерии, после чего информация становится доступной для различных отчетов.
Таким образом, для перевода на бюджет изменения должны быть внесены во все элементы этой схемы. И, несомненно, это очень трудоемкая и объемная задача. Достаточно сказать, что в бухгалтерском учете используется порядка 90 типов документов, не считая постоянно пополняющегося списка используемых отчетов.
Сопровождение блока бухгалтерского учета - тоже весьма не простая задача. Бухгалтерский учет не является стационарным, окончательно сформировавшимся аппаратом. Периодически меняются самые разные его составляющие - от незначительных изменений в форме отчетности до внесения ключевых изменений непосредственно в план счетов. Ситуация усложняется еще и тем, что подобные изменения должны функционировать с определенной даты, ни коим образом не отражаясь на всех операциях, производимых до этой даты. А совершение операций «задним числом» в бухгалтерском учете неизбежно. Зачастую и сами изменения учета, принимаемые Правительством, требуют внедрения задним числом.
Выделим сложности исправления ошибок в программной реализации блока бухгалтерского учета. Такие ошибки могут быть выявлены после нескольких лет эксплуатации, а их исправление может потребовать объемной работы с документами прошлых периодов.
Рассмотрим наиболее крупные проблемы, которые возникали в процессе сопровождения.
• Изменяющиеся формы годовой отчетности
В декабре 2007 г. были приняты новые формы годовой отчетности по бухгалтерскому балансу. Внесенные изменения потребовали реализации совершенно новых отчетов. Поскольку конец года характеризуется массовыми исправлениями бухгалтерских ошибок, допущенных в течение года, а сдача годового отчета происходит в январе, внедрение новой отчетности потребовало особого внимания и значительных ресурсов.
• Источники финансирования и коды бюджетной классификации
Не вдаваясь в подробности бухгалтерского учета, можно рассматривать источники финансирования (ИФ) и коды бюджетной классификации (КБК) как различные сущности в финансовой деятельности организации. Они являются одними из основных в подсистеме бухгалтерского учета. Изначально полагалось, что они связаны отношением «один к одному», однако с января 2008 г. вышло постановление, в соответствии с которым в разные временные периоды с одним ИФ могут быть связаны различные КБК. Проблема вполне понятная, однако, чтобы ее окончательно разрешить, требуется внесение изменений во все места использования сущностей ИФ и КБК в исходном коде конфигурации. А используются они практически во всех элементах блока бухгалтерского учета.
• Изменения в соответствии с новой бюджетной инструкцией
В марте 2009 г. принята новая бюджетная инструкция, действующая с января (!) 2009 г. В соответствии с этой инструкцией изменяется план счетов (добавляются новые счета и модифицируются некоторые имеющиеся), а также изменяется ряд правил формирования бухгалтерских проводок. Значительно прибавляет трудоемкости необходимость работы системы при обращении к операциям более ранних периодов (до 2009 г.) «по старым порядкам», а также требование перехода на новую инструкцию первым января 2009 г.
В процессе решения первой проблемы в существующей конфигурации был выявлен ряд проблемных мест, которые являются причиной большинства ошибок, совершающихся бухгалтерами. Стоит выделить частое отсутствие необходимых проверок вводимой пользователем информации в формах документов, а также неудовлетворительно реализованный процесс оплаты (и получения) товаров и услуг поставщиков. Из-за неверного учета авансовых платежей и получения товаров и услуг в регистре бухгалтерии формируется множество неправильных проводок, которые в итоге ведут к путанице при сдаче отчетов. Алгоритмы решения этих проблем спроектированы в отделе информационных систем ЦНИТ НГУ и в настоящий момент внедряются в текущую конфигурацию.
При решении проблем, связанных с порядком ведения бухгалтерского учета, возникает множество сложностей, причина которых - недостаточная гибкость существующей структуры данных, в особенности отсутствие привязки большинства имеющихся в системе связей к конкретной дате. Разумеется, изначально разработчики и не предполагали, что когда-нибудь в будущем такая привязка может понадобиться (см. проблему источников финансирования и кодов бюджетной классификации). И сейчас достаточно сложно изменить существующую систему для предоставления требуемой гибкости (впрочем, в полной мере это было бы лишним). Чтобы впредь возникало как можно меньше подобных проблем, все разработки, внедряемые отделом информационных систем, проектируются с учетом расширения их функциональности в дальнейшем, а не только с целью непосредственного разрешения стоящей задачи.
Управление персоналом
Управление персоналом представлено двумя подсистемами - подсистемой кадрового учета и подсистемой планово-финансового управления. При внедрении, разработчиками были существенно переписаны многие ключевые моменты этих подсистем, реализованные в типовой конфигурации. Одним из разработчиков, внедряющих блок управления персоналом, была написана статья , в которой отражены все замечания по этому блоку, возникшие в процессе его внедрения. Указанные замечания касаются многих документов кадрового учета, поддержки внутреннего совместительства, возможностей настройки учетной политики и перемещений сотрудников.
Особенности в управление персоналом привносит профессорско-преподавательский состав, работа с которым отличается от других категорий персонала.
Сопровождение этого блока существенно осложнилось наличием множества ошибок и недоработок, допущенных сторонними разработчиками, осуществлявшими внедрение. В качестве примера можно привести неверные алгоритмы расчета количества дней отпуска, наличие ошибок при нескольких кадровых перемещениях работников. Из недоработок стоит выделить отсутствие документов отмены некоторых кадровых приказов, отсутствие возможности хранить историю структуры подразделений. Но многие подобные ошибки и недоработки обусловлены не ошибками разработчиков, а неточностями в формулировках наборов заданий, а также их недостаточной полнотой.
Путем правки структур данных и программного кода сотрудниками отдела информационных систем реализованы недостающие документы отмены кадровых приказов, добавлена
7 См. подробнее: Регламентированный учет кадров и штатное расписание в подсистеме «Управление персоналом» конфигурации УПП - http://www.klerk.ru/soft/1c/796956.
возможность хранения истории структуры подразделения. Алгоритмы расчета количества дней отпуска анализируются и исправляются в настоящее время (их сложность заключается в большом количестве отпусков без содержания у сотрудников университета).
Осуществляемый переход на новую систему оплаты труда (исключение разрядов ЕТС и введение квалификационных групп) в конце 2008 г. поставил новую задачу для группы сопровождения. Наряду с изменениями структуры, связанными с разрядами ЕТС и квалификационными группами, необходимо было сделать также значительные изменения в структуре подразделений, осуществить множество кадровых перемещений с учетом измененных подразделений и осуществить изменение ряда плановых окладов и надбавок. Для решения этих задач нужным образом была изменена структура данных и разработан инструмент для сотрудников планово-финансового управления, который позволил значительно ускорить изменение данных и сохранить все соответствия между старой и новой системами оплаты труда. Для того чтобы произвести требуемые изменения в структуре подразделений университета, был оперативно разработан и внедрен механизм ведения истории подразделений (включая историю их иерархии).
После перехода на новую систему оплаты труда в отделе информационных систем спроектированы нужные структуры данных и алгоритмы учета доплат и надбавок по штатному расписанию, вводимых сотрудниками планового отдела. До внедрения такого механизма установка этих доплат работникам происходила путем ручного ввода сотрудниками отдела кадров.
Также в направлении автоматизации учета надбавок был принят еще один шаг: устанавливаемые министерством доплаты и надбавки определенным должностям в определенном размере на некоторый период ранее вводились сотрудниками планового отдела. Им приходилось отслеживать вручную все приемы на работу сотрудников в заданном периоде, чтобы в случае необходимости произвести назначение положенной надбавки. В настоящее время для работы с такими постановлениями министерства разработан специальный документ, автоматизирующий все указанные операции.
Расчет зарплаты
Подсистема расчета зарплаты разрабатывалась внешним исполнителем около 3 лет. Еще около года длилось внедрение, в течение которого расчет проводился параллельно: в основной программе расчета зарплаты «Зарплата» фирмы «Базис» и во внедряемой системе расчета зарплаты на основе 1С УПП, в которую загружались некоторые результаты расчета из основной программы (для расчета средних значений). Сравнение результатов расчета зарплаты во внедряемой системе и в программе «Зарплата» потребовало написаний специальных модулей для обмена информацией между этими системами. Ввиду серьезных различий в структурах хранения информации реализация такого обмена оказалась непредвиденно трудоемкой. С января 2009 г. расчет зарплаты в НГУ ведется только в системе на основе 1С УПП , однако и сейчас еще вносятся изменения в отдельные виды расчетов.
Расчет зарплаты - наиболее сложная составляющая системы автоматизации. Изобилие используемых в расчете доплат и надбавок (на настоящий момент в системе введено порядка 150 доплат и надбавок) со сложными отношениями зависимости и вытеснения требуют аккуратной и точной настройки. Присутствует необходимость учета изменений задним числом, например, при предъявлении работником - кандидатом наук - диплома доктора наук, выданного гораздо раньше даты его предъявления. Помимо этого, может возникнуть необходимость непосредственной установки определенной доплаты или надбавки задним числом, например, по постановлению правительства. Для профессорско-преподавательского состава снова имеются специфические правила расчета, связанные с ученым званием и учебной степенью работников и с получением компенсации на приобретение книг.
Стоит отметить непростые алгоритмы расчета налогов (в особенности это касается ЕСН), которые, наряду с добавлением в зарплату бюджетной аналитики, еще больше усложнили этот блок.
Поскольку ошибки в расчете зарплаты чреваты, по меньшей мере, недовольством работников, которым не начислили нужной суммы и которые могут обратиться в суд, блок расчета зарплаты требует к себе особого внимания.
Заметим, что расчет зарплаты тесно связан с блоком управления персоналом, поскольку в последнем происходит назначение окладов и надбавок сотрудникам. По этой причине все ошибки кадрового учета автоматически проецируются на расчет зарплаты. Примером таких ситуаций являются удвоенные надбавки, которые рассчитаны на основании ошибок в установленных кадровых надбавках. Все такие ошибки в данных были выявлены в процессе первой стадии тестирования подсистемы, в ходе которой была рассчитана зарплата за месяцы второй половины 2008 г. На основании найденных ошибок сторонними разработчиками совместно с отделом информационных систем был разработан и внедрен ряд алгоритмов, исключающих появление дублирующихся доплат и надбавок.
Так как блок еще не сдан в производственную эксплуатацию сторонним разработчиком, большая часть модификаций блока по-прежнему осуществляется его силами. Отдельно нужно сказать о частой необходимости формирования нерегламентированных отчетов по результатам расчета заработной платы и численности работников, требующихся в разрезах различной аналитики. Долгое время такие отчеты формировались работниками отдела информационных систем, поскольку каждый новый требуемый отчет заметно отличался от предыдущих. В настоящее время разрабатывается средство, которое позволит работникам планового отдела самостоятельно формировать отчеты произвольной сложности и тем самым значительно уменьшит долю участия в этом процессе сотрудников отдела информационных систем.
Но в ближайшем будущем уже видна первая серьезная задача сопровождения блока расчета зарплаты: решением правительства в 2010 г. кардинально изменяется алгоритм расчета ЕСН, т. е. сразу же после опубликования нового алгоритма нужно провести изменения в рабочей системе, чтобы реализовать его.
Некоторые подходы к решению проблем
Вне зависимости от семантики рассматриваемых подсистем можно выделить ряд общих проблем, которые значительно усложняют сопровождение. Подобные проблемы в той или иной мере стоят перед любой группой сопровождения информационных систем, связанных с автоматизацией относительно крупных ОУ.
В первую очередь стоит отметить постоянные изменения в сопровождаемых продуктах не только из-за новых требований заказчика и исправления обнаруженных ошибок, но и ввиду постоянно меняющегося законодательства. И такие изменения зачастую (см. информацию по подсистемам) носят довольно масштабный характер. В связи с этим желательно, чтобы внедряемые разработки были спроектированы с учетом дальнейшего расширения их функциональных возможностей. От назначения и места компонентов в общей системе может зависеть подход к проектированию его структуры. Но в любом случае необходимо очень ответственно подходить к проектированию связей между сущностями, так как возможно, что в дальнейшем их потребуется изменить, не потеряв при этом имеющиеся данные.
Для того чтобы позволить разработчикам оперативно изменять работающую систему, у них должны быть все необходимые инструменты. Это мощная платформа, многофункциональная среда разработки, возможности для коллективной разработки. Дополнительным плюсом будет использование средств, которые направлены именно на решение учетных задач, а не произвольных. Таковыми, например, являются средства, поддерживающие предметно-ориентированное программирование 8. При таком подходе разработчику нет необходимости останавливаться на такие технические подробности, как организация взаимодействия с базой данных, обработка транзакционных блокировок, нюансы программирования экранных форм и т. д. Вместо этого он может полностью сосредоточиться на создании бизнес-логики приложения.
8 См. подробнее об этом: Парадигма предметно-ориентированного программирования в «1С: Предприятие 8» - http://www.1c.ru/rus/partners/training/edu/conf8/th/mare.pdf.
Без грамотного управления разработкой, регламентированного и обязательного процесса составления документации по всем внедряемым решениям, сложность сопровождения неоправданно возрастает. В процессе автоматизации НГУ участвовали разные люди, которые со временем менялись. Требование ведения документации по их работе отсутствовало, поэтому единственной документацией по имеющимся разработкам являются наборы заданий, изначально поставленные заказчиком, а также инструкции для пользователей. Наборы заданий зачастую сильно разнятся с окончательно разработанным продуктом, поэтому их затруднительно использовать в работе. В итоге недостаточная документированность стала заметным катализатором всех возникающих проблем сопровождения, поскольку каждому новому работнику приходилось знакомиться с системой непосредственно по ее исходному коду.
Для автоматизации управления разработкой программного обеспечения в отделе информационных систем НГУ в настоящее время создается система, позволяющая решить все стоящие проблемы управления задачами и ресурсами, составления документации, а также взаимодействия с пользователями. Ее архитектура поясняется на рис. 2.
Сервер системы
МБза.^ Ро&^вЭСП.! Файловая база
Прямой дос гул
Системе аэгоилттацмн
лровкгэ разработки ПО
доступ
| Система ведан ид документации
Доступ * системе доку мен таци*
Ёа б-сервер
Доступ черв) Л/еЬ-сераисы
□
Модуль дли сети с разработчиками
Разрабатываемое пршюнемне
I:'
Разработчик Раэрабогчш Разработчик
Разработчик
Пользователь Пользователь Пользователь
Рис. 2. Архитектура разрабатываемой системы управления проектами
Предлагаемая система откроет разработчикам различные способы работы: прямой доступ непосредственно через клиента 1С, Web-доступ через браузер, доступ к системе ведения документации. Также будет доступна работы с системой через Web-сервисы. Важным моментом является использование модуля для связи с разработчиками, который встраивается в разрабатываемое приложение (в нашем случае это система автоматизации ОУ) и позволяет пользователям общаться с разработчиками, не покидая привычное для них рабочее окружение: указывать на недоработки программы или необходимость расширения функционала.
Описание проблематики управления проектами и рассмотрение предлагаемой системы лежит вне этой статьи, отметим только, что в этой системе планируется использование технологии управления бизнес-процессами 9, которая позволит использовать модели бизнес-процессов для формального описания процессов сопровождения, а также использование сторонних систем ведения документов, основанных на вики-движках.
Заключение
Обобщая все вышесказанное, на основании опыта Новосибирского государственного университета, можно сформулировать ряд рекомендаций для тех, кто планирует внедрение сис-
9 См. об этом: Программы для управления бизнес процессами, процессное управление, автоматизация бизнес-процессов - http://bpms.ru/.
тем автоматизации в образовательном учреждении. Эти рекомендации касаются самостоятельной разработки системы автоматизации. В том случае, если планируется использование готового средства, нужно максимально строго подойти к оценке заложенных в нем возможностей адаптации к изменениям в законодательстве и новым задачам конкретного образовательного учреждения.
Рекомендации для разработчиков:
• выбранная для работы платформа должна поддерживать коллективную разработку, позволять разрабатывать клиент-серверные приложения и обеспечивать возможность использования общепринятых современных технологий (например, таких как использование XML-документов, Web-сервисов , возможностей Web-доступа и т. д.). Использование предметно-ориентированного подхода является преимуществом платформы;
• все разработки от проектирования до окончательной реализации должны производиться с учетом возможного изменения в дальнейшем, за исключением разработки априорно неизменных блоков;
• необходима единая система ведения документации по системе автоматизации, которая должна использоваться всеми разработчиками, включая и внештатных;
• для всех ключевых сущностей в системе должен быть определен набор правил, исключающих (или хотя бы значительно уменьшающих) вероятность дублирования данных. Также должен быть разработан инструмент для исключения существующих «дублей», если таковые все же появились;
• если планируется совместно использовать несколько программных продуктов и осуществлять обмен данными между ними, то нужно с особой внимательностью исследовать структуры данных, используемые в этих продуктах, и лишь затем строить планы обмена. Зачастую задача обмена недооценивается и в итоге существенно тормозит реализацию проекта в целом, поэтому к ней нужно относиться с должным вниманием;
• желательно использование системы управления проектами, с целью достижения определенности в управлении задачами разработки системы автоматизации;
• относительно новое направление в информационных технологиях - системы управления бизнес-процессам. Использование методик этого направления в больших системах является их несомненным плюсом.
Список литературы:
1. Голосов А., Полотнюк И., Филиппович А. Автоматизация образовательных учреждений на базе интеграционной платформы // e-Learning World. 2006. № 2-3. C. 48-52; [Электронный ресурс]. Режим доступа: http://www.elw.ru/magazine/18/9/.
2. Голосов А., Полотнюк И., Филиппович А. Автоматизация образовательных учреждений на базе интеграционной платформы // e-Learning World. 2006. № 4. [Электронный ресурс]. Режим доступа: http://www.elw.ru/magazine/19/167.
Материал поступил в редколлегию 15.05.2009
V. O. Demish, B. N. Pischik, G. G. Koz'menko PROBLEMS OF AUTOMATION OF MANAGEMENT OF EDUCATIONAL INSTITUTION.
Automation of educational institutions - actual and a challenge problem, which dares now various ways in many establishments. On an example of Novosibirsk state university specificity of such automation is considered. Problems of working out and support of the software for the decision of the basic administrative problems, including book keeping, management of the personnel and salary calculation are discussed. Being based on experience of information systems department of Novosibirsk state university, a number of recommendations about automation of educational institutions is given.
Keywords: automation of educational institutions, a technological platform of automation, administrative problems of educational institution, management of educational process.
