ЕМДЕВ

@emdev
+292
с 13.02.2026

Блог компании ЕМДЕВ https://www.emdev.ru/. Разработчик и вендор ПО для бизнеса. Об интранете, HR, интеграционных шинах, low/no-code и немного об ИИ

28 подписчиков
0 подписок

Парадокс в том, что хороший портал как раз освобождает время для разговора. Когда базовый контекст уже лежит на сайте рабочей группы (состав команды, документы, события) встреча не превращается в пересказ того, что можно было прочитать.

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

Да, именно. В нашем видео https://incomand.ru/ru/b/incomand_workgroup мы как раз показываем, как портал становится точкой сборки, т.е. проект виден целиком - люди, документы, события и решения.

1

Портал не конкурирует с таск‑менеджером. Он закрывает другой пласт задач - общую инфраструктуру знаний, документов и коммуникаций, которые Jira просто не видит. Проект не живет в одной доске задач

2

Мы не обещаем заменить мессенджер. Инкоманд делает другое, он выстраивает карту проектной жизни внутри компании. Рабочие группы это центр знаний о проекте - кто участвует, какие документы важны, какие события произошли и планируются, какие решения приняты. Мессенджер остается, но вместо центра обмена знаниями о проекте, становится инструментом оперативных коммуникаций.

1

Если вам интересны именно архитектурные паттерны и практические ограничения решения, приглашаем посмотреть эту статью: https://habr.com/ru/articles/1028932/ Она как раз написана для технической аудитории и дополняет общий бизнес-фокус пресс-релиза.

1

Спасибо за точную формулировку, вы очень хорошо описали запрос рынка: всем нужно именно «импортозамещение без шока». Мы так и проектируем технологию - как инструмент управления переходным периодом, когда часть команды ещё живет в SharePoint, а часть уже работает в новом корпоративном портале.

По синхронизации. Мы говорим не о разовых выгрузках, а о двустороннем обмене изменениями по реестрам, спискам и заявкам в режиме, близком к реальному времени. Именно на этом уровне решается проблема потери заявок и рассинхрона версий - бизнес продолжает работать, а данные остаются целостными, даже если подразделения переходят на новую систему поэтапно.

По масштабу. Инкоманд позиционируется как enterpise-платформа и уже используется на проектах с нагрузкой в десятки тысяч пользователей и распределённой филиальной структурой. Например в Газпромнефти. Технология двусторонней синхронизации разрабатывалась как часть стратегии именно для таких сценариев - поэтапный вывод крупных компаний с SharePoint на российский стек без остановки процессов.

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

Спасибо за такой точный комментарий, он очень хорошо описывает реальную картину проектов импортозамещения.
Именно по этой причине мы и зафиксировали тезис про «20% успеха» в публичной коммуникации. Перенести базы и списки в отечественный стек технически действительно не так сложно. Самый болезненный этап начинается позже — когда тысячи сотрудников продолжают работать по старым привычкам, а внутренние процессы ещё не успели адаптироваться к новой среде.

В наших проектах мы стараемся не ограничиваться «коробочным» переносом данных. Двусторонняя синхронизация между SharePoint и «Инкоманд» — это инструмент для мягкого перехода, который позволяет запустить гибридный режим, не останавливая операционку и не заставляя всех «перепрыгивать» за одну ночь. Но технология сама по себе не решает вопрос хаоса в заявках, если нет управляемого сценария миграции.

Да, здесь вы правы. Но цель статьи - дать верхний уровень зрелости, а не минимальный must-have. В маленьких командах многие вещи можно упростить и совмещать роли. Если начать хотя бы с ограничений на смешанные PR (рефакторинг + новая функциональность + обновление зависимостей), ручного одобрения новых пакетов и базовой матрицы «что ИИ делает сам, а что только с подтверждением», риски уже заметно падают.

1

Спасибо за комментарий.
Мы как раз и разработали чек-лист в первую очередь для тех тем команд, которые «просто живут с Copilot’ом», а потом ловят последствия от несуществующих пакетов до уязвимостей в аутентификации. Цифры про 2–4× ускорение разработки при том, что более 40% ИИ-кода содержит проблемы безопасности и XSS встречается в 2,74× чаще взяты из исследования по реально ушедшему в прод ИИ-коду.

2