การวางแผนการใช้งาน Power BI: การวางแผนโซลูชัน BI

หมายเหตุ

บทความนี้เป็นส่วนหนึ่งของ ชุดการวางแผน การใช้งาน Power BI ของบทความ ชุดข้อมูลนี้เน้นไปที่ประสบการณ์การใช้งาน Power BI ภายใน Microsoft Fabric เป็นหลัก สําหรับบทนําสู่ชุดข้อมูล โปรดดู ที่ การวางแผนการใช้งาน Power BI

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

• BI และกรรมการวิเคราะห์ หรือผู้จัดการ: ผู้มีอํานาจตัดสินใจที่รับผิดชอบในการกํากับดูแลโปรแกรม BI และโซลูชัน BI ที่มีกลยุทธ์สําคัญ
• ทีม Center of Excellence (COE), IT และ BI teams: ทีมที่ออกแบบและปรับใช้โซลูชัน BI ขององค์กรสําหรับองค์กรของพวกเขา
• ผู้เชี่ยวชาญเรื่อง (SMEs) และเจ้าของเนื้อหาและผู้สร้าง: ทีมและบุคคลที่สนับสนุนการวิเคราะห์ในแผนกและการออกแบบและปรับใช้โซลูชันสําหรับบริการตนเอง BI ของแผนกหรือ สถานการณ์การใช้งานของ team BI

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

หมายเหตุ

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

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ OKR ดูทําความรู้จักกับ OKRs (เป้าหมายของ Microsoft Viva)

มีหลายวิธีในการวางแผนและใช้โซลูชัน BI บทความนี้อธิบายวิธีการหนึ่งที่คุณสามารถใช้เพื่อวางแผนและใช้โซลูชัน BI ที่สนับสนุนกลยุทธ์ BI ของคุณ

แผนภาพระดับสูงต่อไปนี้แสดงวิธีการดําเนินการวางแผนโซลูชัน BI

คุณทําตามขั้นตอนต่อไปนี้เพื่อดําเนินการวางแผนโซลูชัน BI

ก้าว	คำอธิบาย
1	รวบรวมทีมโครงการที่รวบรวมข้อกําหนดและกําหนดการออกแบบโซลูชัน
2	วางแผนสําหรับการปรับใช้โซลูชันโดยการดําเนินการตั้งค่าเริ่มต้นของเครื่องมือและกระบวนการ
3	ดําเนินการพิสูจน์โซลูชันของแนวคิด (POC) เพื่อตรวจสอบความถูกต้องของสมมติฐานเกี่ยวกับการออกแบบ
4	สร้างและตรวจสอบเนื้อหาโดยใช้วงจรการพัฒนาและการตรวจสอบความถูกต้องซ้ํา
5	ปรับใช้ สนับสนุน และตรวจสอบโซลูชันหลังจากที่มีการเผยแพร่ไปยังสภาพแวดล้อมการผลิต

หมายเหตุ

การวางแผนโซลูชัน BI ใช้กับทั้ง BI แบบบริการตนเองและ โครงการ BI ขององค์กร

สําหรับข้อมูลเพิ่มเติม ดูชุดการ โยกย้ายข้อมูล Power BI ในขณะที่ชุดข้อมูลเกี่ยวข้องกับการโยกย้าย การดําเนินการและข้อควรพิจารณาหลักจะเกี่ยวข้องกับการวางแผนโซลูชัน

ขั้นตอนที่ 1: รวบรวมข้อกําหนด

คุณเริ่มต้นการวางแผนโซลูชันโดยการรวบรวมข้อกําหนดก่อนและกําหนดการออกแบบโซลูชัน

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

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

ต่อไปนี้คือประโยชน์บางประการจากการใช้วิธีการทํางานร่วมกันเพื่อรวบรวมข้อกําหนด

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

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

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

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

สำคัญ

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

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

หมายเหตุ

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

เตรียมพร้อมสําหรับการวางแผนโซลูชัน

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

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

เคล็ดลับ

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

รวบรวมข้อกําหนดทางธุรกิจ

การรวบรวมข้อกําหนดทางธุรกิจที่เหมาะสมเป็นสิ่งสําคัญในการออกแบบโซลูชันที่เหมาะสม ในการรวบรวมข้อกําหนดที่ถูกต้องและกําหนดการออกแบบโซลูชันที่มีประสิทธิภาพ ทีมโครงการสามารถดําเนินการเซสชันการออกแบบธุรกิจร่วมกับผู้ใช้ทางธุรกิจได้

วัตถุประสงค์ของเซสชันการออกแบบธุรกิจคือเพื่อ:

• ยืนยันขอบเขตโซลูชันเริ่มต้น
• กําหนดและทําความเข้าใจปัญหาที่โซลูชันควรจัดการ
• ระบุผู้เกี่ยวข้องหลักที่ถูกต้องสําหรับโซลูชัน
• รวบรวมข้อกําหนดทางธุรกิจที่เหมาะสม
• เตรียมการออกแบบโซลูชันที่ตรงกับความต้องการทางธุรกิจ
• เตรียมเอกสารประกอบการออกแบบที่สนับสนุน

แผนภาพต่อไปนี้แสดงวิธีการรวบรวมข้อกําหนดทางธุรกิจและกําหนดการออกแบบโซลูชันโดยใช้วิธีการออกแบบธุรกิจ

แผนภาพแสดงขั้นตอนต่อไปนี้

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

การออกแบบธุรกิจสรุปด้วยการส่งมอบดังต่อไปนี้

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

การส่งมอบการออกแบบธุรกิจถูกใช้และผ่านการตรวจสอบโดยการออกแบบทางเทคนิค

เคล็ดลับ

การจําลองโซลูชัน ต้นแบบ หรือแผนผัง wireframe สามารถสร้างความเข้าใจที่ชัดเจนของผลลัพธ์ที่คาดไว้ทั้งสําหรับนักพัฒนาและผู้ใช้ปลายทาง การสร้างตัวอย่างตัวอย่างที่มีประสิทธิภาพไม่จําเป็นต้องมีความสามารถทางศิลปะหรือความสามารถพิเศษ คุณสามารถใช้เครื่องมือง่ายๆ เช่น Microsoft Whiteboard, PowerPoint หรือแม้แต่ปากกาและกระดาษเพื่อแสดงให้เห็นการออกแบบ

รวบรวมข้อกําหนดทางเทคนิค

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

หมายเหตุ

การออกแบบทางเทคนิคส่วนใหญ่เป็นการตรวจสอบอย่างอิสระในข้อมูลต้นทางและระบบที่ดําเนินการโดยผู้สร้างและเจ้าของเนื้อหา

วัตถุประสงค์ของการออกแบบทางเทคนิคคือ:

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

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

ตัวอย่างของผู้มีส่วนได้เสียในการออกแบบทางเทคนิคอาจเป็น:

• ทีมรักษาความปลอดภัยและเครือข่าย: รับผิดชอบในการตรวจสอบความปลอดภัยและการปฏิบัติตามกฎระเบียบของข้อมูล
• ทีมการทํางานและข้อมูลขอบเขตข้อมูล: รับผิดชอบในการดูแลแหล่งข้อมูล
• สถาปนิก: เจ้าของแพลตฟอร์ม เครื่องมือ หรือเทคโนโลยีที่เฉพาะเจาะจง

ทีมโครงการมีส่วนร่วมกับผู้เกี่ยวข้องในเซสชันการออกแบบทางเทคนิคเพื่อจัดการกับแง่มุมทางเทคนิคของโซลูชัน แง่มุมทางเทคนิคอาจรวมถึง:

• การเชื่อมต่อแหล่งข้อมูล : รายละเอียดเกี่ยวกับวิธีการเชื่อมต่อ และรวม แหล่งข้อมูล
• เครือข่ายและเกตเวย์ข้อมูล: รายละเอียดเกี่ยวกับเครือข่ายส่วนตัวหรือแหล่งข้อมูลภายในองค์กร
• การแมปแหล่งข้อมูล: การแมปข้อมูลของเมตริกธุรกิจและแอตทริบิวต์ไปยังเขตข้อมูลแหล่งข้อมูล
• ตรรกะการคํานวณ: การแปลคําจํากัดความทางธุรกิจเป็นการคํานวณทางเทคนิค
• คุณลักษณะทางเทคนิค: คุณลักษณะหรือฟังก์ชันการทํางานที่จําเป็นในการสนับสนุนข้อกําหนดทางธุรกิจ

เคล็ดลับ

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

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

แผนภาพต่อไปนี้แสดงวิธีการแปลความต้องการทางธุรกิจเป็นข้อกําหนดทางเทคนิคโดยใช้การออกแบบทางเทคนิค

แผนภาพแสดงขั้นตอนต่อไปนี้

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

หมายเหตุ

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

การออกแบบทางเทคนิคสรุปกับแผนโซลูชันซึ่งประกอบด้วยการส่งมอบดังต่อไปนี้

• เครื่องมือและเทคโนโลยี : รายการของเครื่องมือทางเทคนิคที่เกี่ยวข้องที่จําเป็นในการใช้งานโซลูชัน โดยทั่วไปรายการมีตัวเลือกสิทธิ์การใช้งานใหม่ที่เกี่ยวข้อง (เช่น ความจุ Fabric หรือ Premium ต่อผู้ใช้) คุณลักษณะ และเครื่องมือ
• รายการเมตริกธุรกิจที่กําหนด: การคํานวณและการแมปแหล่งข้อมูลของเขตข้อมูลของเมตริกธุรกิจสําหรับแหล่งข้อมูลในขอบเขตทั้งหมด หากต้องการสร้างผลที่ได้ ทีมโครงการจะใช้รายการเมตริกธุรกิจที่สร้างขึ้นในการออกแบบธุรกิจ
• แอตทริบิวต์ธุรกิจที่กําหนดไว้: การแมปแหล่งข้อมูลของแอตทริบิวต์ธุรกิจสําหรับแหล่งข้อมูลในขอบเขตทั้งหมด เพื่อให้สามารถส่งมอบได้ ทีมโครงการจะใช้รายการแอตทริบิวต์ธุรกิจที่สร้างขึ้นในการออกแบบธุรกิจ
• ปรับปรุงการออกแบบ: การแก้ไขการออกแบบโซลูชันตามการเปลี่ยนแปลงหรือสมมติฐานที่ไม่ถูกต้องเกี่ยวกับการออกแบบธุรกิจ การออกแบบที่แก้ไขแล้วเป็นเวอร์ชั่นที่อัปเดตของแบบจําลองต้นแบบหรือไดอะแกรม wireframe ที่สร้างขึ้นในการออกแบบธุรกิจ หากไม่มีการแก้ไขใด ๆ ที่จําเป็น ให้สื่อสารว่าการออกแบบทางเทคนิคตรวจสอบการออกแบบธุรกิจ
• การประมาณความพยายาม: การประมาณการทรัพยากรที่จําเป็นในการพัฒนา สนับสนุน และรักษาโซลูชัน การประมาณการแจ้งการตัดสินใจขั้นสุดท้ายเกี่ยวกับว่าจะดําเนินการตามโซลูชันหรือไม่

สำคัญ

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

เคล็ดลับ

เนื่องจากวัตถุประสงค์ทางธุรกิจมีการพัฒนาอย่างไม่แปรปรวน จึงคาดว่าข้อกําหนดนั้นจะเปลี่ยนแปลงไป อย่าถือว่าข้อกําหนดสําหรับโครงการ BI ได้รับการแก้ไข ถ้าคุณดิ้นรนกับข้อกําหนดที่เปลี่ยนแปลง อาจเป็นข้อบ่งชี้ว่ากระบวนการรวบรวมข้อกําหนดของคุณไม่มีประสิทธิภาพ หรือเวิร์กโฟลว์การพัฒนาของคุณไม่รวมคําติชมทั่วไปเพียงพอ

รายการ ตรวจสอบ - เมื่อรวบรวมข้อกําหนด การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

ขั้นตอนที่ 2: วางแผนสําหรับการปรับใช้

เมื่อทีมโครงการรวบรวมข้อกําหนดการสร้างแผนโซลูชันและรับการอนุมัติเพื่อดําเนินการต่อก็พร้อมที่จะวางแผนสําหรับการปรับใช้โซลูชัน

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

วางแผนไปยังพื้นที่หลัก

ทีมโครงการควรวางแผนสําหรับพื้นที่สําคัญในการปรับใช้โซลูชัน โดยทั่วไปแล้ว การวางแผนควรจัดการเรื่องต่อไปนี้

• Compliance: ตรวจสอบให้แน่ใจว่าเกณฑ์การปฏิบัติตามข้อกําหนดทั้งหมดที่ระบุในการรวบรวมข้อกําหนดจะได้รับการแก้ไขโดยการดําเนินการเฉพาะ กําหนดการดําเนินการเหล่านี้ให้กับบุคคลที่เฉพาะเจาะจงและกําหนดกรอบเวลาการส่งมอบอย่างชัดเจน
• ความปลอดภัย : ตัดสินใจว่าจะจัดการเลเยอร์ของการเข้าถึงโซลูชันอย่างไร และความปลอดภัยของข้อมูล ใด ๆ ข้อกําหนดของกฎ ตรวจสอบว่าความปลอดภัยของโซลูชันจะเข้มงวดมากหรือน้อยกว่าเนื้อหามาตรฐานในผู้เช่าหรือไม่
• เกตเวย์ข้อมูล: ประเมินว่าโซลูชันจําเป็นต้องมีเกตเวย์ข้อมูลเพื่อเชื่อมต่อกับแหล่งข้อมูลหรือไม่ กําหนดว่าการตั้งค่าเกตเวย์เฉพาะหรือ คลัสเตอร์ ความพร้อมใช้งานสูงเป็นสิ่งจําเป็นหรือไม่ วางแผนว่าใครจะสามารถจัดการการเชื่อมต่อเกตเวย์ผ่านบทบาทความปลอดภัยของเกตเวย์ และวิธีการตรวจสอบเกตเวย์ สําหรับข้อมูลเพิ่มเติม ดู เตรียมใช้งานการเข้าถึงเกตเวย์
• พื้นที่ทํางาน: ตัดสินใจเลือกวิธี ตั้งค่าและใช้พื้นที่ทํางาน ตรวจสอบว่าโซลูชันจําเป็นต้องใช้เครื่องมือการจัดการวงจรชีวิต เช่น การรวม Git และ ไปป์ไลน์การปรับใช้หรือไม่ และจําเป็นต้องมีการบันทึกขั้นสูงด้วย Azure Log Analytics หรือไม่
• สนับสนุน: กําหนดบุคคลที่รับผิดชอบการสนับสนุนและบํารุงรักษาโซลูชันหลังจากการปรับใช้การผลิต หากบุคคลที่รับผิดชอบในการสนับสนุนแตกต่างจากทีมโครงการให้เกี่ยวข้องกับบุคคลเหล่านี้ในการพัฒนา ตรวจสอบให้แน่ใจว่าใครก็ตามที่สนับสนุนโซลูชันเข้าใจการออกแบบโซลูชัน ปัญหาที่ควรแก้ปัญหาที่ควรใช้ และวิธีการ
• การฝึกอบรมผู้ใช้ : คาดว่าความพยายามที่จําเป็นในการฝึกชุมชนผู้ใช้เพื่อให้พวกเขาสามารถใช้โซลูชันได้อย่างมีประสิทธิภาพ พิจารณาว่าการดําเนินการจัดการการเปลี่ยนแปลงเฉพาะใด ๆ เป็นสิ่งจําเป็นหรือไม่
• การกํากับดูแล : ระบุความเสี่ยงทางการกํากับดูแลที่อาจเกิดขึ้นสําหรับโซลูชัน คาดว่าความพยายามที่จําเป็นเพื่อให้ผู้ใช้สามารถใช้โซลูชันได้อย่างมีประสิทธิภาพ ในขณะที่บรรเทาความเสี่ยงด้านการกํากับดูแล (ตัวอย่างเช่น โดยใช้ ป้ายชื่อ ระดับความลับและ นโยบาย)

ดําเนินการตั้งค่าเริ่มต้น

ทีมโครงการควรดําเนินการตั้งค่าเริ่มต้นเพื่อเริ่มต้นการพัฒนา กิจกรรมการตั้งค่าเริ่มต้นอาจรวมถึง:

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

หมายเหตุ

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการวางแผนการปรับใช้ โปรดดู วางแผนการปรับใช้เพื่อโยกย้ายข้อมูลไปยัง Power BI

รายการ ตรวจสอบ - เมื่อมีการปรับใช้โซลูชันการวางแผน การตัดสินใจที่สําคัญและการดําเนินการประกอบด้วย:

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

ขั้นตอนที่ 3: ดําเนินการพิสูจน์แนวคิด

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

เราขอแนะนําให้ใช้ปัจจัยในข้อควรพิจารณาต่อไปนี้เมื่อเตรียม POC

• เป้าหมายและขอบเขต: อธิบายวัตถุประสงค์ของ POC ของโซลูชันและขอบเขตการทํางานที่จะกล่าวถึง ตัวอย่างเช่น ทีมโครงการสามารถตัดสินใจที่จะจํากัด POC ให้เป็นพื้นที่การทํางานเดียวหรือชุดข้อกําหนดหรือคุณสมบัติเฉพาะ
• ข้อมูลต้นทาง : ระบุข้อมูลที่จะใช้ใน POC ทั้งนี้ขึ้นอยู่กับโซลูชัน ทีมโครงการอาจตัดสินใจใช้ข้อมูลชนิดต่าง ๆ เช่น:
  • ข้อมูลการผลิต (จริง)
  • ข้อมูลตัวอย่าง
  • สร้างข้อมูลสังเคราะห์ที่คล้ายกับปริมาณข้อมูลจริงและความซับซ้อนที่สังเกตได้ในสภาพแวดล้อมการผลิต
• การสาธิต: อธิบายวิธีการและช่วงเวลาที่ทีมโครงการจะสาธิต POC ให้กับผู้เกี่ยวข้องและผู้ใช้ คุณสามารถให้การสาธิตระหว่างการอัปเดตปกติหรือเมื่อ POC เติมตามเกณฑ์การทํางานเฉพาะ
• สภาพแวดล้อม : อธิบายตําแหน่งที่ทีมโครงการจะสร้าง POC วิธีการที่ดีคือการใช้สภาพแวดล้อม Sandbox ที่แตกต่างกันสําหรับ POC และปรับใช้กับสภาพแวดล้อมการพัฒนาเมื่อพร้อม สภาพแวดล้อมของ Sandbox มีนโยบายที่ยืดหยุ่นและเนื้อหาแบบไหลมากกว่า และให้ความสําคัญกับการสร้างผลลัพธ์ที่รวดเร็ว ในทางตรงกันข้าม สภาพแวดล้อมการพัฒนาจะติดตามกระบวนการที่มีโครงสร้างมากกว่าที่เปิดใช้งานการทํางานร่วมกัน และมุ่งเน้นไปที่การทํางานที่เฉพาะเจาะจง
• เกณฑ์ความสําเร็จ: กําหนดเกณฑ์เมื่อ POC ประสบความสําเร็จและควรย้ายไปยังการทําซ้ําถัดไปและเข้าสู่การพัฒนาอย่างเป็นทางการ ก่อนที่จะเริ่มต้น POC ทีมโครงการควรระบุเกณฑ์ที่ชัดเจนว่าเมื่อ POC ประสบความสําเร็จหรือไม่ โดยการตั้งค่าเกณฑ์เหล่านี้ล่วงหน้า ทีมโครงการจะกําหนดเมื่อการพัฒนา POC สิ้นสุดลงและเมื่อวงจรการพัฒนาและการตรวจสอบความถูกต้องเริ่มต้นขึ้น ขึ้นอยู่กับเป้าหมายของ POC ทีมโครงการสามารถกําหนดเกณฑ์ความสําเร็จที่แตกต่างกันเช่น:
  • การอนุมัติ POC โดยผู้ถือผลประโยชน์ร่วม
  • การตรวจสอบความถูกต้องของคุณลักษณะหรือฟังก์ชันการทํางาน
  • การตรวจสอบที่ดีของ POC โดยเพื่อนร่วมงานหลังจากเวลาการพัฒนาคงที่
• ล้มเหลว: ตรวจสอบให้แน่ใจว่าทีมโครงการสามารถระบุความล้มเหลวของ POC ได้ การระบุความล้มเหลวในช่วงแรกๆ จะช่วยในการตรวจสอบสาเหตุที่แท้จริง นอกจากนี้ยังสามารถช่วยในการหลีกเลี่ยงการลงทุนในโซลูชันที่ไม่ทํางานตามที่คาดไว้เมื่อมีการปรับใช้กับการผลิต

ข้อควรระวัง

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

หมายเหตุ

สําหรับข้อมูลเพิ่มเติม โปรดดูที่ ดําเนินการพิสูจน์แนวคิดเพื่อโยกย้ายข้อมูลไปยัง Power BI

รายการตรวจสอบ - เมื่อสร้าง POC การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

ขั้นตอนที่ 4: สร้างและตรวจสอบเนื้อหา

เมื่อ POC ประสบความสําเร็จ ทีมโครงการจะเปลี่ยนจาก POC เป็นการสร้างและตรวจสอบเนื้อหา ทีมโครงการสามารถพัฒนาโซลูชัน BI ด้วยวงจรการพัฒนาและการตรวจสอบความถูกต้องซ้ํา รอบเหล่านี้ประกอบด้วยการเผยแพร่ซ้ํา ซึ่งทีมโครงการสร้างเนื้อหาในสภาพแวดล้อมการพัฒนาและเผยแพร่ไปยังสภาพแวดล้อมการทดสอบ ในระหว่างการพัฒนา ทีมโครงการจะค่อยๆ บอร์ดชุมชนผู้ใช้ในกระบวนการนําร่องไปจนถึงเวอร์ชันเริ่มต้น (รุ่นเบต้า) ของโซลูชันในสภาพแวดล้อมการทดสอบ

เคล็ดลับ

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

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

แผนภาพต่อไปนี้แสดงวิธีการที่ทีมโครงการสามารถส่งมอบโซลูชัน BI ซ้ํา ๆ ด้วยวงจรการพัฒนาและการตรวจสอบความถูกต้อง

แผนภาพแสดงขั้นตอนต่อไปนี้

รายการ	คำอธิบาย
	ทีมโครงการจะสื่อสารแต่ละการเผยแพร่ไปยังชุมชนผู้ใช้ โดยอธิบายการเปลี่ยนแปลงและคุณลักษณะใหม่ ตามแนวคิดแล้ว การสื่อสารรวมถึงการสาธิตโซลูชันและ Q&A ดังนั้นผู้ใช้จึงเข้าใจว่ามีอะไรใหม่ในการเผยแพร่ และพวกเขาสามารถให้คําติชมด้วยคําพูดได้
	ในระหว่างการตรวจสอบ ผู้ใช้ให้คําติชมผ่านเครื่องมือหรือฟอร์มส่วนกลาง ทีมโครงการควรตรวจสอบคําติชมอย่างสม่ําเสมอเพื่อแก้ไขปัญหา ยอมรับหรือปฏิเสธคําขอ และแจ้งระยะการพัฒนาที่จะเกิดขึ้น
	ทีมโครงการจะตรวจสอบการใช้โซลูชันเพื่อยืนยันว่าผู้ใช้กําลังทดสอบโซลูชันอยู่ ถ้าไม่มีการใช้งานใด ๆ ทีมโครงการควรมีส่วนร่วมกับชุมชนผู้ใช้เพื่อทําความเข้าใจเหตุผลว่าทําไม การใช้งานต่ําสามารถบ่งบอกว่าทีมโครงการจําเป็นต้องเปิดใช้งานและดําเนินการจัดการการเปลี่ยนแปลงต่อไป
	ทีมโครงการตอบสนองคําติชมของผู้ใช้ทันที หากทีมโครงการใช้เวลาในการตอบกลับนานเกินไป ผู้ใช้อาจสูญเสียแรงจูงใจในการให้ข้อมูลอย่างรวดเร็ว
	ทีมโครงการรวมคําติชมที่ยอมรับในการวางแผนโซลูชัน หากจําเป็น พวกเขาจะตรวจสอบลําดับความสําคัญของการวางแผนเพื่อชี้แจงและมอบหมายงานก่อนระยะการพัฒนาถัดไปจะเริ่มต้น
	ทีมโครงการยังคงพัฒนาโซลูชันสําหรับการเผยแพร่ถัดไป
	ทีมโครงการจะวนซ้ําผ่านขั้นตอนทั้งหมดจนกว่าจะถึงข้อสรุปที่กําหนดไว้ล่วงหน้า และโซลูชันพร้อมสําหรับการปรับใช้การผลิตแล้ว

ส่วนต่อไปนี้อธิบายข้อควรพิจารณาหลักสําหรับการใช้วงจรการพัฒนาซ้ําและการตรวจสอบความถูกต้องเพื่อส่งมอบโซลูชัน BI

สร้างเนื้อหา

ทีมโครงการจะพัฒนาโซลูชันโดยทําตามเวิร์กโฟลว์การพัฒนาปกติ อย่างไรก็ตาม พวกเขาควรพิจารณาประเด็นต่อไปนี้เมื่อสร้างเนื้อหา

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

ตรวจสอบเนื้อหา

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

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

สำคัญ

ตรวจสอบให้แน่ใจว่าปัญหาคุณภาพข้อมูลใด ๆ ได้รับการแก้ไขในระหว่างการตรวจสอบความถูกต้องของนักพัฒนา (ก่อน UAT) ปัญหาเหล่านี้สามารถกัดกร่อนความน่าเชื่อถือในโซลูชันได้อย่างรวดเร็วและอาจเป็นอันตรายต่อการใช้ในระยะยาว

เคล็ดลับ

เมื่อดําเนินการตรวจสอบความถูกต้องของผู้ใช้ ให้พิจารณาการเรียกสั้นๆ กับผู้ใช้หลักเป็นครั้งคราว สังเกตเมื่อพวกเขาใช้โซลูชัน จดบันทึกเกี่ยวกับสิ่งที่พวกเขาพบได้ยากหรือส่วนใดของโซลูชันไม่ทํางานตามที่คาดไว้ วิธีการนี้อาจเป็นวิธีที่มีประสิทธิภาพในการรวบรวมคําติชม

ปัจจัยในข้อควรพิจารณาต่อไปนี้เมื่อทีมงานโครงการตรวจสอบเนื้อหา

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

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

หมายเหตุ

การพัฒนาและการทดสอบแตกต่างกันโดยขึ้นอยู่กับโซลูชันและเวิร์กโฟลว์ที่คุณต้องการ

บทความนี้อธิบายเฉพาะการวางแผนระดับสูงและรายการที่สามารถดําเนินการได้เท่านั้น สําหรับข้อมูลเพิ่มเติมเกี่ยวกับวงจรการพัฒนาและการทดสอบซ้ํา ดูสร้างเนื้อหาเพื่อโยกย้ายข้อมูลไปยัง Power BI

รายการ ตรวจสอบ - เมื่อสร้างและตรวจสอบเนื้อหา การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

ขั้นตอนที่ 5: ปรับใช้ สนับสนุน และตรวจสอบ

เมื่อพร้อมแล้ว ทีมโครงการจะปรับใช้โซลูชันที่มีการตรวจสอบความถูกต้องไปยังสภาพแวดล้อมการผลิต ทีมโครงการควรนําการดําเนินการที่สําคัญไปใช้และสนับสนุนเพื่อให้แน่ใจว่าการปรับใช้จะประสบความสําเร็จ

เพื่อให้แน่ใจว่าการปรับใช้สําเร็จ คุณต้องดําเนินการงานการสนับสนุนและการปรับใช้ต่อไปนี้

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

ข้อควรระวัง

การล้มเหลวในการส่งมอบสินค้าที่มีประสิทธิภาพอาจนําไปสู่ปัญหาที่ป้องกันได้ด้วยการสนับสนุนโซลูชันและการนํามาใช้ในระหว่างวงจรชีวิต

หลังจากการปรับใช้ ทีมโครงการควรวางแผนที่จะดําเนินการตามโซลูชันถัดไปในงานที่ค้างอยู่ของโซลูชันที่จัดลําดับความสําคัญ ตรวจสอบให้แน่ใจว่าคุณได้รวบรวมคําติชมและคําขอใหม่ และทําการแก้ไข การวางแผนทางยุทธวิธี—รวมถึงรายการตกค้างของโซลูชันถ้าจําเป็น

รายการ ตรวจสอบ – เมื่อพิจารณาการปรับใช้โซลูชัน การตัดสินใจที่สําคัญและการดําเนินการประกอบด้วย:

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

เนื้อหาที่เกี่ยวข้อง

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