УДК 004.418

Проблемы внедрения информационных систем учета плановой нагрузки кафедры на примере Ухтинского государственного технического университета

Problems of implementation of information systems taking into account the planned workload of the department for example Ukhta State Technical University

О. В. Чернова

O. V. Chernova

Ухтинский государственный

технический университет, г. Ухта

Ukhta State

Technical University, Ukhta

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

This article tells about the difficulties of implementing the informational system of planned workload for department at the university as an example Ukhta State Technical University, analyzes the causes of inefficient use of the system, and suggests methods to reduce the likelihood of their occurrence.

Ключевые слова: вуз, нагрузка, информационная система, проблемы внедрения.

Keywords: university, capacity, information system, implementation problems.

Введение

С 2006 года в Ухтинском государственном техническом университете функционирует и развивается информационная система «УГТУ». В ее состав входит ряд подсистем, автоматизирующих ту или иную деятельность образовательного учреждения: приемная кампания, учет успеваемости студента, планирование и распределение нагрузки, составление расписания занятий и экзаменов и т.п. Подсистемы связаны между собой общими данными, процессами, поэтому деятельность, осуществляющаяся в одной подсистеме, может оказывать непосредственное воздействие на данные другой подсистемы. Например, все данные о поступивших студентах в подсистему «Деканат» поступают из подсистемы «Абитуриент», а при планировании нагрузки на кафедрах в подсистеме «Нагрузка» в первую очередь используются данные об учебных планах, которые заполняются в подсистеме «Деканат».

На текущий момент в ИС «УГТУ» стабильно и регламентировано функционируют только две подсистемы:  »Абитуриент» и «Деканат». На протяжение нескольких лет производится попытка внедрения в активное использование подсистем «Нагрузка» и «Расписание». Однако ряд факторов оказывают сильное воздействие на стабильную работу данных подсистем. И в первую очередь, это точность и определенность бизнес-процессов планирования нагрузки на кафедрах.

Анализ проблем внедрения

Среди подсистем ИС «УГТУ», для которых существуют проблемы внедрения, наиболее значимой является подсистема «Нагрузка», т.к. составление расписание целиком и полностью зависит от тех дисциплин, которые запланируют и распределят между преподавателями на кафедре.

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

Опрос, проводимый среди пользователей подсистемы «Нагрузка», в сочетании с журналом их обращений для разъяснения или разрешения неполадок в ходе использования подсистемы, показали следующую статистику причин возникновения проблемных ситуаций:

1) некорректный/неполный ввод исходных данных (учебных планов) – 75%;

2) некорректное использование ИС «Нагрузка» (указание неправильных норм, учебных планов для потоков) – 5%;

3) несогласованность в способах расчета нагрузки, возникновение частных случаев и правил для отдельных кафедр – 10 %;

4) ошибки в информационной подсистеме «Нагрузка» – 7%;

5) «личные барьеры» [2] – 3 %.

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

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

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

К классу «личные барьеры» [2] обычно относят сопротивление работников и руководителей (из-за страха перед неизвестным, потребности в гарантиях, когда под угрозой оказывается собственное рабочее место и др.), нежелание выполнять дополнительную работу. Данные проблемы разрешаются путем проведения для сотрудников соответствующих подразделений бесплатных семинаров, индивидуальных обучений и консультаций, организационных собраний. Данный вид услуг оказывается работниками группы разработки и сопровождения.

Самым сложным классом проблем, возникающих при эксплуатации подсистемы «Нагрузка», является третий класс: несогласованность в способах расчета нагрузки, возникновение частных случаев и правил для отдельных кафедр.

С одной стороны, весь расчет нагрузки четко регламентирован и определен. Заданы единые общие нормы времени для расчета, заполнен контингент обучающихся (количество групп/подгрупп, число обучающихся на бюджетной и контрактной основе), введены учебные планы.

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

  • Несмотря на то, что количество контрактников в потоке составляет величину, достаточную, чтобы отнести все аудиторные занятия данного потока на контрактную форму обучения, для определенной кафедры существуют протоколы или приказы ректора, согласно которым аудиторные занятия  продолжают числиться на бюджете.
  • Для дисциплины количество курсовых проектов может превышать установленную норму.
  • Некоторые кафедры округляют часы консультаций по каждой группе до целого числа.
  • Расчет времени по контрольным работам ведется вне установленного максимума: 1 час на все контрольные.
  • Схемы деления для проведения занятий определяются не по заданному контингенту, а в соответствии с аудиторными ограничениями на кафедре или даже в соответствии с «установленными традициями» и т.д.

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

Кроме того, процесс планирования нагрузки частично зависим от устанавливаемых правил и ФГОСов, которые могут видоизменяться и корректироваться постановлениями со стороны законодательных органов. Например, в 2012 году должен быть выпущен новый закон  »Об образовании», который может существенно повлиять на любой бизнес-процесс осуществления образовательной деятельности.

В условии существования правил, установленных для отдельных кафедр, затруднительным становится ситуация внедрения новых общих правил.

Методы разрешения конфликтных бизнес-процессов

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

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

  • Разработчик создает гибкую настраиваемую информационную систему с системой корректируемых правил. В случае гибкой и настраиваемой системы важно помнить, что система должна в целом упростить и уменьшить работу человека или хотя бы не сильно ее усложнить. Поэтому количество правил должно быть ограничено разумными пределами, а создание правил и их корректировка не стать дополнительной трудоемкой обязанностью пользователя системы.
  • Разработчик создает систему, где человек играет активную роль и ключевой и конечный выбор осуществляет самостоятельно. Этот вариант больше подходит для случаев поддержки принятия решений, которые иногда обоснованы лишь личным эмпирическим опытом ЛПР (лица, принимающего решение).
  • Если все правила осуществления бизнес процессов ясны, но достаточно сложны или запутаны, с большим или растущим списком исключений. Если процессы не оптимальны по ряду критериев, то здесь проигрывается вариант построения двух моделей управляемого объекта:
    • Модели «как есть» (As-Is)
    • Модели «как должно быть», «как будет» (To-Be).

    Сначала строится модель «As-Is». Эта модель отражает текущее состояние и движение бизнес-процессов. Такая модель необходима для анализа недостатков и сложных этапов, существующих в организации процессов. На основе этого анализа, в рамках подробного консультирования и по договору с Заказчиком строится модель процесса «To-Be». Это обычно более подробная и систематизированная схема того, как процессы будут построены в будущем и, соответственно, каким по каким правилам будет работать будущая информационная система. Чаще всего процессы во второй модели приводятся к более структурированному или оптимизированному виду.

    Соотнесем данную классификацию разрешения проблем с проблемами, возникшими при внедрении нагрузки.

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

    Если разрешать проблему с помощью варианта «Поддержки принятия решений», правила расчета нагрузки, в конечном итоге, становятся необязательными к исполнению, что недопустимо в существующем процессе.

    Остается третий вариант: сведение всего расчета нагрузки к единому варианту, без отклонений и исключений для отдельных кафедр. Это позволит:

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

    Кроме того, вариант «Единого стандарта расчетов» допускает установление определенной гибкости для расчета нагрузки. В случае изменений правил, которые будет вводить учебный отдел, вся нагрузка по всем кафедрам будет считаться по новой измененной схеме.

    Выводы

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

    Ключевым шагом в исправлении сложившейся ситуации должно стать построение модели расчета нагрузка «As-Is» с указанием всех исключений по каждой кафедре, которые существуют на сегодняшний день. Данную модель необходимо подвергнуть анализу в присутствии всех заинтересованных лиц и отделов университета, выдвинуть предложения по стандартизации и отмене исключений для отдельных кафедр, построить и установить в качестве стандартной модель «To-Be», которая станет в основу итоговой стандартизации и доработки системы.

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

    Библиографический список

  1. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Управление внедрением информационных систем. М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2008. – 224 с.: ил., табл. – (Серия «Основы информационных технологий»).
  2. Вестник Научно-исследовательского центра корпоративного права, управления и венчурного инвестирования Сыктывкарского государственного университета [Электронный ресурс] / Л.И. Бушуева. Проблемы внедрения корпоративных информационных систем. Режим
    доступа: http://koet.syktsu.ru/vestnik/2005/2005-3/10.htm,
    свободный. – Загл. с экрана.

 

Статья поступила в редакцию: 07.02.2012

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.17_1161]
Rating: 0 (from 0 votes)
VN:F [1.9.17_1161]
Стиль изложения
Информативность
Сложность вопроса
Научная новизна
Коммерциализуемость
Rating: 0.0/5 (0 votes cast)