Alexander Grigoryev – Закупка цифровых платформ для школ и больниц: Практическое руководство (страница 1)
Alexander Grigoryev
Закупка цифровых платформ для школ и больниц: Практическое руководство
Введение: Почему социальные учреждения боятся покупать софт
Закупка программного обеспечения для социальных учреждений — школ, больниц, домов культуры — традиционно считается одной из самых сложных и рискованных процедур в рамках Федеральных законов 44-ФЗ и 223-ФЗ. В отличие от приобретения мебели или продуктов питания, где качество можно оценить визуально или сверить с ГОСТом, программный продукт нематериален. Его функционал скрыт за интерфейсом, а совместимость с существующей инфраструктурой часто становится неприятным сюрпризом уже после подписания акта выполненных работ.
Главная проблема заказчика в социальной сфере заключается в отсутствии штатного ИТ-директора или системного архитектора. Директор школы или главврач больницы являются признанными экспертами в педагогике или медицине, но не в архитектуре баз данных, API-интеграциях или требованиях ФСТЭК. Попытка написать техническое задание «на глаз» или скопировать его у коллег приводит к двум типичным сценариям. В первом случае закупается дорогая, перегруженная функциями система, которую персонал не может освоить, и она годами пылится на серверах. Во втором случае покупается дешевое решение, которое не интегрируется с федеральными системами, такими как ЕГИСЗ, ФИС ОКО или ГИС «Электронная школа». Это делает невозможной сдачу обязательной отчетности и ведет к штрафам со стороны надзорных органов.
Данное руководство призвано закрыть этот компетенционный разрыв. Мы покажем, как директору или контрактному управляющему, не имеющему технического образования, грамотно сформулировать потребности, выбрать подходящее решение из Единого реестра российского программного обеспечения и принять работу так, чтобы система реально работала, а не просто числилась на балансе. Вы узнаете, как заменить сложные технические термины на понятные бизнес-требования, как организовать тестирование демо-версий силами обычных пользователей и какие пункты обязательно включить в контракт, чтобы защитить бюджет от некачественного продукта.
Раздел 1. Подготовка: От хаоса к системе требований
1.1. Аудит текущей ситуации: что уже есть и что болит
Прежде чем приступать к поиску нового программного обеспечения, необходимо честно и беспристрастно ответить на фундаментальный вопрос: зачем оно нужно? Практика показывает, что значительная часть закупок в социальной сфере инициируется не реальной операционной потребностью, а следованием моде на «цифровизацию» или административным давлением сверху. Чтобы избежать покупки бесполезного инструмента, начните с глубокого аудита текущих процессов. Выявите, какие операции до сих пор выполняются вручную или с помощью разрозненных таблиц в Excel. Зафиксируйте места, где регулярно возникают ошибки из-за человеческого фактора. Оцените временные затраты: сколько минут тратит медсестра на заполнение бумажных журналов учета или учитель на перенос оценок из тетрадей в электронный дневник? Эти цифры станут базовыми метриками эффективности будущего решения.
Ключевым элементом аудита является формирование рабочей группы, в состав которой должны войти не только системные администраторы или специалисты по закупкам, но и непосредственные конечные пользователи: врачи, медицинские сестры, педагоги, заместители директоров. Их повседневный опыт и жалобы являются наиболее точными индикаторами системных проблем. Если медики указывают на то, что существующая интеграция с ЕГИСЗ приводит к зависанию рабочих станций при выгрузке данных, это прямой сигнал о необходимости требования высокой производительности и надежных протоколов обмена данными в новом решении. Если педагоги сообщают, что тратят до часа ежедневно на дублирующий ввод оценок в разные информационные системы, значит, критически важным требованием становится наличие единого окна ввода или механизма автоматической синхронизации.
Документирование этих «болевых точек» формирует прочный фундамент для будущего технического задания. Вместо абстрактных желаний «улучшить работу» вы получаете конкретный список функциональных требований, продиктованных реальностью. Такой подход позволяет перевести разговор с поставщиками из плоскости маркетинговых обещаний в плоскость решения конкретных бизнес-задач учреждения, обеспечивая тем самым целесообразность расходования бюджетных средств.
1.2. Формулирование бизнес-требований вместо технических
Самая распространенная и дорогостоящая ошибка при составлении технического задания — попытка говорить на языке разработчиков. Когда заказчик пишет: «система должна использовать СУБД PostgreSQL версии 14» или «интерфейс должен быть написан на React», он не помогает, а вредит. Для директора школы или главврача эти формулировки ничего не значат, а для поставщика они становятся клеткой, ограничивающей выбор современных и эффективных архитектурных решений. Правильный подход заключается в смещении фокуса с инструментов на результаты. Вместо описания того,
Для структурирования этих ожиданий требования целесообразно разделить на три логические группы: функциональные, нефункциональные и интеграционные. Такой подход обеспечивает полноту описания и защищает заказчика от приобретения «красивой, но бесполезной» оболочки.
Функциональные требования описывают конкретные действия, которые система должна выполнять. Это ответ на вопрос «что делать?». В школе это может быть ведение электронного журнала, автоматический расчет среднего балла ученика или формирование табелей успеваемости. В больнице — создание электронной медицинской карты, выписка рецепта с проверкой совместимости лекарств или запись пациента на прием к специалисту. Эти требования должны быть максимально конкретными и привязанными к реальным рабочим процессам учреждения.
Нефункциональные требования определяют качественные характеристики системы, отвечая на вопрос «как работать?». Сюда входят показатели производительности, надежности, безопасности и удобства использования. Например, система должна быть доступна круглосуточно (24/7), за исключением плановых технических работ, время которых должно быть строго регламентировано. Время загрузки любой страницы не должно превышать одной секунды при стандартной скорости интернета. Особое внимание уделяется защите персональных данных: система должна соответствовать требованиям Федерального закона 152-ФЗ, обеспечивать шифрование данных при передаче и хранении, а также разграничивать права доступа так, чтобы учитель видел только своих учеников, а врач — только своих пациентов.
Интеграционные требования описывают взаимодействие новой платформы с существующей цифровой экосистемой. Ни одна современная информационная система не существует в вакууме. Школьная платформа обязана автоматически получать списки учащихся из регионального портала образования и выгружать данные в федеральные системы, такие как ФИС ОКО (Федеральная информационная система «Общеобразовательная организация»). Больничная система должна интегрироваться с ЕГИСЗ (Единая государственная информационная система в сфере здравоохранения) для передачи сведений о оказанной помощи и иметь возможность обмена данными с лабораторными информационными системами. Отсутствие четких интеграционных требований часто приводит к тому, что сотрудникам приходится вручную переносить данные из одной системы в другую, что сводит на нет весь эффект от цифровизации.
Подобная структура требований позволяет поставщикам предлагать оптимальные технологические решения, не сковывая их устаревшими стереотипами заказчика. При этом результат остается предсказуемым и контролируемым. Заказчик получает не просто набор кода, а работающий инструмент, который решает его задачи, быстро реагирует на действия пользователей и бесшовно встраивается в существующие государственные информационные потоки.
1.3. Юридические ограничения: Реестр российского ПО и импортозамещение
С 2025 года нормативное поле в сфере государственных и муниципальных закупок программного обеспечения претерпело существенные изменения, сделав использование отечественного софта не просто рекомендацией, а строгим императивом. Законодательство фактически закрыло возможность приобретения иностранных информационных систем для нужд госсектора, за исключением крайне редких случаев, когда доказано полное отсутствие российских аналогов с требуемым функционалом. Это означает, что любой процесс выбора платформы должен начинаться не с анализа рынка в целом, а с глубокого изучения Единого реестра российских программ для электронных вычислительных машин и баз данных, доступного по адресу reestr.digital.gov.ru. Игнорирование этого этапа на старте делает всю последующую закупочную процедуру юридически уязвимой и рискует быть признанной недействительной контролирующими органами.