Единая и неделимая образовательная среда

Заметки навеяны описанием Международного форума «Электронная образовательная среда: технологии, концепции, ресурсы, услуги».
(PS. Сам форум сначала перенесли с лета на осень, а потом и вовсе отменили)

(использована уменьшенная фотография челябинского метеорита со страницы автора)

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

Я обычно человек спокойный, но два словосочетания – «оценка качества образования» и «единая образовательная среда» (в любых и многочисленных вариациях) – превращают меня в челябинский метеорит. Правда, он стекла сумел побить в 100-км округе и пару заводов частично обвалить, а я только мелкую рябь по сети пускаю.

С определениями сейчас туго – каждый называет, что хочет, как может. Разных вариаций на эту тему много. Я не знаю, что такое «электронная образовательная среда» – она же «единое пространство», в котором живут «все, все, все», указанные через запятую. Я воспользуюсь термином, который не многим лучше, зато упомянут в законе и ФГОСах – информационная образовательная среда – ИОС. По мере приобретения ИОС статуса неотъемлемой части образовательной инфраструктуры, требования к ней становятся все более значимыми и критичными.

Попутно о «единой платформе» и прочих красивых словах, которые подразумевают множественное толкование. Закон Мерфи гласит: «Если неприятность может случиться, она случится». Если термин подразумевает несколько толкований, то регулярно придется сталкиваться именно с тем из них, которое никак не должно применяться. Обращаю внимание на неоднозначность понимания как отдельного слова «единая», так и в сочетании со словом «платформа». Что именно едино? Что понимать под платформой?

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

Такой подход неприемлем для настоящего ИТ-шника потому, что ИТ – самое гибкое из всего, что в области технологий придумал человек. Любую задачу можно решить несколькими способами в рамках разных подходов, каждый из которых обладает своими достоинствами и недостатками. А поскольку этого всего много – задач и способов их решения,– даже грамотный ИТ-шник не может с уверенностью ориентироваться во всем. Что же говорить о чиновнике, которому все чаще приходится отчитываться за внедрение ИТ?

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

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

Мой текст для тех, кто не преследует корыстных интересов, а недостаточно разбирается в ИТ-особенностях.

Естественная реакция неуверенного в своих познаниях человека – найти максимально простое решение. Большинство предложений ориентировано именно на этот мотив и я хочу разъяснить риски наиболее популярных из них.

1. Трактовка понятия «единая» под углом зрения логистики: единообразие/разнообразие

   «Единый софт» или «единые данные»

   (наиболее актуально для выбора стратегии на уровне региона)

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

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

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

   Единое – как одно для всех – решение позволяет:

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

   А граждане недовольны банальной халтурой, поскольку намного лучше чиновника знают, что можно сделать с ИТ и что было сделано реально, т.к. сами с этим работают. И то, что для чиновника является неизбежным злом, считают разбазариванием своих честно уплаченных налогов.

   Можно ли идти другим путем?

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

   Таким образом, мы одним ударом решаем 2 проблемы:

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

   Против такого решения сформировавшаяся «пищевая цепочка»:

   • Во-первых, те производители, которые наладили мосты в чиновные кабинеты и имеют возможность оттеснить конкурентов с помощью административного ресурса.
   • Во-вторых, чиновники, которым проще (а иногда и лично выгоднее) обеспечить «победу» нужному производителю, чтобы держать его «на крючке», заставляя, в случае необходимости, оперативно что-то подкручивать и подвинчивать по мере появления разных «хотелок»: как своих, так и сверху. За это можно закрыть глаза на недоработки, воевать с которыми приходится низовым исполнителям,– ведь, не бывает идеальных программных продуктов. (Кстати, кто у кого «на крючке»,– это еще большой вопрос?!)

2. Как реализовать «информационное единство», за которое я ратую?

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

   Этапы построения информационного единства:

   • Первое – четкое определение состава и источников данных. Не нужно опасаться ошибок – в жизни, особенно с применением ИТ, все быстро меняется. Хотя, конечно, это не «что изволите», а осмысленная процедура согласования изменений, занимающая некоторое время. Зато и основные работники не должны будут удовлетворять фантазии руководства в режиме Фигаро. Но формализация требований к необходимым для сбора данным – это профильная интеллектуальная нагрузка на чиновника, поэтому ждать от него апплодисментов не стоит.
   • Второе – профессиональное согласование технической спецификации протоколов обмена данными. Спецификация (подробное описание) позволит разным вендорам разработать утвержденные протоколы в своих продуктах. Обсуждение с обязательным участием разработчиков нужно организовать в соответствующих ведомствах. Коли мы отталкиваемся от задач образования, инициировать этот процесс должно Минобрнауки РФ, а потом утвердить и открыто опубликовать итоговый документ.
   • Третье – тестовая платформа для отладки работы утвержденных протоколов в процессе разработки (на площадке одного из разработчиков или по иной согласованной с ними процедуре).

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

   Хочу обратить внимание тех, кого смутило умное словосочетание «протокол обмена данными», что всю умность здесь сделают профессиональные ИТ-шники, если им правильно поставить задачу. Для этого достаточно сообщить, что именно откуда и куда должно передаваться (первый этап), понимая принцип: те программы, которые поддерживают этот протокол, могут обмениваться информацией друг с другом, понятия не имея друг о друге. Если задача поставлена здраво, а не по принципу «все подряд», результат будет достижим в разумные сроки и при небольших издержках.

3. Отчет для человека или для компьютера?

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

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

4. Есть ли реальный опыт применения протоколов обмена данными и машинно-читаемых отчетов?

   Будете смеяться, но в США и в Англии (думаю, не только там) школьные системы передают данные в стандартном машинно-читаемом формате уже лет 15. Школы используют самые разные информационные системы (они обобщенно называются SIS – school information system), но все они отправляют данные в их местные органы управления, причем школы понятия не имеют, в каком виде. Зато каждая SIS имеет свои средства анализа, которыми школа пользуется исключительно для своих управленческих задач. И эти аналитические возможности являются одним из конкурентных преимуществ продукта. А кому какие возможности анализа нужны, решает не территориальный орган управления, а сама школа.

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

   Есть и наш пример – пресловутая система межведомственного электронного взаимодействия (СМЭВ), создаваемая в рамках работы по переводу госуслуг в электронный вид.

   Для школьных электронных журналов тоже есть некоторые решения:

   • Есть наработки в Псковской области – там создают свою региональную систему.
   • Есть неуклюжее решение в Москве.
   • Прототип такого подхода подготовлен в рамках СПО-разработки РУЖЭЛЬ и доложен на конференции разработчиков летом 2012 года.

   Но пока под единством чаще понимают единообразие, с которым я пытаюсь бороться.

5. Важно предостеречь от ошибок, уже совершенных на пути создания протоколов обмена данными.

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

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

6. Трактовка понятия «единая» под углом зрения комплектации: монолит/ассорти

   «Единая информационная система» или «единая функциональность».

   (наиболее актуально для выбора стратегии на уровне одного учреждения)

   Логика руководителя, далекого от ИТ, понятна: незачем распылять ресурсы – нужно выбрать лучшую на рынке систему, которая бы решила все наши проблемы. Когда возникнут вопросы и затруднения, достаточно обратиться к одному поставщику.

   • ИТ-шник, которому все это нужно поддерживать, может такое решение поддержать: больше систем – больше головной боли.
   • ИТ-шник, который продает, ... даже объяснять не нужно – его мотив понятен.
   • ИТ-шник, который отвечает за свои экспертные рекомендации, будет пространен в рассуждениях, т.к. вариантов очень много и у каждого свои достоинства/недостатки.

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

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

   ИТ бурно развиваются, поэтому практически невозможно предсказать, что будет завтра в свете ИТ ни с вами, ни с поставщиком универсальной системы.

   • Может измениться позиционирование на рынке и вполне вероятна ситуация, когда либо у вас возникают иные ИТ-потребности, либо поставщик решения оказался в стороне от ваших потребностей. При наличии букета целевых технологий маневр совершается легче.
   • Большой продукт сразу освоить невозможно, значит, вы оплатили то, чем не пользуетесь, а к моменту освоения все может поменяться и нужно будет платить снова.
   • Если же вы все освоили, то перейти на другую систему, которая лучше подойдет вашим новым потребностям, вам не удастся уже по причинам немыслимых издержек на переучивание персонала.

   Однако из этого не следует, что за букет целевых технологий не нужно платить – нужно: получая лучшие ИТ-решения и возможность сравнительно легко их менять по мере изменений на рынке или в вашем бизнесе, нужно обеспечить их взаимодействие друг с другом. Это означает необходимость грамотной ИТ-поддержки, что непростой и недешевый ресурс. Зато часть продуктов из букета может быть в ранге свободного программного обеспечения или открытых облачных решений.

7. Все ли решают «облака»?

   Последнее время много разговоров о том, что больше не нужны привычные сервера и собственная ИТ-служба – все живет в «облаках» под чутким надзором профи.

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

   Поэтому стоит взвешивать риски каждого используемого у вас сервиса на случай его сбоя. То, что не очень критично иметь в доступе в любой момент, правильно размещать в «облаках». То, что требует оперативного доступа, лучше иметь в локальной сети.
   Попробуйте взвесить применимость Интернет-сервисов, когда во многих школах России канал доступа ниже 1 Мб/с. Для сравнения, в школах Англии каналы от 100 Мб/с до 1Гб/с, а локальные сервера тоже используются.

   Я рекомендую не поддаваться на красивую рекламу, а взвешивать риски и строить смешанную архитектуру сети, в которой есть место и локальным сервисам, и «облачным», в зависимости от задач и качеств канала.

Подводя итог

Хотелось бы еще раз предостеречь от «простых» решений – они по последствиям могут оказаться сложнее «сложных» (на первый взгляд!): неуклюжий подход к реализации единых информационных систем может не облегчить, а усложнить решаемые задачи, которые делаются не столько для решения самих задач, сколько для соблюдения указаний свыше.

Ссылка на презентацию с голосовым сопровождением по построению ИОС