1. Философские основания
| Аспект | Традиционный подход | Экосистемный подход (https://expert.8m.by) |
| Онтология | Организация как иерархическая машина | Организация как платформа/экосистема |
| Природа работника | Функциональная единица штатного расписания | Автономный агент с репутационным капиталом |
| Природа знания | Собственность организации, закрытый актив | Публичный ресурс работника, измеримый через достоверность |
| Логика управления | Административно-директивная | Кооперативно-упорядоченная |
| Единица планирования | Тема/мероприятие как описание деятельности | Задача как снятое противоречие с измеримым результатом |
Ключевой философский разрыв: Традиционный подход оперирует категорией занятости (человеко-дни, штатные единицы), экосистемный –категорией результата (решённая задача, созданный нематериальный актив). Это различие восходит к противопоставлению бюрократической рациональности Вебера и сетевой рациональности цифровой экономики.
2. Структурный анализ планирования
2.1. Традиционная модель НИР
Архитектура плана:
Тема (общее направление)
└── Мероприятие (описание деятельности)
├── Ответственный исполнитель (должность)
├── Привлекаемое подразделение
└── Срок: «в течение года»
Критические дефекты структуры:
- Отсутствие декомпозиции: Тема не разбивается на конкретные решаемые задачи. Например, «ОКР по созданию ПО «Информационно-кооперационная платформа»» – это описание процесса, а не то, что должно быть получено.
- Фиксация на должностях: «Начальник сектора», «Начальник управления» – роли привязаны к штатному расписанию, а не к компетенциям для конкретной задачи.
- Временная аморфность: «В течение года» лишает плана управленческого смысла. Невозможно определить точки контроля, критические пути, риски срыва.
- Отсутствие бюджетной детализации: Нет приведённой стоимости задач, нет учёта рисков в бюджете.
- Отсутствие критериев успеха: Нет измеримых порогов, по которым можно судить о завершённости.
2.2. Экосистемная модель (https://expert.8m.by)
Архитектура плана:
Тема (стратегический вызов)
└── Задача (решаемое противоречие/барьер/гипотеза)
├── Тип задачи (типология: противоречие, барьер, гипотеза, проекция, интеграция, трансформация)
├── Приоритет (управленческое требование)
├── Приведённая стоимость (с учётом риска и продолжительности)
├── Владелец (компетенция + рейтинг Гудвил)
├── Ключевой технический риск
├── Измеримый критерий успеха
└── Срок (конкретный квартал/месяц)
Концептуальные инновации:
| Типология задач | Классификация по логике научного познания | Теория решения изобретательских задач (ТРИЗ), эпистемология |
| Приоритет | Управленческое требование, а не пожелание | Теория ограничений Голдратта |
| Гудвил (рейтинг) | Репутационный капитал как замена административного статуса | Экономика репутации, теория сигналов |
| Приведённая стоимость | Финансовое отражение риска и неопределённости | Теория реальных опционов |
| Конкурсная замена владельца | Механизм естественного отбора | Эволюционная экономика, теория турниров |
3. Эпистемологическое сравнение: что считается результатом
3.1. Традиционный подход: отчёт как симулякр
В плане организации результат НИР – это отчёт, зафиксированный в форме:
- Тезисы докладов
- Научные статьи
- Участие в конференциях
- Заявки на патенты
Проблема: Это индикаторы активности, а не показатели результата. Статья может быть опубликована без новизны, патент – без коммерческого потенциала, конференция – без обратной связи.
3.2. Экосистемный подход: достоверный научный результат
В модели https://expert.8m.by результат – созданный нематериальный актив, оцениваемый по пяти критериям (в соответствии с Постановлением Совмина РБ № 914):
| Критерий | Как измеряется в экосистеме |
| Новизна | Сравнение с реестром существующих решений, антиплагиат |
| Значимость | Метрики использования (просмотры, внедрения, цитирования) |
| Объективность | Воспроизводимость, независимая верификация |
| Доказательность | Протоколы тестов, открытые данные, рецензии |
| Точность | Статистические метрики, доверительные интервалы |
Концептуальный сдвиг: Отчёт перестаёт быть самоцелью и становится средством верификации результата. Ценность создаёт не документ, а решённая задача, внесённая в реестр достоверных научных результатов.
4. Правовая состоятельность: соответствие законодательству РБ
4.1. Оценка несоответствий
| Требование законодательства | Нормативный акт | Сейчас | Статус в expert.8m.by |
| Технико-экономическое обоснование (ТЭО) | Приказ ГКНТ № 40 от 20.05.1997 | Отсутствует | Присутствует (разделы «Объект и предмет», «Методология», «Бюджет») |
| Научное (техническое) задание | Указ Президента № 356 от 25.05.2006 | Отсутствует | Заменяется технологической картой задачи |
| Календарный план с этапами | Постановление СМ РБ № 914 | Отсутствует (только «в течение года») | Детальная разбивка по месяцам, контрольные точки |
| Оценка по пяти критериям | Постановление СМ РБ № 914 | Не предусмотрена | Встроена в балльную систему |
| Маркетинговое обоснование | Закон РБ «О научной деятельности» | Отсутствует | Разделы «Выход на коммерческий результат», «Вклад в практику» |
Вывод: План организации может быть формально утверждён, но юридически несостоятелен для финансируемых НИОКР. Он не содержит обязательных элементов, предусмотренных законодательством, и не может служить основанием для контроля целевого использования средств.
4.2. Экосистемный подход как надстройка над законом
Модель https://expert.8m.by не просто формально соответствует требованиям – она операционализирует их:
- ТЭО превращается из статичного документа в динамическую технологическую карту, обновляемую по мере решения задачи.
- Календарный план становится публичным трекером с автоматической фиксацией прогресса.
- Оценка – не разовая экспертиза, а накопительный процесс (отзывы, метрики использования).
5. Экономика научной деятельности: две модели стимулирования
5.1. Традиционная модель: премия за занятость
Вход: Штатная единица → Процесс: Выполнение плана → Выход: Премия по факту отчёта
Патология: Стимул направлен на симуляцию деятельности, а не на создание ценности. Работник заинтересован в:
- формальном выполнении показателей (количество статей, а не их качество);
- минимизации риска (новые идеи опасны для плана);
- сохранении статус-кво (перераспределение ресурсов угрожает должности).
5.2. Экосистемная модель: оплата за результат
Вход: Задача с критериями успеха → Процесс: Конкурсный отбор, решение, верификация → Выход: Оплата по факту приёмки + рост Гудвила
Механизмы самоорганизации:
| Механизм | Описание | Эффект |
| Репутационный капитал (Гудвил) | Накопленный рейтинг определяет доступ к ресурсоёмким задачам | Отбор в пользу надёжных и компетентных исполнителей |
| Конкурсная замена | При срыве сроков или невыполнении критериев владелец заменяется | Снижение риска «застоя» проектов |
| Публичность | Все задачи, прогресс, результаты открыты внутри организации | Предотвращение имитации, стимул к качеству |
| Форки | Любой участник может предложить альтернативное решение | Инновационная конкуренция внутри экосистемы |
6. Типология задач как эпистемологический инструмент
Экосистемный подход вводит типологию задач, отсутствующую в традиционном планировании. Это не простая классификация – это онтологическая сетка, определяющая логику научного познания:
| Тип задачи | Логика познания | Пример |
| Противоречие | Диалектика: снятие противоречия между требованиями | «Снять противоречие между персонализацией API и временем отклика» |
| Барьер | Преодоление предела существующих решений | «Преодолеть барьер совместимости с легаси-АСУ» |
| Гипотеза | Проверка научного предположения | «Проверить гипотезу: распределённый реестр повышает достоверность» |
| Проекция | Конструирование образа будущей системы | «Спроектировать единое окно заявок и рейтингования» |
| Интеграция | Синтез разнородных компонентов | «Интегрировать базы БелИСА, патентный фонд, промышленные данные» |
| Трансформация | Глубокое изменение модели | «Трансформировать модель управления НИР с функциональной на задачно-ориентированную» |
Значение: Каждый тип требует своей методологии, своих рисков, своих критериев успеха. Это предотвращает категориальную ошибку традиционного планирования, где все НИР сводятся к одной форме «провести исследование».
7. Механизм реализации: как работает экосистема
Этап 1: Публикация темы на платформе
↓
Этап 2: Декомпозиция на задачи (любой участник может предложить)
↓
Этап 3: Назначение приоритета Научно-техническим советом
↓
Этап 4: Сбор заявок на решение (кто, с каким планом и бюджетом)
↓
Этап 5: Оценка заявок (новизна, риски, коммерческий потенциал, реализуемость, квалификация)
↓
Этап 6: Цифровой контракт на задачу (не на ставку!)
↓
Этап 7: Публичный мониторинг (прогресс, комментарии, форки)
↓
Этап 8: Итоговая аттестация по 5 критериям → внесение в реестр
Ключевое отличие: В традиционной модели план – это артефакт утверждения, в экосистемной – «живой» инструмент управления, который эволюционирует по мере решения задач.
8. Что исчезает и что появляется
Исчезает из плана:
- Фиксированный «ответственный исполнитель» как должность → заменяется владельцем задачи, определяемым конкурсом
- «В течение года» → заменяется конкретными кварталами/месяцами
- «Привлекается структурное подразделение» → заменяется открытым вызовом
- Отсутствие бюджета → появляется приведённая стоимость с учётом риска
- Отсутствие критериев успеха → измеримые пороги приёмки
Появляется в плане:
- Иерархия «тема → задача» с логической связью
- Типология задач как методологическая основа
- Приоритет как управленческое требование с санкциями
- Ключевой технический/организационный риск
- Рейтинг владельца как гарантия компетенции
- Механизм конкурсной замены при невыполнении
9. Пример задачи: «Снять противоречие между требованием персонализации API и временем отклика»
Идентификация задачи
| Критерий | Значение |
| ID задачи | T-001-01 |
| Принадлежит теме | T-001 «Разработка информационно-кооперационной платформы для промышленности» |
| Название задачи (особенное, предполагает решение) | Снять противоречие между требованием персонализации API и временем отклика |
| Тип задачи | Задача-противоречие |
| Приоритет (управленческое требование) | 1 (высший) |
| Бюджет (приведённая стоимость, руб.) | 16698 |
| Владелец (компетенция + рейтинг) | Петров П.А. (Гудвил — 92) |
| Ключевой риск | Риск невоспроизводимости на реальных данных |
| Измеримый критерий успеха | Адаптивный интерфейс, отклик <0,5 с |
| Срок | 2 кв. |
1. Описание противоречия (входные условия)
| Элемент | Содержание |
| Требование А | Каждое промышленное предприятие (заказчик) требует возможности гибкой настройки API платформы: фильтры, агрегаты, специфические форматы данных, пользовательские скрипты. |
| Требование Б | Платформа должна обеспечивать время отклика API не более 500 мс (0,5 с) при одновременной работе не менее 100 предприятий. |
| Суть противоречия | Чем больше персонализации (количество уникальных настроек на предприятие), тем выше вычислительная сложность маршрутизации и кэширования, что приводит к росту времени отклика. Традиционные подходы (простое кэширование, общие агрегаты) не работают при числе уникальных конфигураций > 50. |
2. Предполагаемое решение (ядро задачи)
Гипотеза решения:
Применить гибридную архитектуру:
- Персонализация на уровне edge-слоя (предварительная фильтрация/трансформация на узлах CDN или nginx + Lua скрипты) — до 80% настроек.
- Адаптивное кэширование с учётом контекста запроса (не по URL, а по хешу настроек предприятия).
- Динамическое управление приоритетами — для предприятий с высокой платёжеспособностью допустимо увеличение отклика до 1 с, для остальных — жёсткое ограничение 0,5 с.
План верификации:
- Построить математическую модель зависимости времени отклика от числа уникальных конфигураций.
- Разработать прототип на Python/FastAPI с имитацией edge-слоя.
- Провести нагрузочное тестирование (100 предприятий, 10 типовых профилей персонализации).
- Сравнить с базовым вариантом (традиционное кэширование).
3. Ключевой технический риск
| Риск | Вероятность | Влияние | Меры снижения |
| Невоспроизводимость результатов на реальных данных промышленных предприятий (отличие профилей запросов от синтетических) | 40% | Высокое (требуется пересмотр гипотезы) | Использовать реальные логи API за 3 месяца (анонимизированные) от 2 пилотных предприятий. Предусмотреть второй сценарий — адаптивное кэширование без edge-слоя (как fallback). |
Дополнительные риски:
- Риск недостижения параметров производительности (<0,5 с) – 25%.
- Организационный риск: отказ пилотных предприятий предоставить логи – 15%.
4. Измеримые критерии успеха (приёмка задачи)
| Критерий | Порог успеха | Метод верификации |
| Время отклика API при 100 предприятиях, каждое со своим профилем (20 параметров) | ≤ 0,5 с (95-й перцентиль) | Нагрузочное тестирование (JMeter) на стандартной конфигурации сервера (4 vCPU, 8 GB RAM) |
| Количество поддерживаемых уникальных профилей персонализации | ≥ 100 | Автоматизированный тест генерации профилей |
| Прирост по сравнению с базовым кэшированием | Ускорение ≥ 40% | Тест A/B |
| Документация | Описана архитектура edge-адаптации, инструкция по развёртыванию | Экспертная оценка |
5. Этапы выполнения и трудозатраты
| Этап | Содержание | Срок | Трудозатраты (чел-дни) | Ответственный (роль) |
| 1 | Анализ реальных логов, формирование профилей персонализации | 1–15 февраля | 5 | Инженер данных |
| 2 | Построение математической модели и выбор гипотезы | 16–28 февраля | 4 | Научный сотрудник (математическое моделирование) |
| 3 | Разработка прототипа edge-слоя + адаптивное кэширование | 1–31 марта | 15 | Разработчик Python |
| 4 | Нагрузочное тестирование, сравнение с базой | 1–15 апреля | 6 | Инженер по тестированию |
| 5 | Документирование, подготовка отчёта | 16–30 апреля | 3 | Все участники |
| Итого | 33 чел-дня |
Базовая стоимость чел-дня: 440 руб.
Приведённая стоимость задачи с учётом риска (коэфф. 1,15)×33×440×1,15 = 16698 руб.
6. План контроля и отчётности
| Параметр | Значение |
| Приоритет задачи | 1 (высший) – контроль ежемесячный |
| Формат отчёта | Загрузка протоколов тестов, фрагментов кода, промежуточных графиков |
| Точки контроля | 1 марта (завершение этапа 2), 1 апреля (прототип готов), 1 мая (полный отчёт) |
| Приёмка результата | Научно-технический совет голосованием (см. https://expert.8m.by) на основе выполнения всех критериев из п. 4 |
7. Квалификация владельца и команды
| Роль | Требуемый Гудвил, балл | Текущий владелец | Подтверждение компетенции |
| Владелец задачи (главный исследователь) | ≥ 80 | Петров П.А. (рейтинг 92) | Ранее решённая задача по оптимизации API (ID завершённой задачи 124) |
| Разработчик | ≥ 60 | (назначается владельцем) | Опыт работы с FastAPI, nginx, Lua |
| Инженер данных | ≥ 50 | (назначается владельцем) | Опыт обработки промышленных логов |
8. Коммерческий потенциал и дальнейшее использование
| Направление | Описание |
| Прямой выход | Полученное решение (алгоритм edge-адаптации + адаптивное кэширование) может быть упаковано как отдельный модуль «Персонализация API» для продажи промышленным предприятиям. |
| Косвенный выход | Снижение серверных мощностей на 30–40% для платформ с высокими требованиями к персонализации. |
| Ожидаемый вклад в практику | Кардинальное улучшение показателя (время отклика) без потери гибкости, что является критическим для перехода на платформу Индустрия 4.0. |
9. Подписи и согласование (в цифровой среде)
| Роль | ФИО / цифровая подпись | Дата |
| Владелец задачи | Петров П.А. | 15.01.2026 |
| Научный руководитель темы | (назначается советом) | (после проверки карты) |
| Председатель НТС | Мухтейн А.Б. | (утверждение бюджета) |
Почему это задача, а не «постоянная обязанность»
| Признак постоянной обязанности | Признак задания |
| Разработка ПО – это постоянная функция отдела | Конкретное противоречие с двумя взаимоисключающими требованиями |
| Нет конкретного результата, кроме очередной версии | 4 измеримых критерия успеха, каждый с порогом и методом верификации |
| Риски не прогнозируются | 3 идентифицированных риска с вероятностью, влиянием, мерами снижения |
| Исполнитель определён штатным расписанием | Владелец назначается по Гудвилу, возможна конкурсная замена |
| Бюджет не выделяется, это в рамках ФОТ | Приведённая стоимость 16698 руб. с учётом риска и продолжительности |
| Срок не определён, в течение года | Конкретный срок: 2 квартал, с ежемесячными точками контроля |
10. Заключение
Традиционное планирование НИР в формате занятости – это бюрократический артефакт, переживший свою эпоху. Оно:
- Формально (не содержит обязательных элементов по законодательству РБ)
- Поверхностно (не декомпозирует темы на решаемые задачи)
- Неуправляемо (отсутствуют точки контроля, критерии успеха, бюджет)
- Демотивирующе (стимулирует занятость, а не результат)
- Неконкурентно (не позволяет привлекать таланты вне штатного расписания)
Экосистемный подход https://expert.8m.by представляет собой концептуальный переход от управления занятостью к управлению по результатам. Его ключевые принципы:
- Задача, а не функция – единица планирования
- Решение, а не отчёт – критерий завершённости
- Конкурс, а не назначение – механизм отбора
- Репутация, а не должность – основа авторитета
- Публичность, а не закрытость – условие достоверности
Этот переход не просто технологическое обновление — это смена вектора движения, адекватного эпохе цифровой трансформации и требованиям программно-целевого бюджетирования.
![]()