1. Философские основания

АспектТрадиционный подходЭкосистемный подход (https://expert.8m.by)
ОнтологияОрганизация как иерархическая машинаОрганизация как платформа/экосистема
Природа работникаФункциональная единица штатного расписанияАвтономный агент с репутационным капиталом
Природа знанияСобственность организации, закрытый активПубличный ресурс работника, измеримый через достоверность
Логика управленияАдминистративно-директивнаяКооперативно-упорядоченная
Единица планированияТема/мероприятие как описание деятельностиЗадача как снятое противоречие с измеримым результатом

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

2. Структурный анализ планирования

2.1. Традиционная модель НИР

Архитектура плана:

Тема (общее направление)

  └── Мероприятие (описание деятельности)

        ├── Ответственный исполнитель (должность)

        ├── Привлекаемое подразделение

        └── Срок: «в течение года»

Критические дефекты структуры:

  1. Отсутствие декомпозиции: Тема не разбивается на конкретные решаемые задачи. Например, «ОКР по созданию ПО «Информационно-кооперационная платформа»» – это описание процесса, а не то, что должно быть получено.
  2. Фиксация на должностях: «Начальник сектора», «Начальник управления» – роли привязаны к штатному расписанию, а не к компетенциям для конкретной задачи.
  3. Временная аморфность: «В течение года» лишает плана управленческого смысла. Невозможно определить точки контроля, критические пути, риски срыва.
  4. Отсутствие бюджетной детализации: Нет приведённой стоимости задач, нет учёта рисков в бюджете.
  5. Отсутствие критериев успеха: Нет измеримых порогов, по которым можно судить о завершённости.

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 с.

План верификации:

  1. Построить математическую модель зависимости времени отклика от числа уникальных конфигураций.
  2. Разработать прототип на Python/FastAPI с имитацией edge-слоя.
  3. Провести нагрузочное тестирование (100 предприятий, 10 типовых профилей персонализации).
  4. Сравнить с базовым вариантом (традиционное кэширование).

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. Заключение

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

  1. Формально (не содержит обязательных элементов по законодательству РБ)
  2. Поверхностно (не декомпозирует темы на решаемые задачи)
  3. Неуправляемо (отсутствуют точки контроля, критерии успеха, бюджет)
  4. Демотивирующе (стимулирует занятость, а не результат)
  5. Неконкурентно (не позволяет привлекать таланты вне штатного расписания)

Экосистемный подход https://expert.8m.by  представляет собой концептуальный переход от управления занятостью к управлению по результатам. Его ключевые принципы:

  1. Задача, а не функция – единица планирования
  2. Решение, а не отчёт – критерий завершённости
  3. Конкурс, а не назначение – механизм отбора
  4. Репутация, а не должность – основа авторитета
  5. Публичность, а не закрытость – условие достоверности

Этот переход не просто технологическое обновление — это смена вектора движения, адекватного эпохе цифровой трансформации и требованиям программно-целевого бюджетирования.

Loading

0

Автор публикации

не в сети 19 часов

Владимир Лемех

0
Комментарии: 2Публикации: 287Регистрация: 21-02-2021
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest
0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
Авторизация
*
*
Генерация пароля

Вы не можете скопировать содержимое этой страницы

0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x