Приказ 270. Инструкция по работе с РПД

Как аккредитованным ИТ-компаниям не потерять льготы и правильно участвовать в образовательных программах — со всеми подводными камнями, которые спрятаны в рабочих программах дисциплин

31 марта 2026 года Минцифры подписало Приказ №270 — «Об утверждении Порядка заключения, реализации и оценки результатов реализации соглашений об оказании российскими организациями, осуществляющими деятельность в области информационных технологий, содействия в реализации образовательных программ и внеурочной деятельности». 14 апреля документ прошёл регистрацию в Минюсте и вступил в силу 25 апреля 2026 года

Под действие приказа попадают крупные аккредитованные ИТ-компании — с численностью сотрудников от 100 человек и годовой выручкой более 1 млрд рублей. Именно они получают наиболее весомые налоговые льготы и теперь обязаны тратить на образовательные проекты не менее 3% от суммы, сэкономленной на налогах. Чтобы сохранить аккредитацию, до 1 июня 2026 года необходимо заключить соглашение с вузом или колледжем.

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

Рабочая программа дисциплины (РПД) — ключевой элемент образовательной программы, без которого невозможно ни провести аккредитацию вуза, ни легально организовать учебный процесс. Это не просто «план лекций». Это юридически значимый документ, который фиксирует: что студент должен знать, уметь и чем владеть после освоения дисциплины, как формируются компетенции, как они проверяются и какими ресурсами обеспечены. Для ИТ-компании, которая хочет выполнить требования Приказа №270, РПД — это точка входа. Если специалист компании будет читать лекции, его часы должны быть отражены в РПД. Если компания предлагает свою платформу или оборудование — это фиксируется в разделе МТО. Если компания участвует в разработке профессиональных компетенций — это влияет на содержание раздела о ПК.

В ММА (Московская международная академия , Москва) структура РПД включает 8 обязательных разделов плюс два обязательных приложения:

Все современные РПД в России строятся по логике ФГОС ВО 3++. Его принципиальное отличие от предыдущих стандартов: профессиональные компетенции (ПК) теперь не задаются стандартом, а определяются вузом самостоятельно — на основе профессиональных стандартов или требований работодателей. Это означает, что для каждой дисциплины нужно:

1. Выбрать из матрицы компетенций ОПОП те УК, ОПК и ПК, которые формирует именно эта дисциплина

2. Прописать индикаторы достижения для каждой компетенции

3. Декомпозировать индикаторы на ЗУВы — конкретные знания, умения и владения

4. Привязать каждый ЗУВ к конкретным темам модульно-тематического плана

5. Создать оценочные средства, которые проверяют именно эти ЗУВы В РПД по «Высшей математике» ТИСБИ, например, формируется единственная компетенция — УК-1 («Способен осуществлять поиск, критический анализ и синтез информации»), и под неё расписаны конкретные индикаторы УК-1.1 и УК-1.2 с ЗУВами по каждому из пяти модулей курса. Это правильно и методически корректно — но требует значительных трудозатрат.

По Положению о РПД МФЮА цепочка ответственности выглядит так:

• Разработчик — ведущий преподаватель, назначенный в соответствии с нагрузкой по кафедре

• Контроль разработки — заведующий кафедрой • Утверждение — заседание кафедры (протокол)

• Хранение — деканаты (электронный вид) + Управление качеством (для сайта)

• Финальное утверждение — ректор Работа по разработке РПД вносится в индивидуальный план преподавателя в раздел «Учебно-методическая работа». Обновление возможно ежегодно — в части тематического плана, ФОС, литературы. Для ИТ-компании, участвующей по Приказу №270, важно понимать: любые изменения в программе (новая тема, новый преподаватель, новое ПО в разделе МТО) формально требуют прохождения этой цепочки. Без протокола кафедры изменение не считается официальным.

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

1. Расхождение наименования дисциплины с учебным планом Наименование дисциплины в РПД должно точно совпадатьс наименованием в утверждённом учебном плане — до регистра, дефисов и предлогов. Расхождение «Информационные системы» vs «Информационные системы и технологии» — это уже ошибка, которая останавливает согласование. Источник истины — учебный план в 1С:Университет, и только он.

2. Несовпадение часов с зачётными единицами 1 зачётная единица = 36 академических часов. Если дисциплина стоит 4 з.е. — в тематическом плане должно быть ровно 144 часа, распределённых по лекциям, практикам и СРС с учётом часов на промежуточную аттестацию. В УлГУ, например, на подготовку к экзамену закладывается до 36 часов, на зачёт — до 18 часов. Ошибки в подсчёте часов — самая частая причина технического возврата РПД.

3. «Мёртвая» литература в разделе 6 Основная литература должна быть не старше 5–10 лет. Учебник 2008 года в качестве основного источника — красный флаг при аккредитации. При этом литература должна быть либо физически в библиотеке вуза, либо в ЭБС, с которой у вуза заключён действующий договор. Ссылка на ЭБС без договора аннулируется при проверке.

4. МТО «из воздуха» Материально-техническое обеспечение (аудитории, оборудование, ПО) должно реально существовать в вузе и соответствовать реестру имущества. Нельзя написать «лицензионный пакет MATLAB» если его нет, или «аудитория с видеопроекционным оборудованием» без конкретного номера аудитории. Для ИТ-компаний, предоставляющих доступ к своим платформам по Приказу №270, это принципиально: платформа должна быть внесена в МТО с указанием условий доступа.

5. Компетенции не покрывают матрицу ОПОП В матрице компетенций образовательной программы каждая компетенция должна быть сформирована хотя бы в одной дисциплине. При этом одна дисциплина не может нести ответственность за всё. Часто возникает ситуация: кафедра при обновлении РПД убирает одну компетенцию — и она «провисает» в матрице без дисциплины-носителя.

6. ФОС не соответствует заявленным компетенциям Фонд оценочных средств должен проверять именно те ЗУВы, которые заявлены в разделе 3. Если в компетенции написано «владеет навыком настройки сетевого оборудования», а в ФОС только тесты с выбором ответа — это несоответствие, которое выявляется при экспертизе. Политех (СПб) требует три уровня сформированности компетенции (пороговый, базовый, повышенный) с разными инструментами оценки для каждого.

Если вы ИТ-компания, которая заключила соглашение по Приказу №270 и впервые сталкивается с разработкой или актуализацией РПД — вот последовательный план действий.

Шаг 1. Получите учебный план из 1С:Университет Прежде чем брать в руки шаблон РПД, запросите у куратора в вузе выгрузку учебного плана по нужному направлению в формате Excel или PDF. Это первичный источник для:

• точного наименования дисциплины

• кода дисциплины (Б1.О.12 и т.п.)

• количества з.е. и часов по формам обучения

• форм промежуточной аттестации (зачёт/экзамен/курсовая)

• семестра изучения Совет: Никогда не начинайте с шаблона Word — начинайте с учебного плана. Всё, что не совпадает с учебным планом, потом придётся переделывать.

Шаг 2. Запросите матрицу компетенций ОПОП Матрица компетенций — это таблица, где по строкам идут все дисциплины программы, по столбцам — все компетенции (УК, ОПК, ПК), а на пересечении стоит крестик, если дисциплина формирует данную компетенцию. Эту матрицу ведёт отдел качества или методический отдел вуза. Выясните, какие именно компетенции закреплены за вашей дисциплиной. Без этого невозможно корректно заполнить раздел 3.

Шаг 3. Изучите ФГОС по конкретному направлению

На сайте fgosvo.ru найдите актуальную редакцию ФГОС 3++ по направлению подготовки. Вам нужны:

• формулировки УК и ОПК (они стандартные, менять их нельзя)

• типы задач профессиональной деятельности ПК формирует сам вуз, но должен согласовать их с профессиональными стандартами — это задача методического отдела, не ваша.

Шаг 4. Декомпозируйте компетенции по схеме УлГУ Для каждой компетенции пропишите индикаторы и ЗУВы по шаблону: Компетенция ОПК-4
 Индикатор ОПК-4.1 [формулировка из ФГОС/ОПОП]
   ОПК-4.1.З.1  Знает [конкретный объект знания]
   ОПК-4.1.У.1  Умеет [конкретное действие]
   ОПК-4.1.В.1  Владеет [навык или метод] Правило: ЗУВы должны быть верифицируемыми — т.е. их можно проверить конкретным заданием. «Знает основы Python» — плохо. «Знает синтаксис и встроенные типы данных Python для решения алгоритмических задач» — хорошо.

Шаг 5. Составьте модульно-тематический план с подсчётом часов Разбейте курс на 3–5 модулей. Для каждой темы в каждом модуле укажите часы лекций, практик и СРС отдельно для каждой формы обучения (очная/очно-заочная/заочная). Итоговая сумма должна точно совпасть с учебным планом. Лайфхак ТИСБИ: На подготовку к экзамену закладывайте 36 часов, к зачёту — 18 часов в рамках часов СРС. Это «спрятанные» часы, которые часто забывают учесть — и получают расхождение в итоге.

Шаг 6. Проверьте литературу по трём критериям Каждый источник в разделе 6 проверьте по чеклисту:

• Год: основная литература — не старше 5–10 лет • Доступность: издание физически есть в библиотеке вуза ИЛИ в ЭБС с действующим договором • Формат ссылки: Автор, инициалы. Название. — Город: Издательство, год. — Страниц. ISBN. URL (если электронный) Уточните в библиотеке вуза, с какими ЭБС заключены договоры. Стандартная тройка — IPRbooks, Лань, ЭБС ЮРАЙТ — но у каждого вуза свой набор.

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

Шаг 8. Создайте ФОС с тремя уровнями Фонд оценочных средств должен содержать задания минимум для трёх уровней сформированности каждой компетенции:

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

На бумаге схема согласования проста: разработчик → зав. кафедрой → протокол заседания кафедры → ректор. На практике к этому добавляются промежуточные проверки: Преподаватель разрабатывает/обновляет РПД
       ↓
Проверка заведующим кафедрой (содержание, часы, компетенции)
       ↓
Проверка Управлением качеством (соответствие шаблону, ФГОС)
       ↓ ← здесь чаще всего возврат на доработку
Согласование первым проректором 
       ↓
Проверка юридическим отделом
       ↓
Утверждение ректором
       ↓
Размещение на официальном сайте вуза Типичные причины возврата на этапе Управления качеством: • Несоответствие шаблону (отсутствие обязательных элементов) • Устаревшая литература или ЭБС без договора • Некорректный подсчёт часов • Компетенции в РПД не соответствуют матрице ОПОП • Отсутствует или формально заполнена пояснительная записка

Практический совет для ИТ-компаний: Назначьте в компании одного ответственного за образовательные соглашения (не обязательно HR — лучше кто-то с техническим бэкграундом и навыками работы с документацией). Именно этот человек будет переводить требования Приказа №270 в конкретные правки РПД и договариваться с методистами вуза.

Прежде чем отправить документ в согласующую инстанцию, пройдитесь по этому списку: Раздел 1 (Цели): • Цели сформулированы через глаголы результата («формирует», «развивает») • Задачи — через глаголы процесса («освоение», «приобретение») Раздел 2 (Место в ОПОП): • Указан блок учебного плана (Б1.О / Б1.В) • Прописаны пресеквизиты и постсеквизиты Раздел 3 (Компетенции): • Компетенции соответствуют матрице ОПОП • Для каждой компетенции прописаны индикаторы и ЗУВы • Формулировки УК/ОПК точно совпадают с ФГОС Раздел 4 (Содержание): • Сумма часов совпадает с учебным планом • Часы на промежуточную аттестацию учтены • Для каждой темы указаны формируемые компетенции/индикаторы Раздел 6 (Литература): • Основная — не старше 10 лет • Все электронные источники — в ЭБС с действующим договором • Формат библиографических ссылок соответствует ГОСТ Раздел 7 (МТО): • Все аудитории указаны с номерами • ПО указано с видом лицензии • Нет позиций, которых реально нет в вузе ФОС (Приложение 2): • Задания для трёх уровней сформированности • Каждый ЗУВ из раздела 3 проверяется хотя бы одним заданием • Критерии оценки прозрачны и конкретны

Чтобы оценить масштаб работы, рассмотрим типичную дисциплину на примере «Высшей математики» ТИСБИ — 6 з.е., 216 часов, 5 модулей, три формы обучения:

Умножьте на количество дисциплин на кафедре. В типичном вузе кафедра ведёт 15–40 дисциплин. При ежегодном обновлении хотя бы 30% программ — это тысячи человекочасов ежегодно только в одном учебном заведении.

Описанный выше процесс — не неизбежность. Современные инструменты позволяют радикально сократить трудозатраты при одновременном росте качества. Конструктор РПД от CDO Global — это продукт, апробированный в десятках российских вузов, включённый в реестр отечественного ПО и работающий непосредственно в ЭИОС. Вот что он меняет в каждом из описанных узких мест: Интеграция с 1С:Университет устраняет проблему расхождения с учебным планом: наименование дисциплины, код, количество зачётных единиц и распределение часов автоматически подтягиваются из учебного плана в 1С. Человеческий фактор в этих полях исключён. Счётчик трудоёмкости следит за тем, чтобы сумма часов по модулям совпадала с учебным планом, выдавая предупреждение при расхождении. Это закрывает самую частую техническую ошибку. Интеграция с библиотечной системой позволяет искать литературу прямо внутри конструктора — только по фондам, которые реально есть в библиотеке вуза. Исключается ситуация, когда преподаватель вносит источник из ЭБС без договора. Интеграция с 1С:Бухгалтерия обеспечивает раздел МТО: оборудование подтягивается из реестра имущества университета. Нельзя вписать то, чего нет. Согласование внутри ЭИОС — весь цикл от разработки до утверждения происходит в одной системе без пересылки файлов по email. Каждый шаг цепочки фиксируется, возвраты и правки отслеживаются. ИИ-ассистент — наиболее интересная возможность для ИТ-компаний. Нейросеть на основе заявленных компетенций предлагает черновики формулировок ЗУВов, тематического плана и содержания разделов. Преподаватель проверяет и уточняет, а не создаёт с нуля. Импорт готовых РПД позволяет загрузить существующий документ — система автоматически распознаёт структуру и распределяет данные по разделам. Это особенно ценно при первичном переходе: не нужно вводить всё вручную. Для ИТ-компании, участвующей по Приказу №270, конструктор решает ещё одну задачу: прозрачность вклада. Все изменения в программе, внесённые специалистом компании, фиксируются в системе с атрибуцией. Это готовая база для отчёта в Минцифры о реализации соглашения.

По материалам CDO Global