On-premise: Shtab на своих серверах, в вашем контуре

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

В итоге компания либо остаётся на табличках и почте, потому что «нормальное всё равно не согласуют», либо тратит месяцы на поиск системы, которую можно поставить в собственный контур. А когда такая система находится, всплывает вторая сложность: развернуть её своими силами — отдельный проект. Нужно понять требования к инфраструктуре, установить, настроить, разграничить доступ, перенести работу команд. Системный администратор, у которого и без того полно задач, тянуть это в одиночку не хочет, и внедрение снова откладывается. Получается замкнутый круг: облако не согласуют, а on-premise страшно разворачивать. Работа при этом живёт в разрозненных файлах, где нет ни общей картины, ни контроля доступа, — ровно там, где рисков для данных больше всего.

Из чего складывается режим on-premise и что вы получаете, размещая Shtab в своём контуре:

• Развёртывание в вашей инфраструктуре — Shtab устанавливается на серверы компании, внутри её закрытого контура; данные не уходят на сторонние серверы, а остаются в периметре организации под её правилами.
• Тариф «Корпорация» как основа — вариант для установки в закрытый контур (On-premise): полный контроль над данными, соответствие требованиям регуляторов и бессрочная лицензия. Стоимость и условия обсуждаются с менеджером под ваш случай.
• Российская платформа из реестра — Shtab разрабатывается в России и числится в реестре отечественного ПО, что обычно и требуется службе безопасности и отделу закупок для допуска системы в контур.
• Гибкие права и роли — доступ настраивается под оргструктуру: собственные роли, ограничение модулей и действий, закрытые финансы и цели компании для лишних глаз. Как это устроено — в статье про настраиваемые права и роли.
• Высокий уровень безопасности и контроля — вариант рассчитан на организации с повышенными требованиями к ИБ: данные внутри периметра, доступ под контролем, картина «кто к чему допущен» — управляемая.
• Работа с большими объёмами данных — контур держит множество проектов, задач и пользователей одновременно, что важно для крупной организации с десятками команд.
• Весь инструментарий Shtab — задачи и канбан-доски, планирование сроков, база знаний, цели, учёт времени и финансы работают в контуре так же, как в облаке; режим меняет размещение, а не возможности.
• Сопровождение внедрения — развёртывание и настройку в вашей инфраструктуре проводит команда Shtab и помогает перенести работу; это не «поставь сам по инструкции», а внедрение с поддержкой.

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

Начали не с установки, а с разбора требований. Служба ИБ выписала, что нельзя выносить за периметр и какие условия к размещению обязательны; ИТ прикинул инфраструктуру; закупки сверили Shtab с требованиями к отечественному ПО — платформа в реестре, это сняло первый вопрос. Убедившись, что данные обязаны оставаться в контуре, выбрали вариант on-premise — тариф «Корпорация» с установкой в закрытый контур компании. Развёртывание в инфраструктуре организации провела команда Shtab и сопроводила внедрение, а не оставила администратора один на один с дистрибутивом.

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

Раздел для организаций, где данные о проектах, задачах и людях нельзя размещать во внешнем облаке — по требованиям безопасности, регуляторов или внутренней политики. Полезен службам информационной безопасности, которые не согласуют хранение чувствительной информации на чужих серверах; ИТ-директорам и системным администраторам, которым поручили развернуть систему управления в собственном контуре; отделам закупок, сверяющим решение с требованиями к отечественному ПО и размещению данных; руководству компаний, где контроль над данными — обязательное условие, а не пожелание. Особенно актуально для банков и страховых, госсектора, промышленности, оборонных и проектных структур, а также для крупного бизнеса, работающего с персональными данными и коммерческой тайной. Если компания спокойно работает в облаке и ограничений на размещение данных нет — on-premise разворачивать незачем: облачный Shtab дешевле и быстрее в запуске, а набор функций тот же. Сценарий имеет смысл ровно тогда, когда данные обязаны оставаться внутри периметра.

• Прохождение требований ИБ — согласована ли служба безопасности с размещением: данные в контуре, условия хранения выполнены. Пока этот пункт не снят, система до внедрения не дойдёт.
• Данные в периметре — вся ли чувствительная информация размещена в закрытом контуре компании, а не осталась в облачных сервисах или разрозненных файлах «снаружи».
• Соответствие требованиям закупок — закрыт ли вопрос отечественного ПО и размещения данных: решение из реестра, установка в своём контуре, права под оргструктуру.
• Управляемость доступа — настроены ли роли под структуру организации и понятно ли, кто к чему допущен; для on-premise это не удобство, а часть требований безопасности.
• Охват контура — сколько подразделений реально перешло в единую систему внутри периметра, а не осталось каждое в своих таблицах и почте.
• Работа в одной системе — ведут ли команды проекты и задачи в Shtab, а не по привычке в файлах на общих дисках; собрана ли работа в один управляемый контур.

• Сначала честно ответьте, нужен ли вам закрытый контур. Если жёсткого запрета на облако нет, облачный Shtab дешевле, быстрее в запуске и функционально не беднее — on-premise берут ради размещения данных, а не ради галочки.
• Соберите требования ИБ, закупок и ИТ до первого разговора с менеджером. Чем точнее сформулировано, что нельзя выносить за периметр, тем предметнее пройдёт обсуждение развёртывания.
• Не пытайтесь развернуть систему силами одного администратора. On-premise разворачивает команда Shtab с сопровождением — так внедрение не вязнет между делами перегруженного айтишника.
• Разграничьте доступ через роли до того, как заведёте чувствительные проекты. В контуре важно не только где лежат данные, но и кто внутри к ним допущен, — проще задать правила сразу, чем потом закрывать открытое всем.
• Запускайтесь не всей организацией разом, а с одного подразделения: отладьте роли и процесс на пилоте, затем тиражируйте по шаблону. Сотни пользователей одним днём — верный способ вернуть людей к таблицам.
• Не путайте два проекта: размещение системы в своём контуре (этот раздел) и перенос работы с зарубежных инструментов — импортозамещение — решаются по отдельности, хотя часто идут вместе.

• Берут on-premise «на всякий случай». Разворачивают систему в контуре без реального запрета на облако — дороже и дольше там, где хватило бы облачного тарифа. Починка: проверить, есть ли настоящее требование держать данные в периметре.
• Выбирают систему без службы ИБ. Подбирают трекер по удобству интерфейса, а потом он не проходит согласование по размещению данных. Починка: собрать требования безопасности и закупок до выбора.
• Пытаются развернуть в одиночку. Установку и настройку в контуре вешают на одного перегруженного администратора — и внедрение застревает. Починка: разворачивать с сопровождением команды Shtab, вести переход как проект.
• Забывают про права внутри контура. Считают, что раз данные в периметре, то доступ уже безопасен, и открывают всё всем. Починка: настроить роли под оргструктуру, закрыть финансы и цели компании на ограниченный круг.
• Путают размещение и миграцию. Смешивают «поставить в свой контур» и «перенести с Jira» в один ком и тонут в объёме. Починка: развести режим on-premise и импортозамещение на два этапа.
• Запускают всё разом. Разворачивают на всю организацию одним днём, люди не успевают перестроиться и возвращаются к файлам. Починка: пилот на одном подразделении, потом тиражирование.

Режим on-premise выбирают по-разному, в зависимости от того, откуда идёт требование. Там, где на первом плане служба безопасности и хранение чувствительных данных, разговор начинается с размещения и модели доступа: настройка ролей опирается на статью про права и роли, а условия установки в закрытый контур обсуждаются с менеджером на странице тарифов. Организациям госсектора и банкам важнее всего соответствие требованиям регуляторов и хранение данных в периметре — для них on-premise не опция, а условие допуска. Крупному бизнесу с десятками команд наравне с безопасностью нужен масштаб: единый контур на множество проектов и пользователей, права под оргструктуру. Важно не путать два соседних вопроса: этот раздел — про сам режим размещения в своём контуре, а перенос работы с зарубежных инструментов разбирает сценарий импортозамещения; часто их делают вместе, но это разные проекты. Процесс закупки и внедрения для крупной организации со стороны ИБ и закупок описан отдельно, в сценарии для корпораций. А чтобы выстроить работу в самой системе после развёртывания, опирайтесь на разделы управления проектами, для PMO и для руководителя.