Alexander Grigoryev – Закупка цифровых платформ для школ и больниц: Практическое руководство (страница 2)

Поиск в реестре требует внимательности и понимания отраслевой специфики. Недостаточно просто найти программу с похожим названием; критически важно проверить её принадлежность к соответствующему классу. Для образовательных учреждений приоритетными являются решения, зарегистрированные в классе «Образовательные технологии», так как они изначально проектировались с учетом педагоических задач, интеграции с электронными журналами и требованиями Министерства просвещения. Для медицинских организаций ключевым является класс «Медицинские информационные системы», продукты которого сертифицированы для работы с персональными данными пациентов и имеют необходимые модули для взаимодействия с ЕГИСЗ. Выбор продукта из неверного класса может привести к тому, что платформа формально будет считаться российской, но функционально окажется непригодной для специфических задач школы или больницы.

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

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

Раздел 2. Техническое задание: Как описать неописуемое

2.1. Структура ТЗ для нетехнического заказчика

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

Первый блок — Общие сведения. Здесь необходимо кратко и ясно описать назначение системы. Для кого она предназначена? Сколько сотрудников будут ей пользоваться одновременно? В каком режиме она должна работать — круглосуточно или только в рабочие часы? Например, для школьной платформы важно указать количество учителей и учеников, а для больничной системы — число врачей и медсестер, которые будут вносить данные. Эта информация поможет поставщику правильно оценить нагрузку на систему и предложить подходящее техническое решение.

Второй блок — Функциональные требования. Это сердце технического задания. Вместо абстрактных фраз вроде «система должна быть удобной» опишите конкретные действия пользователей в формате «Пользователь делает Х -> Система делает Y». Такой подход исключает двусмысленность. Например, для медицинской информационной системы можно написать: «При вводе диагноза врач выбирает код МКБ-10 из встроенного справочника, после чего система автоматически проверяет соответствие диагноза полу и возрасту пациента и предупреждает об ошибках». Для школы: «Учитель выставляет оценку в электронный журнал, и она мгновенно отображается в личном кабинете родителя». Чем подробнее описаны такие сценарии, тем точнее поставщик поймет ваши потребности.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.