Ваша команда руководителей считает, что это вопрос внедрения. Это не так. Это решение, требующее управления, с очень коротким сроком действия, и давление велико, потому что Копайлот не ждет, пока вы упорядочите свои политики или согласуете внутренние процессы. Как только он начинает работать в вашей среде, он использует систему именно так, как ее находит, и именно здесь возникает проблема. Большинство организаций с несколькими арендаторами Microsoft 365 предполагают, что у них есть единая стратегия управления и, в основном потому, что они покупают у одного поставщика и управляют одной системой идентификации. Они слышат одну стратегическую концепцию от Microsoft и предполагают, что реальность соответствует презентации. Но условия работы совершенно иные, и работают на границах арендаторов, в то время как риски перемещаются между ними. Поэтому вопрос не в том, можем ли мы включить Копайлот везде. Настоящий вопрос в том, какая модель управления позволит нам безопасно масштабироваться между арендаторами, которые ведут себя независимо. Прежде чем мы перейдем к этой модели, нам нужно определить ловушку. Ловушка — суверенные островки и внутри одного предприятия. В большинстве организаций иллюзия начинается со знакомства. Вы открываете Microsoft 365, вы открываете Perview, вы открываете интро, вы открываете Power Platform. Брендинг одинаков. Язык администрирования кажется единым, а коммерческая составляющая рассказывает очень понятную историю. Одна экосистема, одна стратегия, одно направление. Но модель управления, лежащая в основе, не является чем-то одним, и это важнее, чем брендинг. На основе проведенного исследования не существует единого глобального центра администрирования и с полным функциональным разнообразием, который бы предоставлял единое место для четкого управления Копайлот во всех арендаторах. На самом деле, у вас есть фрагментированный стек управления. Часть управления находится в Perview, другая часть — в центрах администрирования, а остальное разбросано по интро и Power Platform. Некоторые функции появляются в новых уровнях управления Microsoft, но они еще не формируют единую зрелую глобальную плоскость, охватывающую все арендаторы. Этот разрыв создает ложную уверенность. Руководители смотрят на экосистему и предполагают централизацию, в то время как команды смотрят на общую идентичность и предполагают согласованность. Отдел закупок видит единое соглашение и предполагает единую операционную модель, но каждый арендатор по-прежнему имеет свои собственные границы политики и свои собственные границы данных, что означает, что на практике каждый из них имеет свою собственную версию истины.

Таким образом, на самом деле все просто. У вас не одна корпоративная среда и, у вас несколько сред и, которые принадлежат одному и тому же предприятию. Это совершенно другая картина рисков. Один клиент может иметь более широкий охват, в то время как другой — более слабое использование меток или неполный ввод данных аудита. С точки зрения совета директоров это может выглядеть как одна программа, но с точки зрения аудита или инцидентов это вовсе не одна программа. Это набор отдельных условий эксплуатации. И как только эти условия начинают меняться, отчетность начинает лгать. Не намеренно, а структурно. Ключевая команда спрашивает, управляем ли мы. Один клиент отвечает «да», потому что аудит включен. Другой отвечает «да», потому что метки существуют, даже если охват слабый. Третий отвечает «да», потому что идентификация связана. Четвертый отвечает «да», потому что капайлот технически развернут. Каждый ответ звучит разумно сам по себе, но ни один из них не означает одно и то же. В этом ловушка. Вы думаете, что смотрите на глобальную плоскость управления, тогда как на самом деле вы видите набор суверенных островков и внутри одной компании. Они связаны брендом, а иногда и идентичностью, но не управляются как единая система.

И если вы ничего больше не запомните из этого раздела, запомните эту фразу. Нет глобального центра администрирования и есть только иллюзия его существования. Как только эта иллюзия рушится, быстро возникает следующая проблема. Большинство организаций реагируют, управляя каждым арендатором вручную, и называют это контролем. Почему ручное управление каждым арендатором рушится в масштабах? Как только руководители видят проблему границ, обычный ответ кажется разумным. Они говорят «хорошо, мы будем должным образом управлять каждым арендатором». Одна команда администраторов проверяет настройки здесь, другая команда повторяет их там. Кто-то ведет электронную таблицу, кто-то составляет контрольный список. Руководящая группа встречается раз в месяц и спрашивает, идет ли развертывание по плану. На бумаге это выглядит дисциплинированно. На практике это ручное повторение, замаскированное под управление. И причина, по которой это терпит неудачу, проста. Повторение не создает контроля, оно создает вариативность во времени. Это происходит потому, что каждый арендатор работает с разной скоростью, каждый администратор по-разному интерпретирует стандарты, и локальные исключения начинают казаться оправданными, поскольку бизнес хочет прогресса сейчас, а не после очередной централизованной проверки. Эта старая модель выживает, потому что она кажется наглядной. Люди могут указывать на закрытые заявки, созданные политики и измененные настройки. Они могут демонстрировать активность, но видимые усилия — это не то же самое, что стабильная операционная модель. А с появлением Капайлот этот пробел очень быстро становится дорогостоящим. Система начинает использовать существующее разрешение, существующий доступ к контенту и существующие пробелы в маркировке в тот момент, когда пользователи начинают запрашивать информацию. Именно это большинство людей упускает из виду. Капайлот не ждет зрелости управления. Он работает на основе уже имеющихся у вас разрешений, уже допустимой вами гигиены контента и стандартизированного подхода к аудиту, который вы так и не смогли стандартизировать.

Если один арендатор очистил доступ, а другой удалил его, или если один арендатор передает полезные данные аудита, а другой едва собирает достаточной информации для расследования, Капайлот немедленно выявит эти различия. Это происходит не в теории, а на практике. Если один пользователь проверил широкий доступ к SharePoint, а другой посчитал, что этого достаточно, и обнаружит пробелы. И на более глубоком уровне каждый новый пользователь усугубляет проблему, не потому что пользователи плохие, а потому что накапливаются неуправляемые различия. Одна новая пилотная группа добавляет локальное исключение. Слияние приводит к появлению другого пользователя с другими метками, а региональный администратор копирует старую базовую конфигурацию. Бизнес-подразделение запрашивает более быстрый доступ, и ни один из этих вариантов сам по себе не выглядит радикальным. Если же их объединить на несколько месяцев, получится дрейф-политик, дрейф-доступа и дрейф-развертывания. В результате команда управления тратит больше времени на согласование различий, чем на предотвращение рисков.

Вот где ручной контроль дает сбой. Кажется, что это безопасней, потому что настройки контролируются людьми, но на самом деле это приводит к масштабируемой несогласованности, потому что каждая точка контакта – это еще один шанс для пользователей расходиться во мнениях. В результате – замедление развертывания там, где нужна скорость, больше усилий по аудиту там, где нужны доказательства, и больше доработок там, где нужны стандарты. Хуже всего-то, что это создает скрытую уязвимость там, где руководство ожидает гарантий. Я понял это, когда перестал рассматривать управление как задачу настройки. Это не так. Оно больше похоже на деградацию. Если вы один раз исправляете разрешение, но никакой контроль не предотвращает их повторное изменение, уязвимость возвращается.

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

Доступ выглядит унифицированным, вход в систему выглядит унифицированным, архитектурная схема выглядит аккуратной, но управление Copilot не становится унифицированным только потому, что идентификация может перемещаться. Это предположение не работает в том месте, где и действительно работает. Copilot основывает ответы в контексте арендатора, где выполняется запрос, и собственные рекомендации Microsoft ясно указывают на этот момент. Microsoft 365 Copilot работает в рамках безопасности и соответствия требованиям арендатора и уважает разрешение пользователя в этом конкретном контексте арендатора. Пользователь может переключать контекст как гость, да, но Copilot по-прежнему ограничен одним арендатором за раз. Он не объединяет несколько арендаторов в одно интеллектуальное рабочее пространство для получения одного ответа. Таким образом, идентификация может перемещаться, управление — нет. И как только вы разделяете эти два аспекта, многие формулировки руководителей начинают звучать опасно расплывчато. Связанные арендаторы — общая идентификация, унифицированный опыт.

Эти фразы могут быть в целом верны для совместной работы, но они не означают, что обеспечение соблюдения политик, привязка данных, ведение журналов и проверка контроля теперь работают как единая система. Этот разрыв становится еще более очевидным, если посмотреть на многопользовательский режим Copilot Studio, поскольку предварительная версия рассказывает очень конкретную историю. Да, многопользовательское использование существует, и агент, размещенный в одном клиенте, может использоваться из другого клиента, но аутентификация конечных пользователей в многопользовательском режиме пока не поддерживается в предварительной версии. Гостевые пользователи не поддерживаются. Пользовательские коннекторы не поддерживаются. Коннекторы Graph и Microsoft 365 Standard не поддерживаются. Многогеографическая аутентификация не поддерживается. Некоторые аналитические возможности недоступны. В этом режиме также отключена запись разговоров. Это незрелая система управления между клиентами. Это ограниченная предварительная версия с четкими ограничениями. И эти ограничения важны, потому что они разрушают представления, которые многие руководители рассказывают себе.

Они слышат о многопользовательском режиме и предполагают операционную зрелость. Их архитекторы слышат о межклиентском режиме и предполагают симметрию политик. Их команды управления слышат об одном поставщике и предполагают согласованность аудита. Затем начинается внедрение, и люди обнаруживают различное поведение, недостающие сигналы и неудобные пробелы в аутентификации и аналитике. Представьте второй случай. Глобальная компания устанавливает внутрикорпоративные связи между арендаторами и предполагает, что пользовательский опыт естественным образом распространиться и на использование Капайлот. Ожидание звучит разумно, учитывая доверие к общему каталогу, более плавный доступ и общие шаблоны идентификации. Но когда команды тестируют реальные сценарии Капайлот и агентов, поведение оказывается неравномерным. Некоторые данные появляются только в переключенных контекстах. Некоторые ожидаемые коннекторы недоступны. Некоторые ожидания аудита не совпадают с тем, что фактически предоставляют функции предварительной версии. Руководство по-прежнему слышит о подключении, в то время как команда контроля начинает находить исключения. Это не технический крайний случай.

Это неправильное понимание принципов управления, потому что аудиторы проверяют не вашу архитектурную историю, а доказательства. Они спрашивают, где выполнялись запросы, какой арендатор применял политику, какие журналы существуют и были ли ваши средства контроля действительно сопоставимы в средах, которые вы описали как связанные. Если ваша операционная модель рассматривает идентификацию как управление, у вас не будет однозначного ответа. Поэтому, если вы запомните здесь одну фразу, пусть это будет вот это. Межпользовательская идентификация — это не межпользовательская аналитика. Идентификация помогает пользователям войти в систему. Она не говорит о том, регулируется ли поведение капайлот последовательно, контролируется ли должным образом или безопасно ли масштабировать его во всех местах, которые ваше предприятие теперь называет одной средой. И как только это станет ясно, ответом не может быть увеличения количества связей между пользователями. Это должна быть архитектура. Модель управления, которая действительно работает, центр и периферия. Итак, как выглядит реальная модель управления, когда ваша платформа фрагментирована, идентификация лишь частично, а границы между пользователями все еще имеют значение. Она выглядит как система, центр и периферия. Я предлагаю это не потому, что диаграмма выглядит аккуратно на слайде, а потому, что она действительно соответствует сложным условиям работы, с которыми вы имеете дело прямо сейчас. Вам нужно одно центральное место, где решения по управлению разрабатываются, измеряются и обеспечиваются как единая система. А затем вам нужны локальные команды пользователей для выполнения этих решений. Эти локальные команды должны работать в рамках своих собственных границ, не изобретая свою собственную версию правил каждый раз, когда они чувствуют небольшое давление. Мы должны начать с центра. Центр управления – это не административный портал, не блестящая панель управления и уж точно не героическая централизованная команда, которая вручную проверяет файлы в каждом клиенте. Вместо этого центр управления выступает в качестве высшего органа управления. Эта группа отвечает за разработку политик, базовые показатели аудита, стандарты меток и критерии развертывания. Именно они решают, что на самом деле означает готовность к опайлот, какие доказательства считаются доказательствами и как быстро необходимо устранить уязвимость в системе безопасности. Этот сдвиг меняет весь подход. Благодаря такой структуре глобальный перестает быть словом, обозначающим один волшебный экран и начинает означать единую систему управления. Вы получаете один стандарт для контроля доступа, один стандарт для обработки результатов аудита и один стандарт для меток конфиденциальности. Существует один четкий критерий, которому должен соответствовать любой конкретный клиент, прежде чем ему будет разрешено расширить доступ к опайлот для большего числа пользователей. Затем вам нужны периферийные узлы. Периферийные узлы – это ваши локальные команды по выполнению задач в каждом клиенте, которые берут этот базовый уровень и применяют его к своей конкретной среде. Именно они проводят исправления, проверяют журналы и анализируют общие права доступа. Однако вся эта работа выполняется в очень узком пространстве проектирования, а не в условиях полной свободы действий.

Если местной команде необходимо отклониться от плана, существует формальный порядок для исключений. И если они хотят двигаться быстрее, им все равно сначала нужно выполнить общее требование контроля. Когда возникают региональные или юридические различия, эти проблемы документируются и утверждаются, вместо того, чтобы незаметно поглощаться каким-то локальным обходным путем, о котором никто не знает. Такая структура жизненно важна, потому что полностью централизованные модели обычно застревают на локальных деталях, в то время как полностью локальные модели почти сразу же впадают в полную несогласованность. Структура, центр и периферия позволяют избежать обеих этих проблем. Центр обеспечивает необходимую согласованность, а периферия – скорость выполнения там, где работа фактически ведется. Давайте рассмотрим это на конкретном примере. В центре вы определяете минимальный набор контрольных параметров, которые должен выполнить каждый арендатор, прежде чем капайлот сможет развиваться. Вы точно определяете, какие события аудита вы ожидаете увидеть и как часто вы будете их проверять. Вы также создаете общую таксономию меток для конфиденциального контента, чтобы метка «конфиденциально» не означала пять разных вещей для пяти разных арендаторов. Вы устанавливаете ритм проверок, возможно, ежемесячно для оценки общего уровня безопасности и чаще в тех областях, где развертывание в настоящее время активно.

На периферии ваша команда сопоставляет эти высокоуровневые стандарты с реальностью конкретного арендатора. Они определяют, какие сайты по-прежнему имеют открытый доступ и какие бизнес-подразделения отстают в маркировке. Они проверяют, действительно ли включен аудит и видны ли необходимые записи команде безопасности. Они ищут локальных администраторов, которые могли внести исключения, которые никогда не проверялись официально, и решают, может ли пилотная группа безопасно расширяться или необходимо сначала остановить процесс и исправить ошибки. И вот жесткое правило. Потому что без правила эта модель – всего лишь рекомендация, а не реальное управление. Ни одно развертывание к пилот не происходит ни в одном арендаторе без подтвержденного аудита, завершенного сканирования на предмет избыточного доступа и минимального базового уровня покрытия метками. Я говорю не о планировании или частичном обсуждении этих вещей. Они должны быть подтверждены. Если арендатор не может доказать выполнение этих трех условий, развертывание приостанавливается. Это может показаться строгим, пока вы не сравните это с огромными затратами на устранение последствий, когда пользователи начинают находить конфиденциальную информацию, которую вы никогда не собирались раскрывать, с помощью И. Если посмотреть на это с такой точки зрения, эти правила – просто здравый смысл. Еще одна причина, по которой эта модель так хорошо работает – это время. Чем дольше вы откладываете настройку, тем больше проблем вы создаете себе позже. Каждый арендатор, который развертывается раньше базового уровня, становится еще одним огромным списком исключений и недостающих данных, которые вашей команде в конечном итоге придется устранять. Руководители часто рассматривают управление как нечто, что может созреть после завершения внедрения, но в многопользовательском мире к-пайлот эта последовательность совершенно обратная. Управление должно руководить развертыванием, иначе развертывание создаст больше проблем, чем ваши команды когда-либо смогут решить.

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

Уровни активности не покажут вам правду, а показатели внедрения определенно не покажут риски. Следует начать с сокращения чрезмерного обмена информацией. Это по-прежнему один из самых очевидных признаков того, что ваша среда становится более безопасной для И. Необходимо обратить внимание на группы широкого доступа, открытые сайты SharePoint и старые разрешения, которые предоставляют гораздо больше доступа, чем действительно необходимо бизнесу. Цель здесь не в достижении идеального показателя, а в том, чтобы доказать, что ваша уязвимость снижается, прежде чем охват Капайлот увеличится. Если эти две линии движутся в противоположных направлениях, вы расширяетесь гораздо быстрее, чем решаете основные проблемы. Второй необходимый показатель – это охват мониторинга. Можете ли вы реально видеть, что делает Капайлот во всех ваших клиентах, таким образом, чтобы это позволило провести реальное расследование. Большинство исследований указывают на Microsoft Perview как на основное место хранения основных записей, таких как взаимодействие с Капайлот, но это предполагает, что у вас везде включен аудит. Охват – это не то, что можно просто считать работающим. Вам нужно точно знать, в каких клиентах активен сбор данных аудита, а в каких вы по-прежнему имеете лишь частичную видимость. Если у вас нет журналов, у вас нет управления и нет подотчетности.

Это звучит прямолинейно, потому что так и должно быть. Если клиент не может предоставить полезные доказательства того, что происходит, этот клиент не готов к безопасному масштабированию. Вы не можете управлять тем, что вам не разрешено проверять, и вы, конечно же, не сможете защитить свои действия, если позже что-то пойдет не так. Третий показатель – это время внедрения политик во всех клиентах. Здесь руководство выясняет, действительно ли модель «центр-периферия» реальна или это всего лишь декоративный элемент. Централизованное решение абсолютно ничего не значит, если один арендатор внедряет его на этой неделе, а другой ждет месяц, чтобы обдумать его. Вам следует измерить время, которое проходит от утверждения политики до ее эффективного внедрения в каждом арендаторе. Я говорю не о времени, необходимом для объявления или документирования, а о времени до фактического запуска. Для программы «И», которая развивается так быстро, такая задержка – это просто другое слово для обозначения риска.

Практическая цель для большинства организаций – менее 72 часов для стандартных изменений. Если ваш цикл намного дольше, у вас пока нет масштабируемой модели. У вас просто проблема координации, которую нужно решить. Далее вам нужно посмотреть на коэффициент покрытия метками. Не позволяйте этому превратиться в показатель тщеславия, когда один арендатор достигает высоких показателей, а другие отстают. Действительно важно, достаточно ли последовательно маркируется ваш конфиденциальный контент, чтобы поведение Копайлот не основывалось только на догадках пользователей. Здесь не требуется совершенства, но необходим сопоставимый уровень контроля для каждого клиента в организации. Наконец, необходимо отслеживать скорость изменения прав доступа. Этот показатель показывает, действительно ли ваши усилия по исправлению ситуации дают результаты с течением времени. После завершения проекта по устранению проблем, как быстро эти разрешения начинают снова распространяться. Как часто эти широкие группы пользователей возвращаются в систему. Многие команды понимают это слишком поздно, потому что они оценили эффективность исправления один раз и предположили, что проблема решена навсегда. Это не так.

Единственный важный показатель – это скорость, с которой система начинает давать сбои после того, как вы перестаете за ней следить. Это ваша операционная панель. Вам необходимо отслеживать снижение избыточного доступа, охват мониторинга, время внедрения политики, охват меток и изменение прав доступа. Ритм вашей отчетности также важен, как и сами цифры. Центр должен отвечать за панель управления для руководства, поскольку лидерам необходимо единое представление о всей ситуации. В то же время периферийные подразделения должны отвечать за исправление, поскольку фактическая работа должна выполняться там, где находятся границы клиентских учетных записей. Одна команда читает систему, а другая исправляет ее. Отслеживать эти показатели необходимо до расширения, а не после. Риск не ждет вашей следующей встречи или семинара по управлению. Он уже активен в каждом клиенте, где Копайлот может точно определить, что ваши текущие средства контроля по-прежнему позволяют ему видеть. Две закономерности, которые руководители постоянно упускают из виду. Я постоянно наблюдаю две конкретные закономерности в этой области, и обе они возникают из-за того, что руководители относятся к Копайлот как к запуску программного обеспечения, а не как к важному событию в области контроля. Первая закономерность начинается, когда организация внедряет Копайлот, не установив реальные базовые параметры доступа или не проверив доступ к SharePoint. В первый день внедрение выглядит идеально. Лицензии назначены, пользователи в восторге, и внутренние сообщения направлены на повышение производительности. Но затем обычные запросы начинают выводить материалы, которые технически были доступны все это время, но практически невидимы для среднего сотрудника.

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

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

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

Если это изменило ваше представление об управлении многопользовательскими системами Копайлот, подпишитесь на меня, Мирку Петерса, в LinkedIn и поделитесь этим со своей командой, если вы сейчас сталкиваетесь с подобными проблемами.