Нотатка
Доступ до цієї сторінки потребує авторизації. Можна спробувати ввійти або змінити каталоги.
Доступ до цієї сторінки потребує авторизації. Можна спробувати змінити каталоги.
Ви можете доповнити документацію Microsoft про Dynamics 365 двома способами. Якщо стаття містить неправильну або незрозумілу інформацію, або ви знаєте обхідне рішення поширеної проблеми, скористайтеся посиланням для надсилання відгуків у відповідній статті.
Більшість із наших статей також можна редагувати напряму й надсилати на перевірку.
Надіслати відгук
Кожна стаття на веб-сайті learn.microsoft.com містить пропозицію поділитися відгуком. Ви можете натиснути кнопку Відгук під заголовком статті у верхньому правому куті або вибрати один із варіантів у нижній частині статті в розділі Відгук. Оцініть статтю, виберіть причину свого відгуку й за бажанням додайте коментар. Відгуки надходять до автора статті та робочої групи, яка відповідає за документацію.
Якщо статтю не можна або незручно редагувати напряму, скористайтеся механізмом надсилання відгуків, щоб поділитися думками щодо статті або продукту.
Зовнішні доповнення до документації Microsoft
Вихідні файли основного вмісту можна знайти в загальнодоступних репозиторіях GitHub. Всі з них можна переглядати, а більшість і редагувати. Надсилайте свої пропозиції та виправлення у формі доповнень або повідомляйте про проблеми й ставте запитання через відповідні інструменти GitHub. Ми приймаємо відгуки та доповнення до вихідного вмісту лише англійською мовою.
Більшість статей містить піктограму олівця з підписом Редагувати цей документ. Виберіть її, щоб відкрити статтю в GitHub і почати редагування. Почніть як учасник із посібником для учасників Microsoft Learn.
Якщо ви хочете написати концептуально нову статтю, використовуйте шаблони на сторінці https://github.com/MicrosoftDocs/dynamics365-docs-templates.
Рекомендації щодо Dynamics 365
Контент керівництва Dynamics 365 використовує ті ж процеси, що й більшість документації на Microsoft Learn. У цьому розділі ви дізнаєтеся про інструменти й процеси, якими можна доповнити інструкції в посібнику з впровадження.
У термін рекомендації ми включаємо посібник з упровадження Dynamics 365, опис бізнес-процесів, нові методи, передовий досвід і еталонні архітектури. У квітні 2023 року ми опублікували перші рекомендації щодо впровадження й оновлювали їх щодва тижні. Перегляньте їх у Центрі впровадження і повідомте нам, що сподобалося, а чого не вистачає.
Частину рекомендацій створюють наші працівники. Ми запрошуємо галузевих експертів зі спільноти допомагати нам із документуванням передового досвіду. Читайте далі, якщо у вас є найкраща практика або інші поради, які, на вашу думку, мають бути частиною Microsoft Learn.
Для чого писати рекомендації?
Ми вважаємо, що нові рекомендації допомагають швидше реалізовувати проекти з упровадження Dynamics 365. Завдяки ним наші партнери та клієнти можуть дізнатися більше про впровадження, набути нових навичок або підготувати персонал до роботи. Спеціалісти, які займаються розробкою програмного забезпечення, зможуть використовувати наші рекомендації як платформу для просування своєї інтелектуальної власності чи галузевого досвіду.
Але ми в Microsoft не єдині експерти щодо впровадження рішень із Dynamics 365. До складу нашої спільноти входить багато людей, які спеціалізуються на різних аспектах цього процесу. Ви маєте шаблон, передовий досвід, конфігурацію або архітектуру інтеграції, яка добре зарекомендувала себе в кількох упровадженнях? Розгляньте можливість поділитися цим тут, на Microsoft Learn, щоб зробити всю спільноту ще продуктивнішою та ефективнішою у своїх проєктах впровадження.
Ми сподіваємося мати змогу пропонувати винагороди або інші подяки за внески. Поки що ми визнаємо авторів статей двома різними способами. Докладні відомості див. в розділі Визнання співавторів.
Як доповнити вміст рекомендацій?
Вихідні файли Dynamics 365 керівництва Microsoft можна знайти у a public GitHub repo. Ви також можете редагувати статті на сайті learn.microsoft.com/dynamics365/guidance , як описано в посібнику для учасників Microsoft Learn.
Рекомендуємо подавати виправлення так само, як і в інші розділи Microsoft Learn. Однак щоб надіслати новий вміст, після цього вам потрібно передати файли нових рекомендацій у форматі Markdown до іншого репозиторію – Dynamics 365 Patterns and Practices. Таким чином ми гарантуватимемо, що еталонну архітектуру або шаблон перевірять експерти у відповідній галузі. Для цього існують різні шаблони. Якщо ви хочете доповнити вміст щодо бізнес-процесів, можна скористатися іншим способом.
Шаблони
Шаблони Microsoft зберігаються у двох місцях, залежно від типу шаблону:
Шаблони Markdown знаходяться в репозиторії https://github.com/MicrosoftDocs/dynamics365-docs-templates.
Папка docs-templates містить шаблони для концептуальних і навігаційних статей.
Папка /guidance-templates/ містить шаблони для архітектур, ідей рішень і моделей. Це ті самі шаблони, що використовуються всюди в Microsoft, але адаптовані спеціально для Dynamics 365.
Шаблони Word і PowerPoint зберігаються в репозиторії Dynamics 365 Patterns and Practices.
Шаблони Word для статей про бізнес-процеси можна знайти в папці /templates/business-processes/. Ми запрошуємо усіх галузевих експертів допомагати нам у їх написанні. Папка також містить файл Excel зі списком бізнес-процесів, які ми виявили. З часом цей список доповнюватиметься.
Папка /graphics/ містить файли PowerPoint для кожного комплексного сценарію, куди можна додавати власні діаграми.
Ми додаватимемо більше шаблонів і вказівок. Підпишиться на репозиторії або збережіть їх за допомогою значка у вигляді зірочки, щоб отримувати сповіщення про зміни.
Ділитися відгуками можна на вкладці https://github.com/microsoft/dynamics365patternspractices/discussions у репозиторії Dynamics 365 Patterns and Practices.
Якщо у вас ще немає GitHub-акаунта, почніть з гайдом для учасників Microsoft Learn.
Порада
Перегляньте вихідні файли в репозиторії https://github.com/MicrosoftDocs/dynamics365-guidance. Ознайомтеся з тим, як ми структуруємо різні типи статей, і застосуйте цю структуру до вашого вмісту. Якщо ви дотримуватиметесь цих інструкцій, перевірка пройде швидше.
Архітектури
Ми вітаємо внесок до архітектурних рекомендацій, зокрема ідей рішень і шаблонів проектування. Якщо ви маєте передовий досвід або довідкові матеріали щодо впровадження, надсилайте свої пропозиції команді Azure або Dynamics 365.
Щоб доповнити вміст нових статей архітектурних рекомендацій щодо Dynamics 365, виконайте такі основні кроки:
- Завантажте відповідні шаблони у форматі Markdown із папки guidance-templates у репозиторій GitHub dynamics365-docs-templates.
- Додайте свій вміст.
- Після цього ви можете надіслати свою статтю як файл формату Markdown у запиті на внесення змін до репозиторію dynamics365patternspractices. Папка
/submit-architecture/готова до прийому ваших доповнень.
Спеціалісти Microsoft опрацюють статтю та опублікують її як частину рекомендацій щодо Dynamics 365.
Щоб ознайомитися з рекомендаціями в Microsoft, перегляньте Azure Architecture Center. Посібник для співавторів див. у розділі Доповнення до Azure Architecture Center.
Репозиторій GitHub dynamics365-docs-templates містить наведені нижче шаблони у форматі Markdown для архітектурних рекомендацій, розміщені в папці guidance-templates.
Узагальнений шаблон архітектури. Узагальнений шаблон архітектури виконує роль базової архітектури із загальним рішенням, яке застосовується до багатьох сценаріїв. Наприклад, ідеї рішень можуть ґрунтуватися на архітектурній статті, щоб продемонструвати можливості для розвитку конкретного галузевого або партнерського рішення й бути пов’язаними з архітектурою кожної ідеї рішення. Шаблон створено на основі шаблону Центру архітектури Azure. Використовуйте його для різних типів архітектур, включно з довідковими.
Ідея рішення. Ідеї рішень – це «малі» архітектури впроваджень Dynamics 365. Вони надають короткі огляди рішень зі службами Dynamics 365 і Azure. Кожна ідея рішення має такі елементи:
- схема архітектури;
- потік даних;
- компоненти (список використаних служб);
- інформація про співавторів;
- посилання на наступні кроки та пов’язані ресурси (посилання на відповідні посібники та архітектури).
Зразок рішення. Зразки рішень – це приклади робочих навантажень із «середніми» архітектурами. Вони допоможуть читачам зрозуміти процес проектування рішень для вирішення конкретних проблем із впровадженням Dynamics 365. Зразки рішень практичні рекомендації щодо архітектури, засновані на реальних прикладах клієнтів. Мета полягає в тому, щоб скоротити криву навчання клієнта, розповівши йому історію іншого клієнта, який був у цій ситуації раніше. Зразки включають розділи з шаблону Ідея рішення і додають такі розділи:
- Альтернативи. Інші служби, які можна підключити до архітектури
- Міркування, рекомендації, які відповідають нашій структурі Success by Design і, за бажанням, включають розгортання
Шаблон проектування. Шаблони проектування Dynamics 365 вирішують конкретні проблеми з упровадженням і ґрунтуються на певному сценарії або передовому досвіді. Використовуйте цей шаблон, щоб записати шаблон бізнес-процесу. Або скористайтеся шаблоном Word із папки dynamics365patternspractices/templates/business-processes.
Доповнення вмісту про бізнес-процеси
Термін бізнес-процес охоплює широкий спектр структурованих, часто послідовних дій або завдань, спрямованих на досягнення заздалегідь визначеної організаційної мети. Цей термін також може означати сукупний ефект від усіх кроків на шляху до бізнес-цілі. Бізнес-процеси адаптуються до рішень, які включають Dynamics 365. Ми вважаємо, що цей новий тип вмісту структурує наробки й допомагає клієнтам і партнерам краще підготуватися до впровадження Dynamics 365. Кожен бізнес-процес включає діаграму стандартного потоку бізнес-процесу. У розділах документа описуються кроки конфігурації та інформаційні об’єкти, які використовуються на кожному з цих кроків. Кожен крок посилається на відповідну сторінку в документації до продукту. Усі документи містять посилання на наступні кроки та відповідні ресурси, які допоможуть читачу в навчанні.
Ми структурували бізнес-процеси в каталог. Каталог бізнес-процесів — це книга Excel, яку співробітники Microsoft використовують для впорядкування завдань, пов’язаних із документацією бізнес-процесів, і визначення їхніх пріоритетів. Ми використали формат Excel, оскільки він дає змогу легко сортувати та фільтрувати записи. Ми також вважаємо, що завдяки книгам Excel наші партнери зможуть упорядковувати свої шляхи до запровадження, проекти з впровадження та власні бізнес-процеси.
Завантажте найновішу версію каталогу за посиланням https://aka.ms/BusinessProcessCatalog.
Примітка
Якщо ви хочете доповнити вміст, який стосується бізнес-процесів, спочатку зареєструйте свою роботу, щоб знизити ризик того, що інший користувач почне працювати над тим же бізнес-процесом. Щоб зареєструвати свою роботу, надішліть запит до системи інцидентів GitHub за адресою https://github.com/microsoft/dynamics365patternspractices/issues.
Вміст каталогу
Каталог визначає шість рівнів контенту:
Комплексні процеси
Комплексний процес представляє повний потік дій від початкового тригера до кінцевого результату. Вона охоплює всі проміжні кроки та підпроцеси, необхідні для досягнення бізнес-мети. Ми визначили 15 комплексних сценаріїв. Сценарії описано з точки зору бізнесу, а не програмних технологій.
Для кожного комплексного процесу наведена вступна стаття, у якій описується наше бачення. Ми наводимо перелік ключових зацікавлених сторін і пояснюємо, як Dynamics 365 сприяє комплексному процесу. Ми також надаємо огляд із діаграмою потоку бізнес-процесу, який ілюструє взаємодію комплексного процесу з іншими такими процесами. У вступі перелічено необхідні засоби для впровадження рішення, щоб підтримати комплексний процес.
Області бізнес-процесів
Кожен комплексний сценарій охоплює дві або більше областей бізнес-процесів. Цей рівень представляє значну групу пов'язаних активностей, які сприяють досягненню загальної мети, і забезпечує логічний спосіб групування бізнес-процесів. Здебільшого області бізнес-процесів розділені за основними функціональними обов'язками посад або відділами в організації. Наразі каталог визначає понад 100 напрямків бізнес-процесів.
Бізнес-процеси
Термін бізнес-процес охоплює широкий спектр структурованих, часто послідовних дій або завдань, спрямованих на досягнення заздалегідь визначеної організаційної мети. Цей термін також може означати сукупний ефект від усіх кроків на шляху до бізнес-цілі. Кожен бізнес-процес описує функцію або процес, які підтримує Dynamics 365. На даний момент ми ідентифікували понад 800 бізнес-процесів. Певні з них стосуються однієї програми Dynamics 365. Документація до цієї програми вже може містити описи цих процесів. Зібравши всі бізнес-процеси в цьому посібнику, ми сподіваємося створити єдину точку входу з посиланнями на відповідний вміст для конкретних продуктів.
Сценарії
У Dynamics 365 сценарії — це шаблони повторюваних конфігурацій, які підтримують конкретний бізнес-процес. Вони охоплюють найпоширеніші варіанти використання, сценарії та галузі. Як правило, упровадити Dynamics 365 для задоволення бізнес-потреб можна різними способами. Наша мета щодо шаблонів – забезпечити основу для вашого впровадження. Ми виявили понад 3000 сценаріїв і закономірностей, і очікуємо, що ця кількість з часом зростатиме.
Системні процеси
Системний процес — це частина бізнес-процесу, яка використовує певну форму, сторінку або елемент інтерфейсу в Dynamics 365.
Тестові приклади
Тестовий випадок — це детальний набір умов і кроків, які використовуються для визначення правильної роботи програмного забезпечення або системи. Це невід'ємна частина процесу тестування програмного забезпечення, спрямована на те, щоб гарантувати, що програмне забезпечення відповідає вимогам і працює належним чином. Тестові випадки використовуються для виявлення дефектів, забезпечення якості та перевірки того, що програмне забезпечення працює належним чином за різних умов.
Для кожного типу контенту є шаблони Word. Інструкції оформлені червоним кольором і оточені квадратними дужками, як у наступному прикладі:[Text in red] Видаліть ці інструкції при завершенні документа. Текст, виділений жовтим, має бути замінений або скоригований вами вами. Не змінюйте текст, який не виділений жовтим і не відформатований червоним. Ці стандартні фрази допомагають користувачам розпізнавати шаблон, щоб їм було легше сканувати та знаходити потрібний контент.
Ознайомтеся з каталогом бізнес-процесів на сторінці Про посібник із бізнес-процесів. За бажанням ознайомтеся з TechTalks , де ми говоримо про те, як можна використовувати каталог бізнес-процесів і долучатися до бібліотеки контенту.
Надсилання доповнень
Команда Microsoft наполегливо працює над тим, щоб перетворити внутрішні примітки, багаторічний досвід і різноманітні документи на рекомендації щодо бізнес-процесів. Ми високо цінуємо внесок спільноти.
Для надсилання доповнень доступні різні шаблони, що залежать від типу статті. Співавтори мають вибрати потрібний шаблон для типу статті, вміст якої хочуть доповнити. Шаблони доступні у форматі файлів Word. З їхніх імен зрозуміло, для статей якого типу вони призначені.
Визнання співавторів
Платформа Microsoft Learn показує як внутрішніх, так і зовнішніх учасників у верхній частині кожної статті, якщо вони подавали свій внесок через GitHub. Оскільки деякі люди вносять доповнення іншими способами, ми можемо додавати розділ Співавтори в кінці статті.
У додатковому розділі Співавтори перелічено основних співавторів із зазначенням імені та посилання на профіль LinkedIn або інший профіль, якщо вони його надали. Наведений нижче знімок екрану ілюструє анонімізовану версію розділу Співавтори в статті Azure Architecture Center.
Ось як це виглядає у Markdown.
## Contributors
*This article is maintained by Microsoft. It was originally written by the following contributors.*
Principal author:
* [Author's Name](https://www.linkedin.com/in/author-account/) | Author's job title or similar
Other contributors:
* [Contributor's Name](https://www.linkedin.com/in/contributor-account/) | Contributor's job title or similar
* [Contributor's Name](https://www.linkedin.com/in/contributor-account/) | Contributor's job title or similar
Указувати співавторів у такий спосіб не обов’язково. Ми рекомендуємо використовувати розділ Співавтори, якщо зовнішні співавтори надсилають новий вміст, зокрема еталонні архітектури та шаблони проектування, не через GitHub.