การวางแผนการใช้งาน Power BI: วางแผนและออกแบบเนื้อหา

โน้ต

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

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

• ทีม Center of Excellence (COE) และ BI: ทีมที่มีหน้าที่ดูแล Power BI ในองค์กร ทีมเหล่านี้ประกอบด้วยผู้มีอํานาจตัดสินใจที่ตัดสินใจวิธีการจัดการวงจรชีวิตของเนื้อหา Power BI
• ผู้สร้างเนื้อหาและเจ้าของเนื้อหา: ผู้ใช้ที่สร้างเนื้อหาที่ต้องการเผยแพร่ไปยังพอร์ทัล Fabric เพื่อแชร์กับผู้อื่น บุคคลเหล่านี้มีหน้าที่รับผิดชอบในการจัดการวงจรชีวิตของเนื้อหา Power BI ที่พวกเขาสร้าง

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

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

รูปภาพต่อไปนี้แสดงวงจรชีวิตของเนื้อหา Power BI การเน้นลําดับขั้นที่หนึ่ง ซึ่งคุณวางแผนและออกแบบเนื้อหา

แผนภาพ

โน้ต

สําหรับภาพรวมของการจัดการวงจรชีวิตเนื้อหา ดูบทความแรก ในชุดนี้

ปลาย

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

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

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

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

ระบุและอธิบายเนื้อหา

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

โน้ต

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

ตอบคําถามต่อไปนี้เกี่ยวกับเนื้อหาของคุณเพื่อช่วยให้คุณตัดสินใจในการจัดการวงจรชีวิตในภายหลัง

รูปแบบของเนื้อหาคืออะไร

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

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

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

ปลาย

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

สําหรับตัวอย่างของไดอะแกรมดังกล่าว ดูการวางแผนการใช้งาน Power BI ไดอะแกรมสถานการณ์การใช้งาน

ใครจะสร้างและสนับสนุนเนื้อหา

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

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

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

สําคัญ

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

ความสําคัญของเนื้อหาคืออะไร

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

ตอบคําถามต่อไปนี้เพื่อช่วยให้คุณตรวจสอบว่าเนื้อหามีความสําคัญหรือไม่

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

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

ตัดสินใจว่าผู้สร้างเนื้อหาควรทํางานร่วมกันอย่างไร

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

ปลาย

แม้ว่าผู้สร้างเนื้อหาจะทํางานอย่างอิสระ พวกเขายังคงได้รับประโยชน์จากการวางแผนและจัดโครงสร้างงานของพวกเขาโดยใช้เครื่องมือ เช่น Microsoft Teams และ Azure DevOps

Microsoft Teams

สําหรับโครงการที่มีขนาดเล็กกว่าหรือง่ายขึ้น ผู้สร้างเนื้อหาสามารถทํางานร่วมกันโดยใช้ Microsoft Teams

แผนภาพ

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

ปลาย

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

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

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

เราขอแนะนําให้คุณกําหนดกระบวนการที่มีโครงสร้างสําหรับวิธีที่ผู้สร้างเนื้อหาควรใช้ Microsoft Teams เพื่อทํางานร่วมกัน ตรวจสอบให้แน่ใจว่าคุณกําหนด:

• วิธีการจัดการการเข้าถึงทีมและช่อง
• ใครเป็นผู้รับผิดชอบในการจัดการทีมและแชนเนล
• วิธีการทํางานมีขอบเขตและจัดระเบียบเป็นทีม ช่อง และแผนที่แตกต่างกัน
• วิธีที่ผู้สร้างเนื้อหาควรใช้ไลบรารีเอกสารเพื่อจัดระเบียบแฟ้ม และติดตาม และจัดการการเปลี่ยนแปลง ตัวอย่างเช่น วิธีการจัดระเบียบไลบรารีเอกสาร และกําหนดว่าผู้สร้างเนื้อหาควรเช็คอินและเช็คเอาท์แฟ้มหรือไม่
• ไม่ว่าผู้สร้างเนื้อหาควรใช้ OneDrive Refresh เพื่อเผยแพร่ไฟล์ Power BI Desktop (.pbix) โดยอัตโนมัติหรือไม่
• วิธีการแก้ไขข้อขัดแย้งของการซิงค์ไฟล์
• เมื่อต้องการเก็บถาวรและเอาแฟ้มออกจากไลบรารีเอกสารที่ไม่เกี่ยวข้องอีกต่อไป

Azure DevOps

ผู้สร้างและเจ้าของเนื้อหายังสามารถสื่อสารและทํางานร่วมกันในฮับส่วนกลางที่เป็นระเบียบโดยใช้ Azure DevOps

แผนภาพ

โน้ต

Azure DevOps คือชุดของบริการที่รวมเข้ากับ Power BI และ Fabric เพื่อช่วยให้คุณวางแผนและปรับแต่งการจัดการวงจรชีวิตเนื้อหา เมื่อคุณใช้ Azure DevOps ด้วยวิธีนี้ โดยทั่วไปแล้วคุณจะใช้ประโยชน์จากบริการต่อไปนี้:

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

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

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

ปลาย

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

เราขอแนะนําให้คุณกําหนดกระบวนการที่มีโครงสร้างสําหรับวิธีที่ผู้สร้างเนื้อหาควรใช้ Azure DevOps เพื่อทํางานร่วมกัน ตรวจสอบให้แน่ใจว่าคุณกําหนด:

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

โน้ต

คุณยังสามารถใช้ Microsoft Teams ร่วมกับ Azure DevOps เนื่องจากมีวิธีต่าง ๆ ในการรวมบริการเหล่านี้ ตัวอย่างเช่น คุณสามารถดูและจัดการ บอร์ด Azure และตรวจสอบเหตุการณ์ใน Azure Pipelines จากภายใน Microsoft Teams

สิ่งสําคัญที่สุดคือคุณใช้เครื่องมือและบริการที่อํานวยความสะดวกในการทํางานร่วมกันให้คุณและเหมาะสมกับความต้องการของทีมของคุณและวิธีการทํางานของทีมมากที่สุด

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

ตัดสินใจว่าจะจัดเก็บไฟล์ไว้ที่ใด

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

ปลาย

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

ชนิดของไฟล์ที่คุณจะต้องเก็บไว้มักจะรวมถึง:

• ไฟล์เนื้อหา: ไฟล์ที่ประกอบด้วยข้อมูลเนื้อหาหรือเมตาดาต้า ไฟล์เนื้อหาที่มีข้อมูลเช่นไฟล์ .pbix และ Power BI Project (.pbip) ประกอบด้วยข้อมูลที่สําคัญ จัดเก็บไฟล์เนื้อหาในตําแหน่งที่ตั้งที่ปลอดภัยซึ่งสามารถเข้าถึงได้โดยผู้ที่ต้องการเข้าถึงเท่านั้น นอกจากนี้ คุณควรจัดเก็บไฟล์เนื้อหาในตําแหน่งที่ตั้งที่สนับสนุนการควบคุมเวอร์ชัน เช่น ไลบรารีเอกสารใน Microsoft Teams หรือที่เก็บ Git ใน Azure DevOps ตัวอย่างของไฟล์เนื้อหาได้แก่:
  • ไฟล์ Power BI Desktop (.pbix)
  • ไฟล์โครงการ Power BI (.pbip)
  • ไฟล์รายงานที่มีการแบ่งหน้าของ Power BI (.rdl)
  • ไฟล์เมตาดาต้าแบบจําลอง (.bim หรือ TMDL)
  • ไฟล์เมตาดาต้าของกระแสข้อมูล (.json)
• ไฟล์แหล่งข้อมูล: ไฟล์ที่ใช้โดยรายการข้อมูล เช่น แบบจําลองเชิงความหมายหรือกระแสข้อมูล เนื้อหาจะขึ้นอยู่กับไฟล์แหล่งข้อมูลโดยตรง ดังนั้นจึงเป็นสิ่งสําคัญที่ต้องพิจารณาอย่างรอบคอบถึงตําแหน่งที่จัดเก็บเนื่องจากการลบไฟล์เหล่านั้นจะส่งผลให้การรีเฟรชข้อมูลล้มเหลว นอกจากนี้ ไฟล์เหล่านี้อาจมีข้อมูลที่ละเอียดอ่อน ดังนั้น จัดเก็บไฟล์แหล่งข้อมูลในสภาพแวดล้อมที่ปลอดภัย เชื่อถือได้ และเชื่อถือได้ที่จํากัดการเข้าถึงโดยบุคคลอื่น ตัวอย่างของไฟล์แหล่งข้อมูลอาจรวมถึง:
  • แหล่งข้อมูลที่มีโครงสร้าง เช่น เวิร์กบุ๊ก Excel, Parquet หรือไฟล์ CSV
  • แหล่งข้อมูลแบบกึ่งมีโครงสร้าง เช่น ไฟล์ JSON หรือ XML
  • แหล่งข้อมูลที่ไม่มีโครงสร้าง เช่น รูปภาพที่คุณนําเข้าลงในรายงาน
• สนับสนุนไฟล์: ไฟล์ที่สนับสนุนการสร้างเนื้อหาหรือการจัดการ แต่ไม่จําเป็นสําหรับการทํางาน ไฟล์สนับสนุนควรถูกจัดเก็บไว้ในตําแหน่งที่ตั้งที่สนับสนุนการควบคุมเวอร์ชัน และตําแหน่งที่เครื่องมือและผู้สร้างเนื้อหาอื่น ๆ สามารถเข้าถึงได้ ตัวอย่างของไฟล์สนับสนุนอาจรวมถึง:
  • ไฟล์กฎตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุด (.json)
  • ไฟล์ธีม Power BI (.json)
  • ไฟล์ซอร์สโค้ดสําหรับเนื้อหาและคิวรี
  • ไฟล์การแสดงภาพแบบกําหนดเอง (.pbiviz)
• เทมเพลตและเอกสาร: ไฟล์ที่ช่วยในการสร้างเนื้อหาแบบบริการตนเองหรืออธิบายเนื้อหาที่มีอยู่ เทมเพลตและเอกสารควรสามารถเข้าถึงได้โดยบุคคลที่จําเป็นต้องใช้เทมเพลตและเอกสาร ตัวอย่างของเทมเพลตและเอกสารอาจรวมถึง:
  • ไฟล์เทมเพลต Power BI (.pbit)
  • เทมเพลตการแสดงภาพและรายงานตัวอย่าง
  • การออกแบบโซลูชันและเอกสารประกอบ
  • การวางแผนโซลูชันและแผนงาน
  • คําขอของผู้ใช้และปัญหาในการแก้ไขปัญหา

ความระมัดระวัง

ไฟล์เนื้อหาบางอย่างเช่นไฟล์ .pbix และ .pbip สามารถมีข้อมูลที่สําคัญที่นําเข้าจากแหล่งข้อมูลได้ นอกจากนี้ไฟล์เมตาดาต้า เช่น ไฟล์ TMDL หรือ .pbit ยังสามารถประกอบด้วยข้อมูลที่สําคัญได้ ตรวจสอบให้แน่ใจว่าคุณใช้มาตรการป้องกันที่จําเป็นในการจัดเก็บไฟล์เหล่านี้ในตําแหน่งที่ปลอดภัยและคุณฝึกฝนการป้องกันการสูญหายของข้อมูล ที่มีประสิทธิภาพ

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

SharePoint Online หรือ OneDrive

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

เมื่อคุณจัดเก็บไฟล์ใน SharePoint ให้พิจารณาประเด็นต่อไปนี้

• องค์กร: ตรวจสอบให้แน่ใจว่าคุณรักษาโครงสร้างที่สอดคล้องกันและตรรกะดังนั้นจึงตรงไปตรงมาเพื่อค้นหาไฟล์ที่เฉพาะเจาะจง ใช้มาตรฐานการตั้งชื่อที่ดี จัดระเบียบไฟล์ในโฟลเดอร์ และเก็บไฟล์ถาวรที่ไม่เกี่ยวข้องกับโครงการที่กําลังดําเนินอยู่อีกต่อไป
• รีเฟรช OneDrive : คุณสามารถ ลิงก์ แบบจําลองความหมายที่เผยแพร่หรือรายงานไปยังไฟล์ .pbix ที่จัดเก็บไว้ในไซต์ SharePoint หรือ OneDrive for Business (หรือที่เรียกว่า OneDrive สําหรับที่ทํางานหรือโรงเรียน) ด้วยวิธีนี้ คุณไม่จําเป็นต้องเผยแพร่แบบจําลองความหมายเพื่อทําให้การเปลี่ยนแปลงมีผลใช้งานอีกต่อไป แต่การเปลี่ยนแปลงของคุณจะปรากฏหลังจากการรีเฟรช OneDrive อัตโนมัติ ที่เกิดขึ้นเป็นรายชั่วโมง ในขณะที่สะดวกโปรดทราบว่าวิธีนี้มาพร้อมกับข้อแม้และความท้าทาย เมื่อสิ่งต่างๆ เกิดขึ้น จะไม่สามารถย้อนกลับได้อย่างง่ายดาย
• แสดงตัวอย่างรายงาน: ใน SharePoint คุณสามารถดูรายงาน Power BI โดยไม่ต้องติดตั้ง Power BI Desktop หรือดาวน์โหลดไฟล์ .pbix ภายในเครื่อง เมื่อคุณเปิดรายงานด้วยวิธีนี้ รายงานเหล่านั้นจะแสดงในเบราว์เซอร์ ความสามารถนี้สามารถเป็นทางเลือกที่สะดวกในการดูรายงานจากพอร์ทัล Fabric ซึ่งจะเปิดใช้งาน ตามค่าเริ่มต้น ในการตั้งค่าผู้เช่า Fabric

ปลาย

เมื่อคุณทํางานร่วมกันโดยใช้ Microsoft Teams ให้พิจารณาจัดเก็บไฟล์ในไลบรารีเอกสารแชนเนล วิธีนี้ช่วยรวมศูนย์ไฟล์และอํานวยความสะดวกในการทํางานร่วมกัน

พิจารณาจัดเก็บชนิดไฟล์ต่อไปนี้ใน SharePoint

• เทมเพลตและเอกสาร: จัดเก็บเทมเพลตและเอกสารใน SharePoint เมื่อคุณไม่มีโซลูชันที่เก็บข้อมูลที่มีอยู่ SharePoint เหมาะสําหรับไฟล์เหล่านี้เนื่องจากคุณสามารถให้สิทธิ์การเข้าถึงแก่ผู้อื่นและจัดการไฟล์ได้โดยไม่ต้องมีการตั้งค่าหรือกระบวนการที่ซับซ้อน
• ไฟล์ที่สนับสนุน: จัดเก็บไฟล์ที่สนับสนุนใน SharePoint เมื่อคุณไม่มีโซลูชันที่เก็บข้อมูลที่มีอยู่ อย่างไรก็ตาม ไฟล์ที่สนับสนุนบางอย่าง (เช่น ธีม Power BI .json ไฟล์สําหรับรายงาน) อาจถูกจัดเก็บไว้ในระบบควบคุมเวอร์ชันที่ช่วยให้สามารถดูและจัดการการเปลี่ยนแปลงที่บันทึกไว้ได้ดีขึ้น
• ไฟล์เนื้อหา: จัดเก็บเนื้อหาใน SharePoint เมื่อไม่สําคัญต่อธุรกิจ หรือเมื่อคุณไม่สามารถเข้าถึงที่เก็บระยะไกลเช่น Azure Repos
• แหล่งข้อมูล: จัดเก็บแหล่งข้อมูลใน SharePoint เฉพาะเมื่อมีขนาดเล็กและความซับซ้อนเท่านั้น ใช้ระเบียบปฏิบัติเมื่อใช้ SharePoint เพื่อจัดเก็บไฟล์แหล่งข้อมูล พิจารณาทางเลือกอื่น ๆ ที่เป็นไปได้ เช่น OneLake

ความระมัดระวัง

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

คำเตือน

อย่าใช้ระบบไฟล์ส่วนบุคคลหรือบัญชี OneDrive ส่วนบุคคลเพื่อจัดเก็บไฟล์ ถ้าเจ้าของออกจากองค์กร ไฟล์เหล่านี้จะไม่พร้อมใช้งานอีกต่อไป

OneLake

ถ้าคุณมีความจุของ FabricOneLake สามารถเป็นตัวเลือกที่ดีในการจัดเก็บไฟล์แหล่งข้อมูล คุณสามารถ อัปโหลด หรือ ซิงโครไนซ์ไฟล์ ไปยัง OneLake โดยใช้ OneLake File Explorer ซึ่งสามารถ แปลงเป็นตาราง สําหรับการใช้งานในปริมาณงานปลายทางเช่น Power BI สําหรับแหล่งข้อมูลขนาดใหญ่หรืออัปเดตเป็นประจํา คุณสามารถโหลดไฟล์ไปยัง OneLake โดยอัตโนมัติโดยใช้ Fabric Data Factory หรือแอปพลิเคชันอื่น ๆ ที่ใช้ Azure Data Lake Storage (ADLS) Gen2 API หรือ Azure Storage Python SDK

ความระมัดระวัง

การดําเนินการเช่นการอัปโหลดหรือดาวน์โหลดไฟล์จาก OneLake ใช้หน่วยความจุ Fabric คุณควร เมตริกความจุของจอภาพ และทําตามขั้นตอนเพื่อหลีกเลี่ยงไม่ให้ความจุล้าเนื่องจากการเคลื่อนไหวของไฟล์ขนาดใหญ่ที่ไม่จําเป็น

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

คำเตือน

OneLake File Explorer มีข้อจํากัดและข้อควรพิจารณา ที่สําคัญหลายข้อ ตัวอย่างเช่น OneLake ไม่สนับสนุนการควบคุมเวอร์ชันสําหรับไฟล์ เช่น SharePoint หรือ OneDrive คํานึงถึงข้อควรพิจารณาและข้อจํากัดเหล่านี้เมื่อคุณตัดสินใจว่าจะจัดเก็บไฟล์ไว้ที่ใด

ปลาย

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

ที่เก็บระยะไกล

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

พิจารณาการจัดเก็บชนิดไฟล์ต่อไปนี้ในที่เก็บระยะไกล

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

ปลาย

เมื่อคุณใช้ที่เก็บข้อมูลระยะไกล ให้ลองจัดเก็บรายงาน Power BI และแบบจําลองความหมายเป็นไฟล์โครงการ Power BI Desktop (.pbip) แทนที่จะเป็นไฟล์ .pbix เนื่องจากไม่สามารถระบุการเปลี่ยนแปลงที่บันทึกไว้ในไฟล์ .pbix ได้

ไม่มีไฟล์: เนื้อหาที่สร้างขึ้นในพอร์ทัล Fabric

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

ความระมัดระวัง

คุณไม่สามารถดาวน์โหลดเป็นไฟล์เนื้อหาบางอย่างที่สร้างขึ้นในพอร์ทัล Fabric ได้ ตัวอย่างเช่น รายงานที่สร้างขึ้นในพอร์ทัล Fabric ไม่สามารถดาวน์โหลดเป็นไฟล์ .pbix ได้

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

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

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

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

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