Microsoft tender / RFP / procurement
Чеклист для тендера Microsoft в Казахстане: лицензии M365, Azure, Dynamics 365, Copilot, выбор CSP/LSP, scope и критерии приёмки.
Tugelbay Konabayev, Marketing Specialist · 9 июня 2026 г.
Эти блоки отвечают на практические вопросы без скрытого текста и без неподтвержденных обещаний по срокам, стоимости или результату.
К Microsoft tender/RFP стоит приложить список продуктов, количество пользователей по ролям, текущий tenant state, дату продления, procurement deadline, требования к лицензиям и services, acceptance criteria, billing route assumptions, security requirements, вопросы к поставщику и контактных владельцев со стороны IT, закупки и финансов.
Microsoft 365 scope в RFP лучше описывать через роли пользователей, required apps, desktop/web needs, Exchange/Teams/SharePoint/OneDrive context, tenant readiness, security baseline, migration boundary, support expectations и renewal timeline. Не превращайте RFP в общий список SKU без рабочих сценариев.
Azure scope для RFP нужно описывать как estimate inputs: workload type, region assumptions, expected consumption, backup/DR needs, networking, identity, security, support plan and cost-governance expectations. Не фиксируйте миграционный дизайн как окончательный, если discovery еще не проведен.
License request отвечает на вопрос, какие подписки, пользователи, срок и коммерческий route нужны. Implementation scope отвечает на вопрос, кто настраивает tenant, миграции, security, integrations, reporting, support and acceptance. В одном RFP эти части нужно разделять, иначе оценка становится непроверяемой.
CSP route обычно связан с управляемыми cloud subscriptions, lifecycle, billing and support. LSP или enterprise route уместен для более крупной corporate licensing/procurement модели. Tender/RFP нужен, когда у компании есть формальная закупочная процедура, сроки подачи, требования к поставщику и документальные критерии оценки.
В Microsoft RFP нельзя обещать гарантированный выигрыш тендера, влияние на закупку, специальные цены, Microsoft status, certification, legal compliance, cybersecurity protection или product availability без проверяемого источника. Безопаснее фиксировать проверяемые deliverables: review, estimate, configuration, support boundary and acceptance criteria.
Задайте вопросы о коммерческом route, MCA/Product Terms assumptions, tenant ownership, billing model, support boundary, renewal/change process, license change windows, implementation responsibility, data/security caveats, Azure estimate inputs, integration assumptions and what is explicitly excluded from the proposal.
Для первичного разбора отправьте страну и юридическое лицо, products, users by role, current subscriptions, tenant/admin context, deadline, procurement format, draft ТЗ/RFP, expected services, integrations, security requirements, evaluation criteria and questions already received from procurement, IT or finance.
Microsoft tender/RFP в Казахстане — это документальный пакет, не список “нужны лицензии, пришлите цену”. Хороший RFP разделяет:
Без разделения разные поставщики считают по-разному, закупка получит несравнимые предложения, IT и финансы спорят после дедлайна.
Microsoft-закупка требует четырёх слоёв:
Гайд помогает собрать RFP-пакет. Он не гарантирует выигрыш тендера, цену, статус Microsoft, результат или юридическое соответствие. Для public procurement, regulated sector или внутренней политики тендеров нужна проверка legal/procurement owner.
Для сайта Promise Group Kazakhstan эта страница работает как companion к Tender/RFP route. Money page отвечает за коммерческий маршрут и контакт. Этот guide отвечает за подготовку документов: какие вводные собрать, какие questions задать, где разделить license request and implementation scope, какие boundaries не обещать и что отправить для первичного разбора.
Не каждый запрос — тендер. Иногда достаточно licensing review, CSP route, renewal, discovery или quick proposal. RFP нужен, когда закупка требует formal process: deadline, requirements, evaluation matrix, documents, budget owner, specs, legal review и сравнимые proposals.
Признак RFP: если procurement спрашивает “какие документы”, “как сравнить”, “что в ТЗ”, “как разделить scope”, “какие критерии приемки” или “кто будет support” — это не price request. Это RFP package.
RFP должен помочь заказчику принять информированное решение, не переписывать Product Terms или MCA. RFP определяет требования заказчика и формат ответа поставщика, не условия Microsoft.
RFP становится особенно полезным в таких сценариях:
RFP не нужен как бюрократия ради бюрократии. Если scope слишком сырой, лучше провести discovery и только потом выпускать tender package. Иначе рынок будет считать “примерно”, а procurement будет сравнивать assumptions, а не предложения.
Базовый пакет должен быть понятен procurement, IT, finance и поставщикам. Его цель - уменьшить число уточняющих писем до начала commercial response.
Минимальный package:
Короткий и понятный пакет лучше, чем 100-страничное ТЗ с противоречиями. Каждая часть: один раздел, один owner, одно решение.
Главная ошибка — смешать лицензии и внедрение в одну строку. “Поставка Microsoft 365 и внедрение” звучит просто. Для поставщика это может означать: quote subscriptions, миграцию почты, настройку security, перемещение файлов, обучение, настройку Teams, devices, Power BI, Power Automate, support и документацию.
License request answers:
Implementation scope answers:
Разделите на workstreams или lots. Примеры:
| Workstream | Что входит | Что не считать автоматически |
|---|---|---|
| Licensing | Products, users, term, renewal date, commercial route, MCA/Product Terms assumptions, billing/support boundary. | Migration, configuration, training, integration or managed service. |
| Implementation | Tenant setup, migration, security baseline, app configuration, data/reporting/integration tasks, acceptance evidence. | Unlimited scope, legal compliance guarantee, fixed price without discovery. |
| Support | Support hours, channels, escalation, response windows, change request process, renewal/change handling. | 24/7 coverage, security operations, user training, custom development. |
Это разделение защищает обе стороны. Заказчик получает сравнимые предложения. Поставщик может ответить ответственно, не оценивая неизвестный scope.
RFP для Microsoft 365 не начинается со списка SKU. Начинается с пользователей, ролей и сценариев. Office, field, finance, executives, admins, guests — разные группы. Одни нужны desktop apps, другие — browser/mobile. Одни требуют безопасность. Не каждый должен платить за дорогой план, если не использует.
Опишите Microsoft 365 scope как procurement matrix:
В RFP Microsoft 365 scope — это procurement inputs: что поставщику нужно для quote, assumptions и выявления gaps.
Полезный pattern:
Заказчик просит поставщика предложить licensing route и микс Microsoft 365 subscriptions на основе ролей пользователей, требуемых приложений, состояния tenant и ограничений закупки. Поставщик указывает assumptions, exclusions, нужные input заказчика и включены ли implementation services.
Это избегает двух крайностей: жёсткого плана или гадания поставщика.
Azure RFP опасен без workload detail. Azure Pricing Calculator превращает expected usage в estimate, используя product, configuration, region и consumption. Примеры в документации — не actual prices.
Для RFP нужны estimate inputs, не желаемые числа. Попросите structured estimate и assumptions:
Если inputs нет, RFP должен сказать “discovery требуется перед fixed estimate”. Это не слабость, это ответственная procurement. Поставщик с confident price без workload data оценивает assumptions, не scope.
RFP гайд объясняет только procurement inputs для tender package.
Dynamics 365, Power BI и Power Platform RFPs fail без business process. “Need CRM” — не scope. “Need dashboard” — не BI scope. “Need automation” — не Power Platform scope.
Для Dynamics 365 опишите:
Для Power BI/Fabric опишите:
Для Power Platform опишите:
RFP не становится implementation manual. Он должен дать достаточно информации для qualified request и выявления нужного discovery.
Внутренние маршруты:
Acceptance criteria — measurable, не marketing promises. Для licensing: quote с products, users, term, assumptions и route. Для implementation: конфигурация, миграция, политики, отчёты, интеграция, обучение. Для support: канал, response window, escalation, документация.
Примеры безопасных criteria:
Что не обещать:
Boundaries не пессимизм. Это делает proposals сравнимыми и defensible.
Перед отправкой RFP задайте поставщикам или internal stakeholders эти вопросы. Они разработаны для выявления missing assumptions рано.
Commercial route:
Licensing:
Services:
Risk и dependencies:
Для procurement самый полезный ответ — не самый дешевый. Это ответ, где assumptions, exclusions и next steps ясны для сравнения.
RFP должен пройти несколько audiences. Procurement — clean document и сравнение. IT — sane scope. Finance — budget assumptions. Leadership — business rationale. Legal/compliance — boundaries и risk language.
Подготовьте один internal approval pack перед отправкой external RFP:
Pack помогает избежать failure: procurement отправляет document, который IT не узнает, или IT отправляет wish list, который procurement не может оценить.
Для state/public procurement или regulated procurement используйте official legal/procurement sources и qualified counsel. Adilet публикует Law of the Republic of Kazakhstan “On Public Procurement” и related official text, но этот гайд его не интерпретирует. Он только говорит: если ваш процесс подпадает под такие rules, не полагайтесь на marketing guide как legal basis.
Для рецензии RFP от Promise Group полезный packet краток, но specific:
Не ждите perfect document. Messy draft полезен с real constraints. Не useful — one-line request без users, products, dates или scope.
Suggested first email format:
Готовим Microsoft procurement/RFP в Казахстане. Products: [список]. Users: [по ролям]. Deadline: [дата]. Current: [tenant/subscriptions]. Scope: [лицензии / лицензии+услуги / discovery]. Attached: RFP draft, user matrix, questions. Рецензируйте route, assumptions, inputs и response structure.
Это создаёт realistic starting point для выбора: CSP, enterprise route, tender/RFP, licensing review, discovery или security readiness review.
Гайд основан на official Microsoft и Kazakhstan public sources плюс Promise Group service context. Написан для procurement preparation, не legal advice.
Useful public sources:
Гайд не гарантирует результат тендера, цены, статусы Microsoft, квалификацию поставщика, юридическое соответствие, защиту, резидентность, сроки или бюджет. Все commercial, legal, technical и compliance допущения нужно сверять с договорами, условиями Microsoft, правилами и мнением консультантов.
Нет. Это procurement preparation checklist, а не готовое ТЗ и не юридический документ. Его задача - собрать вводные, разделить licensing, implementation and support scope, подготовить вопросы и снизить риск неполного Microsoft RFP.
Если SKU уже проверены, их можно указать. Если план не подтвержден, лучше описать роли, сценарии и требования, а SKU вынести как subject to licensing review. Так поставщик может предложить корректный route без угадывания.
Сначала отделите minimum viable package: products, users, deadline, tenant state, procurement constraints, service boundary and vendor questions. Срочность не отменяет проверку MCA, licensing terms, scope, acceptance criteria and exclusions.
Можно, если документ явно разделяет lots or workstreams: licensing, Azure estimate, implementation, integrations, support and acceptance. Если всё описано одной строкой, поставщики будут считать разные scope, а сравнение предложений станет слабым.
Нет. RFP помогает структурировать запрос и сравнить предложения, но не гарантирует цену, результат, условия Microsoft or procurement outcome. Цена зависит от продуктов, route, term, tenant, currency/tax assumptions, scope and current commercial terms.
Да, если покупка идет через route, где требуется acceptance of applicable Microsoft Customer Agreement. Microsoft CSP documents state that before an order can be placed on a customer's behalf, the customer must accept/sign the applicable region-specific agreement.
Нет. Этот guide не является юридической консультацией и не интерпретирует законодательство РК о закупках. Если закупка относится к public procurement, regulated sector or internal tender rules, legal/procurement owner заказчика должен проверить применимые требования.
Discovery лучше, когда нет понятного scope, неизвестны users/roles, tenant state, workloads, integrations, acceptance criteria or budget assumptions. После discovery можно сформировать более точный RFP, а не просить поставщиков оценивать неизвестный контур.
Используйте этот checklist как procurement intake: соберите продукты, пользователей, сроки, tenant state, service boundary, acceptance criteria and vendor questions. После этого проще понять, нужен ли CSP route, LSP/enterprise route, tender/RFP package или technical discovery.
