внешней информационной системы управления проектами

Когда говорят о внешней информационной системе управления проектами, многие сразу представляют себе некий волшебный ?черный ящик?, который сам все организует. Это, пожалуй, самый распространенный и дорогостоящий миф. На практике же, такая система — это прежде всего инструмент интеграции, и ее эффективность на 90% определяется не функционалом, а тем, как она встраивается в существующие процессы компании и — что критично — во внешнюю среду заказчиков и подрядчиков. Слишком часто внедрение превращается в попытку натянуть готовое решение на уникальную, живую ткань проекта, что приводит к обратному результату: росту хаоса и бумажной волокиты.

Суть проблемы: зачем выходить за периметр?

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

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

На своем опыте в ООО Хэнань Цзюйхэ Текнолоджи мы пришли к этому через серию неудач. Один из наших первых крупных проектов по автоматизации логистического хаба чуть не сорвался как раз из-за срывов сроков поставки комплектующих. Внутренне у нас все было отлично, но наш ключевой поставщик в Тульской области работал по своим, ?бумажным? регламентам. Информация о задержке производства детали приходила с опозданием в неделю, что каскадно влияло на все последующие этапы. Стало ясно, что нужен общий, максимально простой и наглядный инструмент статусов, доступный и нам, и поставщику.

Критерии выбора: не фичи, а ?стыковки?

Когда мы начали анализировать рынок, то быстро отмели подход ?самой многофункциональной системы?. Для внешнего взаимодействия избыточность — враг. Подрядчик не будет месяц учиться работать в сложном интерфейсе. Ключевых критериев оказалось три: открытый API для интеграции с нашими внутренними сервисами, гибкая модель ролей и прав (вплоть до уровня отдельного поля в карточке задачи), и возможность независимого хостинга данных. Последнее — частое требование наших клиентов из госсектора и промышленности, которые опасаются публичных облаков.

Мы рассматривали как российские платформы (например, ?ПланФикс? с его хорошими инструментами для привлечения контрагентов), так и кастомизированные решения на базе OpenSource. Интересный кейс был с использованием Redmine с плагином ?Рога и копыта? — шутка, конечно, но суть в том, что его удалось относительно дешево адаптировать под конкретный проект с немецким оборудованием, где основной поток задач был по регламентному обслуживанию. Но для масштабирования это не подошло.

В итоге, для своих клиентов мы часто рекомендуем и помогаем внедрять гибридную схему. Внутри компании-заказчика работает его основная ERP или CRM, например, 1С или более специализированная система. А для взаимодействия с внешним кругом подрядчиков и поставщиков разворачивается легковесная, но tightly integrated внешняя информационная система управления проектами. Часто это может быть даже кастомизированный проект на базе Битрикс24, но вынесенный на отдельный, нейтральный домен, с сильно урезанным по сравнению с корпоративным порталом функционалом — только задачи, документооборот, календарь этапов и форум.

Типичные грабли и как мы на них наступали

Самая большая ошибка — попытка автоматизировать все и сразу. В одном из пилотных проектов мы, движимые благими намерениями, включили в контур внешней системы не только управление задачами, но и детализированный финансовый модуль с планированием бюджета. Это сразу же насторожило подрядчиков, они начали занижать сроки в системе, вести ?реальную? отчетность в сторонних файлах, и смысл системы был потерян. Пришлось откатываться и запускать все поэтапно: сначала только обмен документами и календарный план, потом — трекинг задач, и только через полгода успешной работы — базовый финансовый трекинг по этапам.

Вторая проблема — ответственность за данные. Кто должен вносить информацию? Если статус задачи меняет подрядчик, а срок контролирует ваш менеджер, система должна иметь четкие правила и напоминания. Мы столкнулись с ситуацией, когда из-за невнесенного вовремя статуса ?ожидание решения заказчика? автоматически срабатывала просрочка по вине подрядчика, что вызывало конфликты. Пришлось вводить роль модератора или ?владельца процесса? с нашей стороны, который ежедневно сверял автоматические алерты с реальным положением дел.

И третье — техническая поддержка для внешних пользователей. Оказалось, что нельзя просто дать ссылку на мануал. Для каждого нового контрагента, особенно немолодого технического специалиста, нужна была 15-минутная вводная сессия по Zoom. Мы даже создали серию двухминутных скринкастов ?как поставить задачу?, ?как загрузить акт?. Без этого порог входа оказывался слишком высоким.

Кейс: интеграция в цепочке поставок

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

Мы предложили и развернули для них внешний контур на базе модифицированного решения, доступного через hnjhkjjt.ru как часть наших сервисов. Ключевым было создать для поставщика сырья простейший интерфейс: он видит утвержденный график поставок на месяц, может подтвердить объем или отметить задержку, прикрепить сканы транспортных накладных. Для транспортной компании — свой вид: список грузов к перевозке, точки маршрута, возможность внести данные трекера. При этом клиент в своей внутренней системе видел агрегированную картину: статус всего заказа.

Эффект был достигнут не мгновенно. Первые две недели подрядчики продолжали дублировать информацию звонком менеджеру. Но когда менеджер начал строго ссылаться на данные из системы (?Иван Иваныч, я вижу в системе, что вы отметили отгрузку только на 5 тонн, а по графику 10?), процесс пошел. Через три месяца удалось снизить ?телефонный? трафик по этим вопросам на 70%, а количество срывов сроков из-за человеческого фактора — примерно на 40%.

Вместо заключения: система как процесс, а не продукт

Главный вывод, который мы сделали — успешная внешняя информационная система управления проектами это не софт, который ты купил и установил. Это живой процесс согласования и постоянной адаптации. Ее нельзя просто ?внедрить?, ее нужно выращивать вместе с проектной командой и внешними партнерами. Иногда нужно отключать лишние модули, иногда — добавлять простые чек-листы.

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

Поэтому, если сейчас кто-то думает о внедрении подобного инструмента, мой совет — начните с самого болезненного, узкого места во взаимодействии с одним, самым лояльным внешним партнером. Автоматизируйте только его. Посмотрите, что получится, где начнутся трения. И уже от этого ?пятна контакта? постепенно расширяйте периметр. Это долго, не так эффектно, как ?большой bang-запуск?, но зато результат будет реальным, а не виртуальным. В конце концов, любая система — лишь отражение реальных отношений между людьми в проекте.