Power Platform vs custom development

Power Platform или custom development: что выбрать

Когда компаниям Казахстана выбирать Power Apps и low-code, а когда custom development: Dataverse, connectors, DLP, environments, ALM, governance и support.

Tugelbay Konabayev, Marketing Specialist · 9 июня 2026 г.

Короткий ответ

Быстро или правильно — неправильный выбор. Правильный вопрос:

• Какой процесс мы автоматизируем?
• Он стабилен или меняется каждый месяц?
• Где живут данные (Microsoft 365, 1С, облако)?
• Кто владеет — IT или бизнес?
• Какие ошибки будут дорогими?
• Кто это поддерживает через год?

Power Platform подходит для: согласований в Teams, заявок в SharePoint, форм в Power Apps, автоматизации рутины в Power Automate, расширений вокруг Dynamics 365. Быстро, видно результат, нет big engineering overhead.

Custom development подходит для: customer-facing product, сложная бизнес-логика, нестандартный UX, высокие нагрузки, полный control над архитектурой, долгосрочный roadmap.

Казахстанская реальность: согласования идут по почте (потеряются), заявки в чатах (потеряются), данные вручную между Excel–1С–CRM (ошибки), IT хочет дать бизнесу скорость без “каждый отдел создаёт свою форму”.

Этот гайд помогает выбрать первый маршрут: Power Platform для быстрой формы (weeks), или custom code для долгосрочного product (months). Не заменяет архитектурный разговор. Но помогает выбрать.

Главное: Power Platform НЕ хуже custom code. Это разные модели. Одна выигрывает скоростью, другая выигрывает control.

Что выбрать: Power Platform или custom development

Power Platform = сильный маршрут для:

• заявка на закупку (форма в Teams);
• согласование договора (workflow по почте);
• отпускные (форма в SharePoint);
• задачи на рассылку (Power Automate);
• связка 1С с CRM (trigger → sync).

Особенность: business owner часто понимает процесс лучше чем разработчик. Low-code позволяет быстро делать MVP (2-3 недели), показать value и итерировать.

Custom development = сильный маршрут для:

• customer-facing приложение (клиенты покупают/используют);
• сложная бизнес-логика (не forms и workflows, а расчёты, game logic, AI);
• нестандартный UX (это конкурентное преимущество);
• высокие нагрузки (1000+ одновременных пользователей);
• external API с security как часть продукта.

Главное: это не “правильно vs неправильно”. Это разные operating models.

• Power Platform выигрывает: скорость, доступность для бизнеса, интеграция с Microsoft.
• Custom code выигрывает: полный control, UX, performance, долгосрочный roadmap.

Вопросы для выбора:

1. Процесс понятен или спорный? (Ясен = Power Platform, спорный = сначала discovery.)
2. Где данные? (Microsoft 365 = легко Power Platform, 1С on-premise = сложнее.)
3. Кто пользователи? (Внутренние = Power Platform ok, внешние = custom code нужен.)
4. Это товар для продажи или внутренний tool? (Товар = custom, tool = Power Platform.)
5. Когда нужен? (2 недели = Power Platform, 6 месяцев = custom code с проверкой quality.)

Если ответов нет, не выбирайте маршрут. Сначала process discovery.

Короткая матрица решения low-code automation или custom code

Матрица не дает абсолютного ответа, но помогает не спорить абстрактно. Она переводит разговор из “Power Apps или разработчики” в “какой operating model соответствует рискам и целям”.

Если таблица показывает Power Platform, следующий шаг - не сразу “собрать app”. Нужно определить environment, access, DLP policy impact, data source, support owner и ALM path. Если таблица показывает custom development, Power Platform все равно может остаться рядом: internal admin panel, approval layer, notification flow, prototype, back-office workflow или integration support.

Когда Power Apps подходит лучше кастомной разработки

Power Apps хорошо когда:

• внутренняя форма (заявка, запрос, чек-лист);
• пользователи только сотрудники компании;
• процесс ясный и стабильный;
• данные в Microsoft 365, SharePoint или Dataverse;
• нужен MVP быстро (2-4 недели) для проверки;
• есть business owner (кто скажет “да, это правильно”);
• есть IT owner (кто настроит environment и access).

Примеры хороших Power Apps:

• Заявка на закупку.
• Форма командировки.
• Field inspection checklist (инспектор заполняет на планшете).
• Запрос доступа в IT.
• CRM extension в Teams.

Power Apps рискован когда:

• Пользователи внешние (клиенты покупают).
• UX должен быть крутым (это конкурентное преимущество).
• Процесс каждый месяц меняется (не стабилен).
• Нужна интеграция с legacy system глубокая (старые SAP, Oracle).
• App должен стать миссион-критичным без владельца и поддержки.

Казахстанский пример — хороший Power Apps case: Отдел закупки теряет согласования в почте. IT говорит: “не будем писать систему, соберём форму в Power Apps, данные в SharePoint, workflow отправляет уведомление финдиректору”. 2 недели, вот результат: заявка видна, статус ясен, согласование не теряется.

Плохой case: “Тот же процесс, но внешние vendors должны заполнять форму, нужна e-signature, интеграция с тремя ERP, аудит-логирование, высокие нагрузки”. → Custom development нужен.

Когда Power Automate подходит для согласований и workflow

Power Automate = когда люди делают одно и то же вручную, каждый день:

• отправить уведомление;
• создать задачу;
• синхронизировать данные;
• переместить файл;
• напомнить ответственному.

Примеры:

• Когда заявка создана → отправить email финдиректору.
• Каждый понедельник в 8 AM → отправить список задач в Teams.
• Когда статус = “Одобрено” → скопировать в Excel + отправить.

Слабый запрос: “нужно автоматизировать согласования”. Сильный запрос: “Когда заявка > 1M тенге, отправить финдиректору Амине. Она согласует за 24ч или эскалирует CTO. Уведомление в Teams + email. Если Амина не ответила за 48ч, напомнить.”

Перед стартом проверьте:

1. Trigger: что запускает flow? (новая заявка, время суток, кто нажал кнопку?)
2. Действия: что делать? (отправить email, создать task, скопировать в Excel?)
3. Условия: если сумма > X, то Y? (разные согласующие для разных сумм?)
4. Ошибки: что если email не ушёл, кто это узнает? (логи? кто смотрит?)
5. Владелец: кто может менять flow? (только IT или business тоже?)

Главная ошибка: automation работает, все довольны. Потом ломается, никто не знает почему (connector упал, лицензия истекла, IT уволился).

Когда custom development объективно лучше

Custom development нужен, когда Power Platform не может удобно закрыть задачу. Это не “Power Platform плохой”. Это граница платформы.

Выбирайте custom development если:

• Клиентский товар (люди платят и пользуются).
• UX это конкурентное преимущество (вес, дизайн, интерфейс).
• Логика сложная (не форма, не workflow, а расчёты, game logic, ML).
• Нагрузки высокие (1000+ одновременных пользователей).
• Integration сложный (много legacy систем, custom protocols).
• Нужна полная строгость: source control, tests, deploy pipeline, rollback.
• Roadmap на много лет (компания будет вкладываться в product).
• Security как часть продукта (не просто “заблокировать доступ”).

Примеры:

• Mobile app для клиентов. (Custom.)
• Внутренняя форма заявки. (Power Platform.)
• High-load trading platform. (Custom.)
• Approval в Teams. (Power Platform.)
• SaaS для продажи в интернете. (Custom.)
• Согласование договоров. (Power Platform + Power Automate.)

Гибридная архитектура часто лучше:

• Custom API обрабатывает сложную логику (расчёты, интеграции).
• Power Apps показывает результат пользователю.
• Power Automate отправляет уведомления.

Ошибки:

1. Выбрать custom “потому что серьезнее”, когда Power Platform подходит. → Перерасход.
2. Выбрать Power Platform “потому что быстрее”, потом два года бороться с техническим долгом. → Невозможно поддерживать.

Process discovery: как понять, что автоматизировать

Process discovery = не схемы, а реальный процесс. Нужен, чтобы не автоматизировать чужую путаницу.

Выбирайте один процесс для первого MVP:

• часто повторяется (не раз в квартал);
• раздражает сейчас (люди на это жалуются);
• есть владелец (не “никто не знает”);
• 3-7 ролей (не 20 рассыпанных);
• понятны данные (не “где-то в разных файлах”);
• short happy path (есть исключения, но основной путь простой);
• можно тестировать на небольшой группе (10 человек).

Собери для процесса:

Что	Почему
Название и владелец	Кто скажет “да, это правильно”.
Участники (кто инициирует, согласует, делает)	Чтобы не забыть никого.
Текущая боль (где теряется время, информация)	Что решает automation.
Текущие инструменты (Excel, email, Teams, 1С, CRM)	Откуда брать данные.
Поля данных (что нужно собрать, что меняется)	Какие fields в форме.
Решения (кто решает, какие условия)	Логика workflow.
Уведомления (кому, когда)	Power Automate actions.
Риски (данные чувствительные, финансы)	Какой уровень security нужен.
Владелец поддержки	Кто следит за ошибками после запуска.

После discovery результат:

• Power Platform (форма + workflow).
• Power Automate only (нет формы, только рутина).
• Custom development нужен.
• Dynamics 365 change request.
• Power BI first (дашборд для понимания).
• Неприятный ответ: “процесс не готов”. → Сначала cleanup, потом automation.

Dataverse: когда нужен управляемый слой бизнес-данных

Dataverse = управляемое хранилище данных. Нужен не для каждой формы.

Dataverse полезен когда:

• данные это core business asset (заказы, клиенты, сделки, финансы);
• нужны роли доступа (разные люди видят разное);
• данные используют несколько apps/flows (форма + отчет + Dynamics 365);
• нужны business rules (автоматические проверки);
• app может вырасти (начинаем с MVP, потом features).

Dataverse может быть лишним когда:

• одна простая форма (почта за отпуск);
• данные временные (temp list, proof of concept);
• документ уведомление (просто отправить).

Главный вопрос: где должна жить истина? Если запись влияет на клиента, деньги, compliance → обсуди Dataverse в начале. Если запись просто operational status → начни проще (SharePoint, Excel).

Примеры:

• Заявка на закупку → Dataverse (это в финансах, влияет на числа).
• Форма отпуска → Dataverse (это в HR, влияет на человека).
• Список задач → SharePoint or Excel (временная, не core business).
• Lead из website → Dataverse (это переходит в CRM, Dynamics 365).

Connectors и интеграции: стандартные, premium и custom сценарии

Connectors = кубики, которые соединяют системы.

Есть ready-made connectors:

• Teams (отправить сообщение).
• Excel (читать/писать таблицы).
• SharePoint (документы, списки).
• Outlook (письма, calendar).
• Dynamics 365 (CRM data).
• SQL Server (база данных).
• Dropbox, Google Drive.
• Slack, Telegram.

Нет готового connector для 1С, SAP, Oracle (legacy)? → Нужен custom connector. Это API, который IT пишет для Power Platform.

Каждый connector перед использованием:

1. Какие данные читает/пишет?
2. От чьего имени работает? (какой аккаунт, какие права?)
3. Что если connector упал? (email не ушёл, attachment потерялся?)
4. Есть ли логи? (кто видит, что случилось?)
5. Это дорогой connector? (Premium connectors → есть лицензии.)
6. Может ли DLP policy заблокировать его? (security rule не дает смешивать бизнес-данные с публичными сервисами.)

1С/ERP/Legacy systems:

• Иногда можно API → custom connector.
• Иногда нужен gateway (для on-premise систем).
• Иногда нужен middleware/integration layer (Azure Functions, custom code).
• Иногда Power Platform может только notification layer, остальное = custom code.

**Не обещайте “подключим всё через connector” без проверки API и architecture.

Governance, environments, роли, безопасность и владельцы

Governance = не бюрократия. Это рамки, чтобы не было “каждый отдел создал свою форму и никто не знает, где она”.

Minimum governance чеклист:

Что	Зачем
Separate environments (dev/test/prod)	Чтобы не ломать production новыми версиями.
Environment Admin назначен	Кто управляет permissions, security, backups.
Maker permissions явно даны	Не все в компании создают apps.
Owner register (кто что создал)	Кто за это отвечает, если сломалось.
Naming rules (MyApp_V1, не MyAppNew)	Кто-то понимает логику имён.
DLP policies	Запретить connector который миксует бизнес-данные с публичным (Google Drive).
Connector list (какие разрешены)	Не каждый может добавить новый connector.
Support owner	Кто принимает tickets “форма не работает”.
Retirement rules	Когда app старая, её надо выключить, а не оставить.

Частая проблема в Казахстане:

• Finance создал свою форму в своём environment.
• HR создал свою форму в своём environment.
• Procurement создал форму в default environment.
• IT не знает, где что.
• Никто не знает, кто поддерживает форму HR.
• Форма finance использует премиум connector, никто не считает лицензии.

Результат: хаос, дублирование, потерянные формы.

DLP политики: как снижать риск утечки данных через connectors

DLP (Data Loss Prevention) = guardrails против ошибок.

Пример проблемы: Maker создал форму в Power Apps, которая читает financial data (секретно), и отправляет уведомление через Telegram (публичный, не secure). → Данные утекли случайно.

DLP предотвращает это: “Business connectors” (Dynamics 365, Dataverse, SharePoint) отделены от “personal connectors” (Telegram, Google Drive, личный Dropbox). Политика говорит: “не миксуй данные из Business в Personal”.

Простая логика DLP:

1. Business connectors: Dynamics 365, SharePoint, Dataverse.
2. Personal connectors: Gmail, Telegram, Google Drive.
3. Правило: если используешь business data, можешь только в business connector.

Перед DLP:

• Проверить, какие apps/flows используют connectors.
• Если DLP разрешить только business connectors, что упадет?
• Предупредить makers: “С завтра политика меняется”.

DLP НЕ решает security полностью. Она только снижает риск конкретного типа ошибки. Нужны ещё: identity, access control, audit, backup, incident response.

ALM и поддержка: разработка, тестирование, deployment и CI/CD

ALM (Application Lifecycle Management) = как app рождается, меняется, поддерживается, умирает.

Простое ALM:

• Финдиректор говорит: “нужна форма”.
• IT: “вот форма в dev environment, протестируй”.
• Финдиректор: “хорошо, выкладывай в production”.
• IT: “вот в production, помощи если сломалось”.

Сложное ALM:

• Requirements: какая форма, какие поля, какие роли.
• Development: пишу в dev.
• Testing: тестирую в test (финдиректор, IT security).
• Deployment: выкладываю в production.
• Monitoring: смотрю логи, слежу за ошибками.
• Support: финдиректор пишет “не работает”, я смотрю.
• Changes: если нужна новая роль, проходим cycle заново.
• Retirement: через 2 года форма не нужна, выключаю.

Когда ALM важен:

• Форма влияет на деньги (закупка, финансы).
• Много пользователей.
• Данные Confidential.
• Нужны логи для audit.

Когда ALM может быть простым:

• Одна форма, 5 пользователей.
• Данные не чувствительные.
• Меняется редко.

Правило: если app становится production dependency, ALM нельзя оставлять на потом.

Перед разговором собери процесс, а не wish list.

Минимальный пакет:

1. Один процесс (не список из 10).
2. Как это работает сейчас? (скриншоты Excel, email, Teams, 1С).
3. Роли: кто инициирует, кто согласует, кто делает?
4. Системы: какие используются (Microsoft 365, 1С, CRM, ERP, website)?
5. Данные: какие поля нужны, где source of truth?
6. Владелец: кто ответственен за процесс?
7. Если ломается: что делать?
8. Сроки: когда нужно?

Хороший итог discovery:

• ✓ Решение выбрано (Power Platform? Custom? Hybrid?).
• ✓ MVP boundary ясен (что в первой версии, что потом).
• ✓ Owner назначен (кто следит после запуска).
• ✓ Risks выявлены (что может пойти не так).
• ✓ Timeline реалистичный.

После discovery:

• Если Power Platform → переходи на Power Platform услуги.
• Если custom development → нужна архитектура, разработчики, CI/CD.
• Если hybrid → Power Platform для процесса, custom code для logic.

Источники и границы

Useful public sources:

• Microsoft Power Apps training - Power Apps как no-code/low-code platform и examples of simple и complex business solutions.
• What is Power Automate? - automation of repetitive tasks, cloud flows, desktop flows и workflow types.
• Power Platform environments overview - environments, scope, Dataverse database, Environment Admin и Environment Maker roles.
• Data policies in Power Platform - guardrails, connectors, design-time/runtime impact и policy enforcement.
• What is Microsoft Dataverse? - tables, role-based security, Dynamics 365 data, business logic и integrations.
• Connectors overview - prebuilt/custom connectors и use across Power Apps, Power Automate, Copilot Studio и Logic Apps.
• Application lifecycle management with Microsoft Power Platform - ALM, governance, development, testing, deployment, source control и CI/CD.

Boundary: этот гайд - informational и decision-readiness oriented. Он не предоставляет final architecture, licensing quote, product availability confirmation, security audit, legal/compliance advice, fixed project estimate, ROI calculation или guarantee, что Power Platform или custom development - это right route для specific company. Перед production commitments IT, business owner, security/compliance, procurement и support owners должны review actual requirements, current Microsoft terms, data sources и operating risks.

Следующий шаг

Используйте этот гайд как нейтральную модель выбора: возьмите процесс, опишите роли, данные, интеграции, риски, владельца поддержки и жизненный цикл. Если после матрицы Power Platform выглядит подходящим маршрутом, переходите на страницу услуги и собирайте бриф MVP.