ผสานรวมแอปการเงินและการดําเนินงาน Dynamics 365 ด้วย Power Platform

สถาปัตยกรรมอ้างอิงนี้ใช้ Microsoft Power Platform เพื่อสนับสนุนกระบวนการวิศวกรต่อใบสั่งจากการกําหนดค่าและอ้างถึงการจัดลําดับ การวางแผนความจุคําแนะนํา และการวางลําดับการผลิต แอปแบบจําลองข้อมูลและ Microsoft Dataverse ประสานกระบวนการหลัก ในขณะที่แอปการเงินและการดําเนินงาน Microsoft Dynamics 365 ทําหน้าที่เป็นระบบ ERP (การวางแผนทรัพยากรองค์กร) ของระเบียน สถาปัตยกรรมอ้างอิงนี้ยังอาศัยบริการ Azure สําหรับการดําเนินการแบบอะซิงโครนัสที่เกินขีดจํากัดของแพลตฟอร์ม

แผนภาพสถาปัตยกรรม

ไดอะแกรมต่อไปนี้แสดงบริบทของระบบหลักและสถาปัตยกรรม

ผู้ใช้ทํางานผ่านเวิร์กโฟลว์โดยใช้แอปพลิเคชันที่ขับเคลื่อนด้วยแบบจําลองสาม Power Apps:

• แอปการประมาณ: พื้นที่ทํางานหลักของตัวประมาณ ตัวประมาณเริ่มต้นการประเมินโดยการนําเข้าการออกแบบวิศวกรรมจากไฟล์ XML หรือเลือกการออกแบบจากไลบรารี จากนั้น ตัวประมาณจะเพิ่มหรือลบส่วนประกอบเพื่อปรับแต่งการประมาณการ ปลั๊กอินเซิร์ฟเวอร์จะคํานวณน้ําหนัก ชั่วโมงแรงงาน ตัวขับเคลื่อนค่าใช้จ่าย และราคาใหม่อย่างต่อเนื่อง ตัวประมาณการจะเรียกใช้การสรุปเพื่อรวมการกําหนดราคามาตรฐานกับราคาสําหรับลูกค้า จากนั้นจะเสร็จสิ้นและล็อกแพคเกจ แอปนี้เป็นแกนหลักของการกําหนดค่า-price-quote ของโซลูชัน

• แอปการวางแผน: รองรับการวางแผนเตรียมคําแนะนํา นักวางแผนจะจัดขั้นตอนการออกแบบขั้นสุดท้ายตามไซต์และเวลา และกําหนดวันที่เริ่มต้นการผลิตที่แน่นอน จากนั้นพวกเขาจะตรวจสอบแดชบอร์ดความจุที่รวมข้อมูลพื้นฐานของปฏิทินทรัพยากร ERP และใบสั่งผลิตที่กําหนดไว้ด้วยปริมาณงานที่ได้จากการประเมินและตัวแทนการคาดการณ์ด้วยตนเอง แอปรองรับการมองเห็นความจุและการสื่อสารนําเวลา ซึ่งไม่ใช้อย่างเป็นทางการ — ใบสั่งผลิต, MRP (การวางแผนทรัพยากรวัสดุ) และการจัดกําหนดการยังคงอยู่ในแอปการเงินและการดําเนินงาน

• ลอกแบบแอปพลิเคชัน: เครื่องมือผลผลิตสําหรับการจําลองบันทึกการประมาณการที่ซับซ้อน—การประมาณ การออกแบบโครงสร้าง และลําดับชั้นของคอมโพเนนต์—โดยใช้ข้อกําหนดแบบลอกแบบที่นํากลับมาใช้ใหม่ได้และขับเคลื่อนด้วยเทมเพลต ตัวประมาณการใช้สําเนาของการประเมินโดยวิศวกรที่มีอยู่เป็นจุดเริ่มต้นสําหรับการประเมินใหม่ แอปพลิเคชันใช้ Azure Service Bus และ ฟังก์ชัน Azure เพื่อเรียกใช้งานลอกแบบที่ซับซ้อนแบบอะซิงโครนัสและบันทึกสถานะของงานแต่ละรายการผกผัน

เวิร์กโฟลว์

ขั้นตอนต่อไปนี้อธิบายกระบวนการแบบ end-to-end:

1. สร้างหรือระบุเรกคอร์ดทริกเกอร์เชิงพาณิชย์ (แหล่งโอกาสอาจแตกต่างกันไปตามการใช้งาน) และสร้างใบเสนอราคา ERP ในช่วงต้นของวงจรชีวิต ใบเสนอราคา ERP ทําหน้าที่เป็นจุดยึดเชิงพาณิชย์สําหรับกระบวนการประมาณการ

2. สร้างหรือเปิดเรกคอร์ดการประมาณค่าข้อมูลที่เชื่อมโยงกับใบเสนอราคา ERP และเริ่มต้นการออกแบบเริ่มต้น (การเลือกการนําเข้า XML หรือตามไลบรารี) จากนั้น ปรับปรุงการกําหนดค่าในแอปการประมาณค่า

3. ยืนยันการประมาณ การออกแบบ และรายละเอียดคอมโพเนนต์ใน Dataverse ปลั๊กอินฝั่งเซิร์ฟเวอร์ตรวจสอบกฎวิศวกรรมและคํานวณชั่วโมงแรงงาน น้ําหนัก ตัวขับเคลื่อนค่าใช้จ่าย และผลรวมซ้ําๆ เมื่อมีการเปลี่ยนแปลงการออกแบบ

4. เริ่มต้นการสรุปเพื่อเสร็จสิ้นแพคเกจสําหรับการตรวจทาน ชุดการจัดเรียงสรุปอินพุตและทริกเกอร์การคํานวณฝั่งเซิร์ฟเวอร์สําหรับการประเมินและการออกแบบทั้งหมด

5. เรียกใช้การประเมินราคาเฉพาะของลูกค้า (CSP) ระหว่างการสรุป ข้อตกลงทางการค้า ERP (ข้อตกลงราคาและส่วนลด) จะใช้เป็นข้อมูลป้อนเข้าการกําหนดราคาที่มีโครงสร้างตามความเหมาะสม โครงสร้าง CSP อื่น ๆ เช่น $ / lb การกําหนดราคาตามช่วงและการกําหนดราคาตารางคอมโพเนนต์ได้รับการรองรับเพื่อตอบสนองสถานการณ์ที่ขับเคลื่อนด้วยวิศวกรรมซึ่งไม่สามารถแสดงได้เพียงอย่างเดียวผ่านข้อตกลงทางการค้าโดยไม่ต้องกําหนดค่า ERP อย่างมีนัยสําคัญ

6. ดําเนินการให้เสร็จสมบูรณ์และล็อกแพคเกจ recap ผลลัพธ์เสียงอ้อมที่ล็อกไว้รักษาความสามารถในการตรวจสอบย้อนกลับของเกณฑ์การกําหนดราคาที่ใช้ในเวลาขององค์ประกอบการกําหนดราคา ข้อตกลงทางการค้ามีผลบังคับใช้วันที่ การเปลี่ยนแปลงข้อตกลงทางการค้าครั้งต่อมาโดยเจตนาไม่แก้ไขผลลัพธ์การสรุปสรุปย้อนหลัง หากจําเป็นต้องมีการทํานายใหม่ ให้ดําเนินการตามรอบการ requote อย่างเป็นทางการ (ตรวจสอบการกําหนดค่าและสรุปการดําเนินการอีกครั้ง)

7. ปิดประตูกระบวนการในการรีวิวให้เสร็จสิ้น เมื่อบทสรุปเสร็จสมบูรณ์และทําเครื่องหมายการตรวจสอบแล้ว ให้ทริกเกอร์การประมวลผลเชิงพาณิชย์ปลายทาง

8. ใช้มาร์จิ้นและค่าคอมมิชชันกับรายการที่ราคามาตรฐานก่อนการเขียนกลับ ERP ตามความจําเป็น ผู้ตรวจสอบเชิงพาณิชย์ดําเนินการในขั้นตอนนี้ การรับรู้อัตราส่วนกําไรทางการเงินเกิดขึ้นใน ERP หลังมอบรางวัลผ่าน Project Management และการจัดการบัญชีและการติดตามต้นทุนตาม WBS (โครงสร้างการแบ่งงาน)

9. ปรับเอาต์พุตสุดท้ายให้เป็นโครงสร้างใบเสนอราคาแบบพร้อมใช้งาน ERP และเพิ่มบรรทัดใบเสนอราคาไปยังใบเสนอราคา ERP ที่มีอยู่ใน Dynamics 365 แอปการเงินและการดําเนินงาน ERP ไม่ปรับบรรทัดใบเสนอราคาที่เสร็จสมบูรณ์ใหม่ ERP เป็นระบบที่เชื่อถือได้ของการบันทึกสําหรับราคาที่ยอมรับและการดําเนินการทางการเงินปลายทาง

10. ใช้แอปการวางแผนเพื่อขั้นตอนการออกแบบตามไซต์และเวลา กําหนดวันที่เริ่มต้นการผลิตแบบไม่แน่นอน และตรวจสอบแดชบอร์ดความจุ แดชบอร์ดความจุจะรวมใบสั่งผลิตที่กําหนดไว้ของ ERP และรันไทม์ด้วยปริมาณงานที่ได้รับมาจากการประเมินสําหรับงานที่ยังไม่ได้สร้างเป็นผลิตภัณฑ์ ERP และใบสั่งผลิต ข้อมูลพื้นฐานของความจุมาจากปฏิทินทรัพยากร ERP ใบสั่งผลิตและ MRP ยังคงอยู่เฉพาะใน ERP

11. ลบการคาดการณ์ออกเป็นการประเมิน ใบสั่งขาย และใบสั่งผลิตจะถูกสร้างขึ้น (เรกคอร์ดการคาดการณ์จะเป็นตัวแทนที่ป้อนด้วยตนเองที่ใช้ในการจองความจุสําหรับความต้องการที่คาดหวังไว้เมื่อยังไม่ทราบรายละเอียดการกําหนดค่า)

12. ใช้แอปพลิเคชัน ลอกแบบ เพื่อจําลองเรกคอร์ดการประเมินที่ซับซ้อน รวมถึงการประมาณ การออกแบบโครงสร้าง และลําดับชั้นของคอมโพเนนต์ ด้วยเทมเพลตแบบลอกแบบที่นํากลับมาใช้ใหม่ได้ การดําเนินการและการจัดการเริ่มต้นงานเหล่านี้ Azure Service Bus ส่งงานลอกแบบที่ใช้เวลานานไปยังฟังก์ชัน Azure สําหรับการประมวลผลแบบอะซิงโครนัส และฟังก์ชันจะเขียนสถานะงานไปยัง Dataverse

รายละเอียดของสถานการณ์จำลอง

ปริมาณงานนี้ช่วยให้องค์กรเปลี่ยนการกําหนดค่าที่ซับซ้อนและการประเมินเป็นธุรกรรม ERP ที่ทําซ้ําได้ในขณะที่สนับสนุนข้อกําหนดแบบไดนามิกเฉพาะของลูกค้าในแบบจําลองธุรกิจแบบวิศวกรต่อการสั่งซื้อ

สถาปัตยกรรมถูกออกแบบมาเพื่อแยกความรับผิดชอบตามระยะวงจรชีวิต:

• การกําหนดค่าและองค์ประกอบราคาทางวิศวกรรมเกิดขึ้นในส่วนผันข้อมูล (แอปการประมาณการ/การวางแผน ปลั๊กอิน การเรียงลําดับ)
• ผู้มีสิทธิ์ทางการเงินและการดําเนินการเกิดขึ้นใน ERP (วงจรชีวิตใบเสนอราคา รางวัล ใบสั่งขาย การติดตามต้นทุนโครงการ/WBS ใบสั่งผลิต MRP การจัดกําหนดการ และการลงรายการบัญชี)
• ผลลัพธ์การสรุปจะถูกล็อกในขั้นสุดท้ายเพื่อรักษาการตรวจสอบย้อนกลับและป้องกันการเปลี่ยนแปลงย้อนหลังเว้นแต่จะมีการดําเนินการ requote อย่างเป็นทางการ

ผู้ใช้หลักและความรับผิดชอบ

• วิศวกรรมและตัวประมาณ: สร้างและตรวจสอบการออกแบบ จัดการการกําหนดค่า และสร้างค่าชั่วโมงแรงงาน น้ําหนัก และการประเมินต้นทุน
• เชิงพาณิชย์และผู้อนุมัติ: ตรวจสอบแพคเกจ recap ใช้มาร์จิ้น/ค่าคอมมิชชันสําหรับรายการการกําหนดราคามาตรฐานและอนุมัติเอาต์พุตสําหรับการใช้งานของลูกค้า
• นักวางแผน: การออกแบบระยะตามไซต์และเวลากําหนดวันที่เริ่มต้นที่แน่นอนและจัดการความสามารถในการมองเห็น / โอกาสในการขายโดยใช้ข้อมูลพื้นฐานความจุ ERP รวมถึงการประมาณและคาดการณ์สัญญาณความต้องการ
• การดําเนินการและการดูแลระบบ: จัดการเทมเพลตการลอกแบบ ตรวจสอบการรวม และสนับสนุนผู้ใช้ข้ามสภาพแวดล้อม

สิทธิ์ใช้งานและขอบเขตของผลิตภัณฑ์

ผู้ใช้ส่วนใหญ่จําเป็นต้องมีสิทธิ์การใช้งานสําหรับ Dynamics 365 แอปการเงินและการดําเนินงาน เนื่องจากเวิร์กโฟลว์ใช้แอปเหล่านี้ตั้งแต่ต้นจนจบ ผู้ใช้ที่ทํางานกับบันทึกเชิงพาณิชย์ เช่น ใบเสนอราคา ใบเสนอราคา และผลิตภัณฑ์ต้องมี Dynamics 365 Sales องค์กรแนบใบอนุญาต แอปการเงินและการดําเนินงานจะยังคงเป็นระบบ ERP ของบันทึกสําหรับวงจรชีวิตของใบเสนอราคา รางวัล และการดําเนินการทางการเงินปลายทาง

ข้อกําหนดหลัก

• สนับสนุนเวิร์กโฟลว์การกําหนดค่าใบเสนอราคาที่จําเป็นต้องมีการคํานวณซ้ํา การออกแบบซ้ํา การตรวจสอบความถูกต้องของวิศวกรรม และการควบคุม gating ก่อนข้อผูกมัด ERP

• ใช้ข้อตกลงทางการค้า ERP ตามความเหมาะสมในขณะที่เปิดใช้งานการสร้าง CSP ที่ขับเคลื่อนด้วยวิศวกรรมซึ่งเกินการเป็นตัวแทนข้อตกลงทางการค้ามาตรฐานโดยไม่ต้องกําหนด ERP เองอย่างมีนัยสําคัญ

• รักษาความสามารถในการตรวจสอบย้อนกลับและความมั่นคงในเชิงพาณิชย์ผ่านการสรุปและการล็อค เปิดใช้งานการทํานายใหม่ผ่านวงจรการ requote อย่างเป็นทางการเท่านั้น

• รักษา ERP เป็นระบบที่เชื่อถือได้ของเรกคอร์ดสําหรับวงจรชีวิตใบเสนอราคา รางวัล การสร้างใบสั่งขาย การกํากับดูแลทางการเงินโครงการ/WBS ใบสั่งผลิต MRP การจัดกําหนดการ และการลงรายการบัญชี

• เปิดใช้งานการวางแผนความจุเตรียมการผลิตที่แนะนําโดยใช้ปริมาณงานที่ได้รับการประเมินและตัวแทนการคาดการณ์ด้วยตนเองที่สอดคล้องกับปฏิทินทรัพยากร ERP และรันไทม์ใบสั่งผลิตที่มีอยู่

• ขอบเขตการรวมนโยบายควบคุมในสามรูปแบบ— เอนทิตีเสมือน (อ่าน), dual-write (เขียน), และ OData API—ด้วยการยกเว้นอย่างชัดเจนของเอนทิตีการลงรายการบัญชีทางการเงินจากการเขียนแบบคู่

คุณลักษณะนอกขอบเขต

• การดําเนินการผลิตโดยละเอียดและการควบคุมพื้นของร้านค้า (จัดการใน ERP และระบบปลายทาง)
• Project Operations (โซลูชันใช้โมดูลการจัดการ Project และการบัญชีในแอปการเงินและการปฏิบัติการแทน)
• การกําหนดราคาที่ขับเคลื่อนโดย AI หรือการตัดสินใจโดยอัตโนมัติ (การตรวจสอบโดยมนุษย์ยังคงเป็นจุดควบคุม)

ส่วนประกอบ

คอมโพเนนต์ต่อไปนี้มีความสามารถของแอปพลิเคชัน การประมวลผลแบบอะซิงโครนัส การรวมข้อมูลระดับองค์กร และนโยบายการกํากับดูแลทางการเงินสําหรับสถาปัตยกรรมการอ้างอิงนี้

Power Platform

• แอปการประมาณการ (แบบจําลองข้อมูล): การกําหนดค่าที่แนะนํา การประมาณราคา องค์ประกอบการกําหนดราคา และการดําเนินการแสดงการสรุป

• แอปการวางแผน (แบบจําลองข้อมูล): สนับสนุนการวางแผนเตรียมการผลิตที่แนะนําเท่านั้น ซึ่งไม่ควบคุมกําหนดการผลิต แอปให้ข้อมูลฟิสซิ่งตามไซต์และเวลา วันที่เริ่มต้นที่แน่นอน และความจุและการมองเห็นระยะเวลาที่รอคอย ข้อมูลพื้นฐานของความจุมาจากปฏิทินทรัพยากร ERP ใบสั่งผลิตและ MRP ยังคงมีเฉพาะในแอปการเงินและการดําเนินงาน การคาดการณ์คือตัวแทนที่สํารองความจุสําหรับความต้องการที่ยังไม่ได้กําหนดค่า และจะถูกลบออกเป็นการประเมิน ใบสั่งขาย และใบสั่งผลิตที่สร้างขึ้น

• ลอกแบบแอปพลิเคชัน (แบบจําลองข้อมูล): โคลนเรกคอร์ดการประมาณการที่ซับซ้อนโดยใช้ข้อกําหนดการลอกแบบที่นํากลับมาใช้ใหม่ได้ข้อกําหนดการลอกแบบเทมเพลตสําหรับการประเมิน การออกแบบโครงสร้าง และลําดับชั้นของคอมโพเนนต์ ผู้ใช้สามารถคัดลอกการประเมินโดยวิศวกรที่มีอยู่เป็นจุดเริ่มต้นสําหรับการประเมินใหม่ งานลอกแบบที่ใช้เวลานานจะทํางานแบบอะซิงโครนัสบนบริการ Azure

• Dataverse: ที่เก็บข้อมูลหลักสําหรับการประเมิน การออกแบบ คอมโพเนนต์ ระเบียนการวางแผน ตัวแทนการคาดการณ์ และโคลนเทมเพลตและคําขอ นอกจากนี้ยังมีความปลอดภัย การตรวจสอบ และพื้นที่การดําเนินการฝั่งเซิร์ฟเวอร์

• ปลั๊กอินข้อมูล: การตรวจสอบความถูกต้อง การคํานวณ การสรุปการสรุปและการล็อค และตรรกะการทําให้เป็นมาตรฐานเพื่อเตรียมเอาต์พุตใบเสนอราคาแบบใช้ ERP

• Power Automate: การจัดเรียงสําหรับการสรุปชุดงาน การอนุมัติ และการแจ้งเตือน และรูปแบบการจัดส่งงานตามความเหมาะสม

บริการ Azure

• Azure Service Bus: คิวโคลนข้อความงานและแยกส่วนการประมวลผลที่รันนานจากเซสชันแบบโต้ตอบ

• Azure Function App: ประมวลผลงานลอกแบบ (และปริมาณงานแบบอะซิงโครนัสอื่น ๆ ที่ใช้งานได้) เกินขีดจํากัดเวลาของแพลตฟอร์ม เขียนสถานะกลับไปยัง Dataverse

• Azure Key Vault: จัดเก็บข้อมูลลับและรายละเอียดการเชื่อมต่อ เข้าถึงได้โดยใช้ข้อมูลประจําตัวการรวม

• ข้อมูลประจําตัวการรวม (บริการหลัก): รับรองความถูกต้องไปยัง Azure ทรัพยากรต่อไปนี้หลักสิทธิ์น้อยที่สุด

ERP และการรวมข้อมูล

• Dynamics 365 แอปการเงินและการดําเนินงาน: ระบบบันทึกสําหรับใบเสนอราคา ERP และใบเสนอราคาบรรทัด รางวัล ใบสั่งขาย การจัดการ Project และบัญชี การติดตามต้นทุน WBS ใบสั่งผลิต MRP และการจัดกําหนดการ และการลงรายการบัญชี การรวมใช้รูปแบบที่แตกต่างกันสามแบบ โดยเลือกต่อสถานการณ์เพื่อลดความเสี่ยง:

  • เอนทิตีเสมือน ให้การเข้าถึงแบบอ่านอย่างเดียวเพื่ออ้างอิงและข้อมูลหลักในแอปการเงินและการดําเนินงาน รวมถึงผลิตภัณฑ์ ตัวแปร และหน่วยวัดที่เผยแพร่ พวกเขาไม่คัดลอกข้อมูลไปยัง Dataverse
  • ตัวจัดการการเขียนแบบคู่เขียนกลับไปยัง ERP โดยส่วนใหญ่เป็นบรรทัดใบเสนอราคาขั้นสุดท้าย รวมถึงเอนทิตีอ้างอิงและธุรกิจที่จําเป็นสําหรับการจัดเรียงและการกํากับดูแล
  • OData API ดึงข้อมูลชั่วโมงแรงงานตามการดําเนินงาน เอนทิตีการลงรายการบัญชีทางการเงิน (บัญชีแยกประเภททั่วไป สมุดรายวันใบแจ้งหนี้ ธุรกรรมต้นทุน การลงรายการบัญชีการผลิต การกระจายการลงบัญชี และมิติทางการเงิน) จะถูกแยกออกโดยเจตนาจากการเขียนแบบคู่ หลีกเลี่ยงลักษณะการทํางานของ shadow-ERP

• โครงสร้างการกําหนดราคา ERP: ข้อตกลงทางการค้า (ข้อตกลงราคา/ส่วนลด) จะใช้เป็นข้อมูลป้อนเข้าการกําหนดราคาที่เชื่อถือได้ระหว่างการตรวจสอบเมื่อเหมาะสม ERP ไม่ได้ปรับบรรทัดใบเสนอราคาที่เสร็จสมบูรณ์แล้วที่เขียนจากเอาต์พุตการสรุปใหม่แบบไดนามิก

• การใช้งาน API การกําหนดราคา ERP: API การกําหนดราคา ERP (รวมถึงการสอบเทียบราคาหน่วยมาตราส่วน Commerce) จะไม่ถูกเรียกใช้ในระหว่างการประมาณการซ้ําหรือการสรุปซ้ํา องค์ประกอบการกําหนดราคาเกิดขึ้นใน ข้อมูลผกผันระหว่างการสรุปโดยใช้อินพุตที่ถูกควบคุม (รวมถึงข้อตกลงทางการค้า) และโครงสร้างที่ขับเคลื่อนโดยวิศวกรรม

ข้อควรพิจารณา

ข้อควรพิจารณาเหล่านี้ใช้เสาหลักของ Power Platform Well-Architected ซึ่งเป็นชุดหลักการชี้นําเพื่อช่วยปรับปรุงคุณภาพของปริมาณงาน เรียนรู้เพิ่มเติมเกี่ยวกับ Microsoft Power Platform Well-Architected

ปริมาณงานถูกออกแบบมาเพื่อให้การควบคุมขององค์กรสมดุล (ความปลอดภัย ALM และความสามารถในการตรวจสอบ) ด้วยความสามารถในการใช้งานสําหรับผู้ใช้ทางธุรกิจที่ดําเนินการประมาณการและกระบวนการวางแผนที่ซับซ้อน

ความน่าเชื่อถือ

• ใช้การประมวลผลแบบอะซิงโครนัส (Service Bus + Azure Function) สําหรับการดําเนินการที่อาจเกินขีดจํากัดเวลาแบบโต้ตอบ ติดตามสถานะของงานผกผันสําหรับความสามารถในการกู้คืนและการสนับสนุน
• ออกแบบการคํานวณฝั่งเซิร์ฟเวอร์และตัวจัดการงานเพื่อให้เป็นไปตามเหตุผลที่เป็นไปได้ เพื่อให้สามารถทําซ้ําและประมวลผลใหม่ได้อย่างปลอดภัย
• บันทึกสถานะความล้มเหลวอย่างชัดเจน (ความล้มเหลวในการตรวจสอบความถูกต้อง ข้อยกเว้นการประเมินราคา ข้อบกพร่องในการรวม) และแสดงด้วยคําแนะนําการแก้ไขที่สามารถดําเนินการได้
• ล็อกผลลัพธ์สรุปที่ขั้นสุดท้ายเพื่อรักษาการตรวจสอบย้อนกลับและป้องกันการเปลี่ยนแปลงหลังเสร็จสิ้นโดยไม่ได้ตั้งใจ

Security

• บังคับใช้การเข้าถึงตามบทบาทที่สอดคล้องกับ personas และใช้สิทธิ์น้อยที่สุดสําหรับการรวมทั้งหมด
• จัดเก็บความลับใน Key Vault และเข้าถึงข้อมูลลับเหล่านั้นผ่านข้อมูลประจําตัวการรวม หลีกเลี่ยงการฝังความลับในโฟลว์ แอป หรือตัวควบคุมแหล่งข้อมูล
• ใช้การอ้างอิงการเชื่อมต่อเฉพาะสภาพแวดล้อมและการกําหนดค่าเพื่อป้องกันการรั่วไหลของสภาพแวดล้อมข้าม
• ตรวจสอบการดําเนินการที่สําคัญ เช่น การเสร็จสิ้นการบันทึกและล็อค ตรวจสอบการเสร็จสมบูรณ์ การดําเนินการกําหนดราคา และการเขียนบรรทัดใบเสนอราคาแบบย้อนกลับ

ความเป็นเลิศในการดำเนินงาน

• ทําให้การปรับใช้เป็นอัตโนมัติโดยใช้ไปป์ไลน์ orchestrator เดียวและการแท็กสาขาที่สอดคล้องกันเพื่อติดตามและสร้างการปรับใช้ใหม่
• ใช้การตรวจสอบทั่วทั้ง Power Automate ทํางาน การดําเนินการปลั๊กอิน Dataverse และข้อมูลฟังก์ชัน/Service Bus Azure ให้ runbooks สําหรับรูปแบบความล้มเหลวทั่วไป
• ความเป็นเจ้าของเอกสารและกระบวนการสนับสนุนสําหรับแอป ปลั๊กอิน โฟลว์ ทรัพยากร Azure และการรวม ERP

ประสิทธิภาพการทำงาน

• ต้องการการคํานวณฝั่งเซิร์ฟเวอร์สําหรับการตรวจสอบความถูกต้องและการคํานวณ (ปลั๊กอิน) เพื่อลดการเดินทางไปกลับของลูกค้า
• การคํานวณสรุปชุดงานและการเตรียมสายปลายทางเพื่อควบคุมโหลดระหว่างการใช้งานสูงสุด
• ปรับการซิงโครไนซ์ให้ตรงกับความต้องการทางธุรกิจและหลีกเลี่ยงขอบเขตการเขียนคู่ที่ไม่จําเป็น

การปรับปรุงประสบการณ์ใช้งาน

• รองรับการสร้างการประมาณอย่างรวดเร็วผ่านการเลือกข้อมูลเริ่มต้นที่ใช้ XML และไลบรารีที่นํากลับมาใช้ใหม่ได้ อนุญาตให้มีการปรับแต่งซ้ํา
• ใช้ประตูที่ชัดเจน (สรุป / ล็อคตรวจสอบเสร็จสมบูรณ์) เพื่อให้รัฐมองเห็นได้และลดความคลุมเครือ
• มีการวางแผนที่มีการดําเนินงาน Phasing ที่คล่องตัวและแดชบอร์ดที่สะท้อนถึงข้อมูลพื้นฐานความจุ ERP รวมถึงสัญญาณความต้องการการประมาณ/การคาดการณ์

AI ที่รับผิดชอบ

ปริมาณงานนี้ไม่ได้ขึ้นอยู่กับเอาต์พุตที่ AI สร้างขึ้นสําหรับการกําหนดราคาการอนุมัติหรือการตัดสินใจ ผู้ใช้ทางธุรกิจยังคงต้องรับผิดชอบสําหรับขั้นตอนการตรวจทานและอนุมัติขั้นสุดท้าย

ผู้สนับสนุน

Microsoft ดูแลบทความนี้ ผู้เขียนต่อไปนี้ได้เขียนบทความนี้

ผู้เขียนหลัก:

• Esteban Salinas, หลัก

แหล่งข้อมูลที่เกี่ยวข้อง

• เอกสาร Microsoft Dataverse
• Power Apps เอกสารแอปแบบจําลอง
• เอกสารประกอบ Power Automate
• คู่มือแอปพลิเคชันการเงินและการดำเนินงาน
• ภาพรวมของการรวมแบบสองทิศทาง
• เอกสารประกอบ Azure Service Bus Messaging (คิว ลองใหม่ และการตรวจสอบ)
• เอกสารประกอบ ฟังก์ชัน Azure
• Azure Key Vault เอกสารประกอบ
• การบริหารวงจรชีวิตของแอปพลิเคชัน (ALM) ด้วย Microsoft Power Platform
• สร้างแนวทางปฏิบัติในการจัดการวงจรชีวิตแอปพลิเคชันที่มีประสิทธิภาพ