Формирование электронного образования как информационно технологической услуги

Таким образом, отсутствие единого подхода к внедрению системы eFront как LMS в НИУ ВШЭ приводит к лишним затратам, трудностям внедрения, реализации, эксплуатации системы, что еще раз подчеркивает актуальность проблемы поддержки очного образования электронными системами и необходимость управления и поддержки системы как ИТ-услугой в соответствие со стандартами, библиотеками лучших практик.

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

- административные процессы (в том числе мониторинг успеваемости, составление расписание, назначение преподавателей, формирование групп, ведение отчетности и пр.);

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

- процессы управления пользователями (регистрация, определение прав доступа и др.).

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

6.2 Описание бизнес-процессов автоматизированных систем поддержки e-learning (LMS)

"Бизнес-процесс - совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующая "входы" в "выходы", представляющие ценность для потребителя" [5]. К бизнес-процессам систем LMS относят те процессы, которые в первую очередь связаны с прохождением курса, подготовкой к нему, административным сопровождением и поддержкой. Для описания бизнес-процессов необходимо в первую очередь определить клиентов ИТ-услуги и окружение. Клиенты, использующие LMS, могут быть как внутренние (весь персонал ВУЗа, преподавательский состав, отделы, департаменты, студенты, владельцы других бизнес-процессов и др.), так и внешние (абитуриенты, поставщики, партнеры и т.д.). Бизнес-процессы определены в соответствие с основным набором функций, которые предлагаются современными системами LMS, а также с необходимыми видами деятельности при прохождении обучения или отдельных курсов в классических университетах.

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

Управление учебным процессом содержит:

- прохождение курса (лекции, семинары, самостоятельные работы, экзамены, пересдачи);

- назначение преподавателей на курс, назначение студентов на курс, формирование групп слушателей, и т.д.;

- ведение электронной документации (электронные журналы оценок, зачетные книжки, ведомости);

- организация совместной работы и коммуникаций между пользователями;

- анализ успеваемости студентов, мониторинг прохождения курса;

- управление расписанием, календарем событий и т.д.;

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

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

Управление пользователями в системах LMS

Программным обеспечением для моделирования бизнес-процессов был выбран продукт Ramus Educational. Критериями выбора стала доступность, бесплатное распространение, построение моделей в нотации IDEF0, схожесть с более продвинутым аналогом - BPWin.

Диаграмма верхнего уровня (Приложение 17) является кросс-функциональной и представляет собой процесс автоматизации учебной деятельности. Автоматизация учебной деятельности заключается в использовании систем LMS и взаимосвязанных с ней различных баз данных и других информационных и управленческих систем, которые подаются как механизмы. Данный процесс является частью портфеля ИТ-услуг ВУЗа, представляющего e-learning. Как любую ИТ-услугу, необходимо разработать стратегию использования LMS, спроектировать каталог услуг LMS, корректно внедрить и эксплуатировать в соответствие с ЖЦ LMS (Приложение 18). Необходимо определить владельца бизнес-процесса автоматизации учебного процесса. В НИУ ВШЭ ответственным отделом назначена Дирекция информационных технологий (ДИТ). В персонал входят менеджеры, разработчики, инженеры, администраторы системы и др.

1 Построение стратегии

В каталог услуг LMS входят все программные приложения, информационные и управленческие системы, системы поддержки и др. Каталог услуг LMS можно представить в виде функциональных возможностей системы, наличие которых было проанализировано в сравнительном описании различных систем LMS, а именно услуги для административного персонала, связанные с ведением документации, преподавателей (загрузка материалов, тестов), студентов (личная страница, запись на курсы). Также в услуги LMS будут входить электронные журналы и зачетные книжки, электронная почта и другие средства коммуникаций, системы управления пользователями и т.д. Так как функциональность современных продуктов LMS является очень широкой, то, чтобы осуществить процесс построения стратегии и разработать стратегию автоматизации учебной деятельности, необходимо ответить на вопросы, поставленные на этапе "Построение стратегии выбора и внедрения LMS". Пример, к сторонам внешней среды НИУ ВШЭ относятся экономическое развитие страны, заинтересованность государства в подготовки специалистов определенных сфер, наиболее востребованные профессии на бирже труда, направленность научной деятельности, увеличение желающих получить высшее образование и их возможности. В ходе маркетинговых исследований выявляются желания абитуриентов и их причины выбора ВУЗа. Определив общую направленность деятельности ВУЗа, можно начать подготовку к внедрению LMS, чтобы улучшить качество образования и перейти на уровень e-learning. В ходе анализа решений LMS, НИУ ВШЭ выбрал платформу eFront, которую ВУЗ и интегрировал в учебную среду. Главной целью системы онлайн поддержки учебного процесса НИУ ВШЭ поставил повышение уровня и качества методической, дидактической, информационной поддержки организации учебного процесса для студентов, преподавателей и административных работников факультетов []. Далее измеряются показатели, чтобы посмотреть и сравнить пользу, получаемую от системы с затратами на ее поддержку. Если выгоды от использования системы оказывается больше, то необходимо решить, будет ли ВУЗ самостоятельно внедрять и поддерживать систему или пользоваться услугами аутсосрсинга. Процесс заканчивается разработанной стратегией внедрения и использования системы, а вход будет преобразован в каталог услуг LMS, то есть в желаемые функциональные возможности системы и реализованные требования с учетом имеющихся ресурсов.

2 Процесс проектирования

Каталог услуг является входом процесса проектирования LMS. Данный этап будет декомпозироваться на следующие бизнес-процессы: проектирования технологий, проектирование поддерживающих процессов, проектирование методов и метрик измерений и формирование проекта LMS (Приложение 19).

Проектирование технологий согласно ITIL - это проектирование архитектуры услуг, приложений, данных, инфраструктуры. "Архитектура - фундаментальная структура системы, отображающая ее компоненты, их взаимодействие друг с другом и условия эксплуатации системы, а также принципы, лежащие в основе проектирования и развития системы" [15]. Архитектура услуг транслирует всю деятельность системы в набор услуг, то есть представляет собой интегрированный в ВУЗ подход для представления услуг клиентам. Архитектура приложений отражает функциональные возможности LMS и максимизирует повторное использование системы и ее компонентов. Архитектура данных (информации) описывает логические и физические информационные активы ВУЗа (набор курсов, информация о пользователях, пароли, конфигурации, данные проверок и т.д.). Архитектура инфраструктуры описывает структуру и географические расположение программного и аппаратного обеспечения (количество и расположение серверов, прокладка сетей, установление операционных систем и т.д.). В качестве ИТ-инфраструктуры будут использоваться различные ПО, АП, базы данных, сервера для разработки архитектур. В качестве владельца бизнес-процесса назначается руководитель процесса, а основным персоналом будет выступать команда разработчиков.

Управление поддерживающими процессами было декомпозировано до уровня применения непосредственно процессов ITSM: управление уровнем услуг LMS, управление мощностями, доступностью, непрерывностью (Приложение 20). Также сюда входит процесс управления информационной безопасностью, который строится с рекомендациями ITIL и ИСО 27000.

Уровень ИТ-услуги измеряется параметрами качества и объема услуг. Управление уровнем услуг содержит услуги, видимые для клиентов-пользователей, а также технический каталог услуг, содержащий все конфигурационные единицы LMS. Выходом является система отчетности об услугах, содержащая информацию об удовлетворенности потребителей, производительность, планы совершенствования услуг, запланированные изменения, согласованность с требованиями заказчиков и т.д. Примером в отношении LMS могут являться требования к услуге электронной почты внутри системы: входящая почта (размером менее 2 K) должна доставляться в электронный ящик пользователя менее чем через минуту после получения (производительность), с учетом того, что в день поступает более 10 000 писем. Или требование к самой LMS: система должна работать 99,9% времени (доступность), то есть обговаривается время на техническое обслуживание 2 часа в месяц, чтобы все остальное время услуга была доступна. В качестве персонала будет назначены менеджеры для работы с заказчиками услуг LMS, то есть со всеми пользователями и стратегией ВУЗа.

Процесс управления мощностями включает в себя формирование отчетов о производительности и мощности услуг и элементов LMS на основе полученных отчетов об услугах, предоставление информации о необходимых обновлениях элементов ИТ-инфраструктуры, снижение рисков при обновлении каталога услуг с точки зрения технического оснащения, мощности аппаратных средств и др. На выходе процесса будет план обеспечения мощностей, содержащий сценарий для прогнозирования спроса на компоненты и услуги LMS, а значит нагрузки, и оценку затрат. Кроме того, на выходе формируется система управления мощностями (далее - СУМ) - виртуальное хранилище для всех данных мониторинга в рамках данного процесса, например, некоторая БД мощностей, хранящая все показатели производительности и система управления данной БД. Кроме того, в эту систему помещается информация, собранная на этапе эксплуатации системы, поступающая на вход процесса. Примером управления мощностями в рамках проектирования LMS может служить измерение нагрузки на систему (электронные зачетные книжки, почта, обращения к БД паролей и логинов) во время проведения экзаменов. В качестве персонала выступают менеджеры систем, сетей и приложений, которые не только следят за производительностью, но и отвечают за определение необходимых мощностей в будущем. В дополнение к ИТ-инфраструктуре добавляется БД мощностей как часть СУМ.

Процесс управления доступностью отвечает за то, чтобы вся инфраструктура, процессы, средства, роли и т.д. соответствовали показателям уровня услуг (связь с процессом управления уровнем услуг). В ходе процесса формируется план управления доступностью, который содержит требования к доступности услуги и ее компонентов, к надежности и др. Примером является время обращения к системе LMS и анализ простоев системы, несогласованных в процессе формирования уровня услуг. Также выходом процесса является система управления доступностью (далее - СУД), которая так же, как и СУМ, представляет собой физически распределенное хранилище для всех данных процессов, находящихся под контролем управления доступностью. Данное хранилище также будет частью ИТ-инфраструктуры ВУЗа. В качестве персонала может выступать та же команда менеджеров, что и в предыдущем процессе.

Процесс управления непрерывностью ответственен постоянное предоставление минимального согласованного уровня услуг (Приложение 21). Сюда же входят планы по восстановлению услуг, сценарии проведения тестирования и стратегия процесса непрерывностью услуг, которые в общем виде представляют собой подпроцесс управления непрерывностью ИТ-услуг LMS. Данный подпроцесс формирует планы соответствия каталога услуг и отчетов по их доступности (входы) с отчетами и требованиями уровня услуг. Вторым подпроцессом является идентификация угроз - возможных причин нежелательных инцидентов, наносящих ущерб. Угрозы являются причинами остановки оказания услуг, приводят к простою системы. Полученный на выходе каталог угроз является входом для процесса управления информационной безопасностью. Примером угрозы в LMS может быть кража паролей, из-за которой пользователь не может зайти в систему, то есть нарушается непрерывность услуги входа в систему LMS.

Последним процессом является управление информационной безопасностью (далее - ИБ), в ходе которой формируется политика ИБ, система управления ИБ (далее - СУИБ). Каталог рисков формируется на основе каталога угроз предыдущего процесса и активов ВУЗа (Приложение 22). Риски ВУЗа, связанные с использованием LMS, будут физическими, информационными (личные данные пользователей, разработанные материалы и др.) и аппаратного или программного обеспечения. Эти риски являются управляющими воздействиями для формирования каталога рисков, который является входом для СУИБ. "Система менеджмента информационной безопасности (СМИБ) представляет модель для создания, внедрения, функционирования, мониторинга, анализа, поддержки и улучшения защиты информационных активов для достижения деловых целей, основанную на оценке риска и на принятии уровней риска организации, разработанную для эффективного рассмотрения и управления рисками" [3]. Риски - сочетание вероятности события (угрозы) и его последствий, то есть необходимо качественно или количественно оценить последствия наступления нежелательных событий и поместить в каталог только те, которые представляют значительный ущерб для ВУЗа, чтобы выделить средства для минимизации рисков. Если угроза была связана с кражей паролей (угроза потери информации), то риском будет являться ущерб от потери такой информации. В LMS такая угроза является значительным риском, так как ущерб может быть связан с изменением внутренней информации, удалением, фальсификацией материалов, нарушением авторских прав (скачивание материалов) и т.д. Значит, данная угроза будет являться риском. В соответствие с СУИБ процент данного риска будет минимизироваться за счет применения различных средств защиты, политики ИБ (контролей). Для этого процесса формируется команда по управлению ИБ, включая аудиторов. Так как СУИБ включает в себя и политики, процессы, стандарты, и различные средства для защиты информации, то выход будет как управляющим воздействием (политики СУИБ) так и механизмом (инструментальные средства) для всех процессов LMS.

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

Последним процессом проектирования услуги является процесс проектирования методов и метрик измерений для сбора информации о прогрессе процессов, соответствия требованиям, результативности и эффективности. Данные методы могут использоваться для сбора информации в СУМ и СУД.

Таким образом, в ходе моделирования бизнес-процессов этапа проектирования были использованы четыре из десяти процессов ITSM, чтобы представить LMS в виде ИТ-услуги и дополнительные процессы, взятые на основе анализа ITIL и ИСО 27000.

3 Процесс внедрения LMS

Процесс декомпозируется на три составляющие согласно ITSM и ITIL: управление изменениями, конфигурациями и релизами (Приложение 23). Процесс внедрения является промежуточным звеном между проектированием и эксплуатацией, ответственен за преобразования в LMS.

Процесс управление изменениями принимает запросы на изменения со всех этапов ЖЦ, его процессов, клиентов системы. Примером запроса на изменение может быть запрос на смену пароля для входа на личную страницу LMS. После получения запроса определяется его приоритет, категория, проверка с проектной документацией, то есть возможностями (управление мощностей, наличие финансовых возможностей), требованиями уровня услуг, обеспечения непрерывности и доступности. По это причине одним из механизмов данного процесса являются базы данных мощностей и доступности. Информация об изменениях в свою очередь будет управляющим воздействием при разработке планов мощностей, доступности, непрерывности, а также ряда других процессов. Если продолжить пример запроса на смену пароля, то услуга будет доступна и непрерывна, если запрос был обработан быстро, все новые данные, а также данные о самом запросе были занесены в базы данных, для хранения новых данных достаточно места на серверах.

Процесс управления конфигурациями авторизует проведения изменений, заносит все данные в конфигурационную БД и обновляет ее. Выходом процесса является система управления конфигурациями (далее - СУК), в которую входит необходимые БД. Также в данной системе должна содержаться информация о связях между конфигурационными единицами (далее - КЕ). Все изменения связаны с КЕ, поэтому изменения регистрируются под контролем процесса управления конфигурациями. Управление конфигурациями определяет зависимость между КЕ, вовлеченной в проводимое изменение, и другими КЕ, чтобы определить, на какие другие элементы будет воздействовать это изменение. Процесс управления доступностью использует конфигурационную БД как механизм для определения конфигурационных единиц, задействованных в услуге, для составления плана изменений и для выявления слабых мест. Процесс управления мощностями использует данные из СУК для оптимизации ИТ-инфраструктуры, распределения рабочей нагрузки и разработки плана мощностей. Процесс управления непрерывностью использует стандартные конфигурации для формулирования требований к восстановлению услуг в случае возникновения чрезвычайных обстоятельств.

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

Все три процесса, описанные на этапе внедрения (преобразования) являются важнейшими процессами в ITSM.

4 Процесс эксплуатации LMS

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

Первая часть процесса эксплуатации связана с учебной деятельностью, которую можно автоматизировать с помощью LMS. В итоге были выделены процессы управления пользователями, прохождения курса, управления учебным процессом (администрирование) в соответствие с выделенными группами процессов раннее. Кроме того, были смоделированы процессы организации коммуникаций и формирования обращений по вопросам работы с системой (Приложение 26). На этом этапе важную роль играет интеграция спроектированной системы LMS с уже существующими системами. В НИУ ВШЭ такими системами являются АСАВ и РУЗ. Учетно-аналитическая системы управления учебным процессом (АСАВ) - используемая в ВШЭ электронная система сопровождения учебного процесса. С ее помощью составляются учебные планы, учитываются успеваемость студентов, нагрузка преподавателей и пр. Расписание учебных занятий (РУЗ) - электронная система планирования расписания учебных занятий на основании нагрузки преподавателей, запланированной в АСАВ.

Процесс управления пользователями в LMS декомпозируется на регистрацию в системе, определение прав и роли, а также формирование доступа к персональной странице пользователя (Приложение 26). Выходом процесса управления пользователями являются зарегистрированные пользователи с определенными ролями (администратор, преподаватель, студент). Регистрация в LMS в НИУ ВШЭ выполняется администратором системы. Для регистрации в системе LMS необходимо отправить заявку в свободной форме на адрес lms@hse.ru с указанием ФИО (полностью) и электронного почтового адреса. В ответ придет письмо с логином и паролем для входа на персональную страницу системы [8].

Процесс прохождения курса начинается с регистрации учебной дисциплины (Приложение 27). Для регистрации учебной дисциплины в НИУ ВШЭ, необходимо обратиться в службу поддержки пользователей по адресу lms@hse.ru, где указать название дисциплины по РУП, ступень обучения и целевую группу слушателей. РУП хранится в системе АСАВ. Регистрации дисциплины может также проводиться учебным администратором, но с разрешения системных администраторов и менеджеров при наличии определенных прав [8]. Процесс записи на курс имеет несколько форм: обязательный или факультативный. Тем не менее, выходом процесс является записанный или зарегистрированный на курс студент. Зарегистрировать студентов может сам преподаватель или учебный администратор с помощью LMS, обратившись в службу поддержки пользователей с заявкой, в которой указать номера групп студентов, факультет, а также курс. При подаче на вход дисциплины, студентов и преподавателей образуется учебная группа как выход процесса назначения преподавателей и студентов. Процесс изучения дисциплины включает в себя элементы смешанного обучения: очное обучение и электронного (Приложение 28). Изучение материалов, прохождение тестов, выполнение проектов выполняется в системе LMS. С помощью электронного журнала оценок из каталога LMS автоматизируется проставление оценок. LMS НИУ ВШЭ позволяет импортировать оценки из тестов, проектов в журнал оценок предмета. После прохождения экзамена в очном или электронном виде дисциплина считается изученной.

Процесс управления учебным процессом состоит из составления расписания занятий, анализа успеваемости и формирование текущей учебной документации (Приложение 29). В системе e-learning данные процессы должны быть автоматизированы с помощью LMS. Выход составления расписания является управляющим воздействием для процесса прохождения курса. Формирование текущей учебной документации включают хранение и обработка информации о ходе учебного процесса и его участниках. Заполнения ведомостей, зачетной книжки, расчет кредитов администраторами также являются частью данного процесса. Примером автоматизации является наличие электронной зачетной книжки как услуги LMS, где происходит подсчет кредитов. Преподаватель заполняет ведомость, относит в учебный офис. Менеджеры проставляют оценки в АСАВ, откуда результаты импортируются в LMS. Целью процесса анализа успехов является выявление, обоснование, проверка основных и сопутствующих факторов учебной успешности студентов, для разработки педагогических рекомендаций по оптимизации образовательного процесса и повышению учебной успешности студентов. Анализ успехов осуществляется с помощью статистических методов, а также опросов, анкетирования, которые составляются с помощью LMS. Общим выходом двух процессов является система отчетности.

Процесс коммуникаций включает в себя управления следующими услугами LMS: корпоративная электронная почта, чаты, обсуждения, форумы и т.д. В соответствие с функциональностью LMS НИУ ВШЭ были выделены процессы составления календаря ("Календарь"), объявлений ("Единое окно", "Объявления к дисциплине") и обмена сообщениями (корпоративная почта, форумы) (Приложение 30). Эти процессы отражают взаимодействие зарегистрированных пользователей в системе во время изучения дисциплины.

Последним процессом было выделено формирование обращений в службу поддержки по вопросам, связанным с работой в системе. В НИУ ВШЭ выделяется несколько подпроцессов: подача заявлений на консультацию, сообщение о неисправностях и запрос на обслуживание, предложения о доработке системы (Приложение 31). Эти обращения обрабатываются как в сервисной службе, как и обращения с других процессов. Все обращения являются инцидентами, это означает, что данные процессы связаны с процессом управления инцидентами.

Процессы поддержки представляют собой деятельность, выполняемую службой Service Desk (диспетчерская служба) (Приложение 32). Являясь точкой контакта с пользователями, служба Service Desk позволяет уменьшить нагрузку на другие ИТ-подразделения путем "перехвата" не относящихся к делу обращений и вопросов, на которые легко ответить. Служба Service Desk действует как фильтр, который пропускает звонки на вторую и третью линии поддержки, только когда это действительно необходимо. В рамках этой службы были выделены три процесса: сбор заявок на обслуживание, управление инцидентами и управление проблемами. Сбор заявок осуществляется в едином центре звонков (Call Centre), первая поддержка реализуется службой Help Desk, которая также является частью Service Desk. Кроме того, эта служба может участвовать в процессах управления изменениями, конфигурациями.

Процесс управления инцидентами принимает на вход ошибки аппаратного и программного обслуживания (сбои ИТ-инфраструктуры), а также любые запросы на обслуживание от клиентов-пользователей системы (запрос на смену пароля, загрузку материалов, получение доступа к базе данных и т.д.). "Инцидент (incident): Любое событие, которое не является частью стандартной операции услуги и которое вызывает или может вызвать прерывание или снижение качества предоставления услуги" [2]. На выходе данного процесса будут запросы на изменения, которые обрабатываются в процессе управления изменениями, отчеты по заявке и первоначальные рекомендации по обслуживанию запросов и решения проблем. Для сбора информации по инцидентам, их категорированию, статусу необходима БД инцидентов.

Процесс управления проблемами включает деятельность по определению причин возникновения инцидентов, особенно, если инциденты не являются запросами на обслуживание. "Проблема (problem): Неизвестная основная причина одного или нескольких инцидентов" [2]. На вход процесса поступают зарегистрированные инциденты, на выходе предлагаются обходные решения или запросы на изменения. Первоначально проверяется наличие инцидента в БД инцидентов и связанной с ней причиной в БД причин, чтобы предоставить скорейшее решение. Если инцидент является уникальным, то проводится работа по установлению возникновения причины в рамках этого процесса. В таком случае собирается информация с процессов управления мощностями, доступностью, конфигурациями, уровнем услуг для нахождения причины инцидента и решения проблемы. Решения проблем отправляются в процесс управления инцидентами, в котором этот вход преобразуется в рекомендации по устранению инцидентов. Данные рекомендации являются управляющими воздействиями в процессе деятельности единого центра звонков.

Главным итогом процесса эксплуатации является выход "Учебная деятельность автоматизирована", что и являлось изначальной целью проектирования системы LMS как части e-learning.

6.4.5 Процесс непрерывного улучшения

Последний этап ЖЦ сопровождает автоматизацию учебной деятельности и проектирование LMS на всех этапах и отвечает за управление улучшениями во всех процессах. Процесс имеет входы в виде собранной информации по всем процессам, услугам системы, которые преобразуются в рекомендации по совершенствованию оказания услуг e-learning. Улучшения происходят по циклу Деминга, который включает в себя 4 этапа по планированию, выполнению запланированных услуг и работ, проверке с целями и корректировке результатов.

6.5 Формирование организационно-функциональной ИТ-инфраструктуры автоматизированных систем поддержки e-learning

В ходе работы были выделены 3 крупных отдела ВУЗа: Дирекция информационных технологий, учебная часть и учебный департамент. ДИТ состоит из набора отделов или групп специалистов, ответственных за выполнения ряда процессов. Процесс автоматизации учебной деятельности является первым бизнес-процессом, он проходит через все три отдела. Вторым бизнес-процессом является изучение дисциплины, который имеет место на этапе эксплуатации LMS.

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

Рис. 16. Организационно-функциональная структура ВУЗа

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

7. Соотнесение организационно-функциональных подразделений ВУЗа с классическими службами ITSM

После построения карт процессов и отделов организационно-функциональной структуры ВУЗа при проектировании LCMS и LMS был сделан вывод о том, что большинство процессов, связанных с проектированием, внедрением и поддержкой систем, осуществляется в отделах Департамента информационных технологий. Кроме того, системы могут поддерживаться в рамках одного департамента, так как они являются взаимосвязанными (рис.17) [7].

Рис. 17. Процессы создания и управления контентом и автоматизации учебной деятельности

С другой стороны, ITSM предлагает классический подход к формированию организационных подразделений [4]. При помощи модели ITSM отделы ДИТ были соотнесены с организационными подразделениями (рис. 18). Несмотря на то, что отдела по качеству нет в подразделениях ITSM, непрерывное совершенствование является одним из принципов ИСО 9000, поэтому данный отдел необходим в структуре организации.

Рис. 18. Взаимосвязи и цели отделов ДИТ и служб ITSM

Заключение

В работе был сформирован подход к предоставлению электронного образования как ИТ-услуги с применением рекомендаций ITSM, моделирования бизнес-процессов, анализа жизненных циклов различных форматов обучения, с помощью которых можно определить организационно-функциональную ИТ-инфраструктуру ВУЗа, необходимые каталоги. Были описаны полного жизненные цикла классического образовательного процесса и e-learning; проведено сравнение e-learning с классическим образованием и сравнительный анализ образовательных структур e-learning; выделены основные бизнес-процессы e-learning.

Результатами части работы, посвященной системе разработки учебного контента являются:

- изученная предметная область LCMS путем сравнительного анализа систем ATutor, eXact Learning, Xyleme, Claro, GreenLight и определение их функциональных возможностей;

- выделенные жизненный цикл и основные бизнес-процессы связанные с проектированием и эксплуатацией LCMS, на основе которого выделены жизненный цикл и бизнес-процессы, связанные с разработкой эксплуатацией LCMS контента;