Керівнику країни в Таллінні потрібно запустити застосунок для погоджень до кінця кварталу. Груповому IT, яке працює в іншій столиці, необхідно, щоб усі застосунки в tenant дотримувалися однакових правил роботи з даними. Обидва запити є обґрунтованими, і без узгодованого розподілу відповідальності вони вступають у конфлікт. Microsoft Power Platform дозволяє один раз визначити цей розподіл на рівні конфігурації, замість того щоб переглядати його для кожного нового застосунку. Нижче наведено карту того, які механізми контролю належать групі, які — дочірній компанії в Балтії, а також чотири функції, що забезпечують цей поділ: політики роботи з даними, групи середовищ, ізоляція tenant і pipelines.

Іноземна власність є структурною особливістю економіки Балтійських країн. У 2023 році 10,9% підприємств Естонії перебували під іноземним контролем — це другий найвищий показник у ЄС після Люксембургу, згідно зі статистикою Eurostat щодо підприємств під іноземним контролем (Eurostat, Foreign-controlled enterprises statistics – inward FATS, data for 2023). Кожна з таких дочірніх компаній працює в системах, які були обрані на рівні групи. Проте ці системи рідко охоплюють локальні процеси продажів, ланцюжки погоджень у конкретній країні або звіти, які потрібні керівнику країни перед щомісячною зустріччю групи. 

Це створює два передбачувані сценарії. Локальні команди або створюють неофіційні інструменти на основі електронних таблиць та персональних автоматизацій, або стають у чергу до групового IT-беклогу, який одночасно обслуговує всі країни. Жоден із цих підходів не є повноцінним управлінням IT у дочірніх компаніях: перший ігнорує групу, другий — потреби бізнесу. Power Platform пропонує третій шлях: локальні команди створюють рішення в межах правил, які група визначає один раз. Saint-Gobain Baltic, що входить до міжнародної промислової групи, автоматизувала процес продажів за допомогою застосунку на Power Platform, створеного без використання Dynamics 365 Sales. 

Найзручніше проводити межу на рівні руху даних. Power Platform підтримує політики роботи з даними як на рівні tenant, так і на рівні середовищ, і ці два рівні безпосередньо відповідають групі та дочірній компанії. Групове IT, яке має роль адміністратора Power Platform, визначає політики tenant-рівня, що класифікують, які конектори можуть обмінюватися даними. Адміністратор середовища в дочірній компанії може додатково створювати політики на рівні середовищ, якими він управляє. 

Ця ієрархія працює лише в одному напрямку. Адміністратори середовищ не можуть виключити свої середовища з-під дії політик tenant-рівня, а політики середовищ не можуть перевизначати загальні політики tenant. Команда країни може накладати власні правила поверх групових, але ніколи не може їх прибрати. Саме ця асиметрія робить управління IT у дочірніх компаніях масштабованим: група один раз визначає базові правила, а кожна дочірня компанія розвиває власні рішення без повторного узгодження основ. 

Групи середовищ Microsoft дозволяють адміністраторам об'єднувати середовища за організаційними одиницями, і Microsoft прямо вказує дочірні компанії як один із критеріїв такого групування. Коли адміністратор tenant застосовує правила на рівні групи, відповідні налаштування стають доступними лише для перегляду в усіх середовищах групи, і локальні системні адміністратори не можуть їх змінити. Такі правила охоплюють спільний доступ, увімкнення AI-функцій, зберігання даних та управління життєвим циклом застосунків. 

Одне обмеження визначає всю архітектуру. Групи середовищ не підтримують винятки для окремих середовищ і можуть містити лише керовані середовища (Managed Environments). Якщо литовській юридичній особі потрібні інші обмеження спільного доступу, ніж естонській, для неї необхідно створити окрему групу. Це рішення потрібно приймати на етапі впровадження, ще до того, як makers створять рішення, які потім доведеться переносити. 

Маршрутизація середовищ (environment routing) закриває останню прогалину. Новий maker не починає роботу в спільному середовищі за замовчуванням. Натомість він отримує власне середовище розробника, створене всередині групи, визначеної IT, із застосуванням правил цієї групи вже з першого дня. 

Не кожна дочірня компанія працює в одному tenant Microsoft Entra із групою — деякі мають власний tenant. Межі такого сценарію визначає ізоляція tenant у Power Platform: якщо ізоляція ввімкнена, міжtenantні підключення блокуються навіть за наявності дійсних облікових даних користувача. Після цього адміністратори можуть створити список дозволених tenant для вхідних, вихідних або двосторонніх підключень. 

Для дочірньої компанії в Балтії, яка працює у власному tenant, практичним підходом є додавання tenant групи до списку дозволених. Погоджені інтеграції з головним офісом продовжують працювати, а підключення до будь-яких інших tenant залишаються заблокованими. Ізоляція поширюється лише на конектори, що використовують автентифікацію через Microsoft Entra ID, наприклад Office 365 Outlook або SharePoint. Конектори з іншими способами автентифікації не підпадають під її дію.

Pipelines у Power Platform дозволяють makers розгортати рішення із середовищ розробки до тестових і production-середовищ у кілька кліків без надання розширених прав доступу до цільових середовищ. Групове IT може доповнити pipeline етапами погодження, розгортанням через service principal та інтеграцією з Azure DevOps або GitHub. Дочірня компанія визначає темп впровадження, а група зберігає контроль над погодженням. 

Ті самі механізми підтримують модель «створити один раз — розгорнути багато разів». Для L'Oréal компанія OntargIT створила рішення Power Fluence для Іспанії та Португалії з подальшим розгортанням у регіоні EMEA. Також було створено рішення Pricing Workflow для Великої Британії та Ірландії з подальшим впровадженням у Європі та Південній Африці — як частину роботи OntargIT у межах Power Platform Center of Excellence. Для Aker Solutions OntargIT поєднала Power Platform, SharePoint, Power Automate та Azure DevOps для організації внутрішньої звітності в міжнародній корпорації. 

Управління IT у дочірніх компаніях працює тоді, коли межі делегування узгоджуються до запуску першого локального застосунку, а не після десятого. Перевірте свою поточну конфігурацію за чотирма параметрами: 

• чи визначені ваші політики роботи з даними на рівні tenant чи середовища;
• чи відповідають групи середовищ структурі ваших юридичних осіб;
• чи використовує дочірня компанія в Балтії спільний tenant групи;
• чи розгортають локальні makers рішення через pipelines.

Якщо хоча б одна відповідь не є очевидною, замовте безкоштовну консультацію — це допоможе визначити модель управління, яку зможуть погодити і групове IT, і локальна команда під час однієї робочої сесії.