เครื่องมือสถาปัตยกรรมองค์กร: วิธีเลือกให้เหมาะกับงาน
เปรียบเทียบเครื่องมือ enterprise architecture จากงานที่แต่ละเครื่องมือทำ แล้วดูว่าข้อมูลกระบวนการช่วยตรวจสอบความถูกต้องของสถาปัตยกรรมได้อย่างไร.
เครื่องมือ enterprise architecture ช่วยทำแผนที่ความสามารถ แอปพลิเคชัน ข้อมูล และกระบวนการ พร้อมแสดงความสัมพันธ์ระหว่างส่วนต่างๆ การเลือกเครื่องมือที่เหมาะสมขึ้นอยู่กับว่าคุณต้องการจัดทำรายการข้อมูล กำหนดมาตรฐานและแผนงาน หรือมีหลักฐานว่าการทำงานจริงเป็นอย่างไร.
คลังข้อมูลช่วยตอบได้ว่าคุณมีอะไรบ้าง และตั้งใจให้ส่วนต่างๆ ทำงานร่วมกันอย่างไร แต่ไม่ได้แสดงเสมอไปว่าเกิดอะไรขึ้นเมื่อผู้คนใช้ระบบและกระบวนการเหล่านั้น.
ช่องว่างนี้ไม่ได้เกิดจากความผิดพลาดของผู้ดูแลสถาปัตยกรรม วิธีทำงานเปลี่ยนไป เอกสารล้าสมัย และระบบปฏิบัติงานบันทึกหลักฐานที่โมเดลแบบคงที่ให้ไม่ได้.
เครื่องมือ enterprise architecture ใช้ทำอะไร?
เครื่องมือ enterprise architecture ช่วยอธิบายองค์กรและความสัมพันธ์ระหว่างส่วนต่างๆ โดยทั่วไปเครื่องมือเหล่านี้รองรับงานหลัก 3 ด้าน.
- **จัดทำรายการข้อมูล:**บันทึกความสามารถ กระบวนการ แอปพลิเคชัน ข้อมูล ผู้รับผิดชอบ และการพึ่งพาระหว่างกัน
- **มาตรฐานและแผนงาน:**ใช้กรอบการทำงาน เช่น TOGAF หรือ ArchiMate เพื่อประเมินการเปลี่ยนแปลงที่เสนอ และวางแผนเปลี่ยนจากสถานะปัจจุบันไปสู่สถานะเป้าหมาย
- **การวิเคราะห์:**ทำความเข้าใจว่าองค์กรดำเนินงานอย่างไร และการเปลี่ยนแปลงอาจส่งผลอย่างไร.
คลังข้อมูลช่วยตอบคำถามได้ เช่น แอปพลิเคชันใดรองรับความสามารถหนึ่ง หรือกระบวนการใดต้องพึ่งพาระบบหนึ่ง นอกจากนี้ยังช่วยให้ทีมใช้คำศัพท์ร่วมกันเมื่อต้องหารือเรื่องการเปลี่ยนแปลง.
อย่างไรก็ตาม คลังข้อมูลสถาปัตยกรรมไม่ได้อธิบายโดยอัตโนมัติว่างานดำเนินไปอย่างไรจริง ชื่อกระบวนการ ผู้รับผิดชอบ และคำอธิบายไม่ได้บอกว่ามีกี่กรณีที่ต้องใช้เส้นทางยกเว้น ต้องรอตรงไหน หรือวนกลับไปขออนุมัติกี่ครั้ง.
ความแตกต่างนี้เป็นหัวใจของการเปรียบเทียบในบทความนี้ เครื่องมือคลังข้อมูลอธิบายสิ่งที่คุณมีและตั้งใจจะทำ ส่วน ProcessMind ช่วยตรวจสอบสิ่งที่ระบบแสดงว่ากำลังเกิดขึ้น.
ควรตรวจสอบอะไรเมื่อเปรียบเทียบซอฟต์แวร์ enterprise architecture?
เปรียบเทียบซอฟต์แวร์ enterprise architecture จากงานที่คุณต้องการให้รองรับ ไม่ใช่ดูแค่ฟีเจอร์บนหน้าเว็บไซต์ของผู้ขาย.
- คลังข้อมูลและเมตาโมเดล: เครื่องมือแสดงขีดความสามารถ กระบวนการหลายระดับ แอปพลิเคชัน ข้อมูล และความสัมพันธ์ระหว่างกันได้หรือไม่ โดยไม่ต้องหาวิธีแก้ขัด?
- การรองรับกรอบการทำงาน: ผลิตภัณฑ์รองรับ ArchiMate และ TOGAF หรือมีเพียงองค์ประกอบสำหรับสร้างแผนภาพ?
- รายละเอียดกระบวนการ: คุณเจาะจากกระบวนการระดับสูงลงไปยังกระบวนการย่อย กิจกรรม เกตเวย์ และรูปแบบต่างๆ ได้หรือไม่ ขอให้ดูตัวอย่างกระบวนการที่แสดงในหลายระดับ
- การเชื่อมโยงข้อมูล: คุณรีเฟรชหรือตรวจสอบส่วนใดของสถาปัตยกรรมกับข้อมูลการปฏิบัติงานได้หรือไม่ แทนที่จะอาศัยการอัปเดตด้วยตนเองทั้งหมด
- การทำงานร่วมกันและสิทธิ์: ทีมต่างๆ ร่วมให้ข้อมูลและตรวจทานงานได้หรือไม่ ผู้ใช้ดูคลังข้อมูลได้โดยไม่ต้องมีไลเซนส์สำหรับแก้ไขหรือไม่
- การโฮสต์และที่ตั้งข้อมูล: ข้อมูลของคุณจัดเก็บที่ไหน ใครเข้าถึงได้ และตรงตามข้อกำหนดของคุณหรือไม่?
- การทำงานร่วมกันระหว่างระบบ: คุณส่งออกสถาปัตยกรรมและใช้ API หรือรูปแบบเปิดได้หรือไม่ คุณควรนำผลงานของคุณออกไปใช้ต่อได้
- ไลเซนส์: ผู้แก้ไข ผู้ตรวจสอบ และผู้ใช้ที่ดูได้อย่างเดียวต้องใช้ไลเซนส์แบบใด เปรียบเทียบค่าใช้จ่ายรวมของทุกคนที่ต้องเข้าถึง ไม่ใช่เฉพาะทีมหลัก.
ให้ความสำคัญเป็นพิเศษกับรายละเอียดกระบวนการและการเชื่อมโยงข้อมูล แผนที่ความสามารถอาจช่วยวางแผนได้ แต่จะนำไปใช้จริงได้ยากหากเชื่อมโยงกับกระบวนการที่ผู้คนทำไม่ได้.
ขอให้ผู้ขายสาธิตวิธีดูแลโมเดล คุณเจาะลำดับชั้นกระบวนการลงไปได้ลึกแค่ไหน และตรวจสอบข้อมูลส่วนใดกับข้อมูลจริงได้บ้าง คำตอบเหล่านี้ช่วยให้เห็นว่าเครื่องมือรองรับการทำงานกับกระบวนการได้จริง หรือเพียงบันทึกข้อมูลไว้.
ข้อพิจารณาเหล่านี้ช่วยให้คุณตัดสินใจได้ว่าต้องใช้คลังข้อมูล enterprise architecture ชั้นข้อมูลหลักฐานกระบวนการ หรือทั้งสองอย่าง.
เครื่องมือ enterprise architecture แบบใดเหมาะกับงานแต่ละประเภท?
เครื่องมือ enterprise architecture แต่ละประเภทตอบโจทย์ต่างกัน การเปรียบเทียบที่มีประโยชน์ควรเริ่มจากงานที่ต้องทำ ไม่ใช่จำนวนฟีเจอร์ ตารางด้านล่างจึงนำข้อพิจารณาทั้ง 8 ข้อมาเปรียบเทียบเครื่องมือแต่ละประเภท โดยวาง ProcessMind ไว้คอลัมน์สุดท้าย.
| รายการเปรียบเทียบ | ชุดเครื่องมือ EA ที่เน้นคลังข้อมูล | แพลตฟอร์มจัดการ EA | เครื่องมือสร้างไดอะแกรมและ ArchiMate | โมดูล ITSM และแพลตฟอร์ม | ProcessMind |
|---|---|---|---|---|---|
| คลังข้อมูลและเมตาโมเดล | คลังสถาปัตยกรรมขนาดใหญ่ | รายการแอปพลิเคชันและความสามารถ | โมเดลและไดอะแกรม | มุมมองสถาปัตยกรรมภายในแพลตฟอร์มขนาดใหญ่ | สถาปัตยกรรมกระบวนการที่กำหนดระดับได้ ตั้งแต่สายธารคุณค่าจนถึงกิจกรรม |
| การรองรับกรอบการทำงาน | รองรับกรอบการทำงานและแนวปฏิบัติด้านธรรมาภิบาล | ฟีเจอร์ด้านการจัดการสถาปัตยกรรม | มักเน้นมาตรฐานการสร้างไดอะแกรม | ขึ้นอยู่กับโมดูลของแพลตฟอร์ม | สายธารคุณค่าและระดับกระบวนการที่เชื่อมโยงกับวิธีทำงานจริง |
| รายละเอียดกระบวนการ | ความสามารถของคลังข้อมูลแตกต่างกันตามการตั้งค่า | มักเน้นแอปพลิเคชันและความสามารถ | รายละเอียดระดับไดอะแกรม | ขึ้นอยู่กับโมดูล | โมเดล BPMN 2.0 ที่แสดงกิจกรรม เกตเวย์ และรูปแบบการทำงานในแต่ละระดับ |
| การเชื่อมโยงข้อมูล | ขึ้นอยู่กับการเชื่อมต่อระบบและการนำไปใช้ | รองรับการจัดการรายการข้อมูล ควรตรวจสอบว่าตรงกับความต้องการด้านข้อมูลของคุณหรือไม่ | โดยทั่วไปต้องอาศัยการอัปเดตโมเดล | ขึ้นอยู่กับแพลตฟอร์มและการตั้งค่า | เชื่อมข้อมูลเหตุการณ์กับโมเดลเพื่อตรวจสอบลำดับการทำงาน |
| การทำงานร่วมกันและสิทธิ์ | ออกแบบมาสำหรับทีมสถาปัตยกรรมและธรรมาภิบาล | รองรับการจัดการสถาปัตยกรรมองค์กร | แตกต่างกันตามเครื่องมือและการติดตั้ง | ใช้สิทธิ์ของแพลตฟอร์ม | เจ้าของงานตาม RACI เวิร์กโฟลว์ธรรมาภิบาล และพอร์ทัลสำหรับผู้ดู |
| การโฮสต์และที่ตั้งข้อมูล | แตกต่างกันตามผู้ให้บริการและการติดตั้ง | รูปแบบ SaaS | แตกต่างกันตามเครื่องมือ | แตกต่างกันตามแพลตฟอร์ม | โฮสต์ในสหภาพยุโรปที่แฟรงก์เฟิร์ต |
| การทำงานร่วมกับระบบอื่น | ตรวจสอบข้อกำหนดด้านการส่งออกและการเชื่อมต่อ | ตรวจสอบข้อกำหนดด้านการส่งออกและการเชื่อมต่อ | ตรวจสอบรูปแบบไฟล์ที่รองรับ | ตรวจสอบตัวเลือกการเชื่อมต่อของแพลตฟอร์ม | นำเข้าและส่งออก BPMN 2.0 ได้ โมเดลจึงย้ายไปใช้ในรูปแบบ XML มาตรฐานได้ |
| ไลเซนส์ | เปรียบเทียบบทบาทและความต้องการด้านสิทธิ์การเข้าถึง | เปรียบเทียบบทบาทและความต้องการด้านสิทธิ์การเข้าถึง | แตกต่างกันตามเครื่องมือ | มักผูกกับไลเซนส์แพลตฟอร์ม | แพ็กเกจแบบคิดตามที่นั่งผู้ใช้ที่ประกาศราคาไว้ แพ็กเกจ Process Individual และผู้ดูพอร์ทัลฟรี 10 คนต่อที่นั่ง Architecture หรือ Intelligence |
ชุดเครื่องมือ EA ที่เน้นคลังข้อมูล เช่น Software AG ARIS, Bizzdesign, MEGA HOPEX, Orbus iServer และ Sparx EA ออกแบบมาสำหรับคลังข้อมูลสถาปัตยกรรม กรอบการทำงาน การกำกับดูแล และการจัดการพอร์ตโฟลิโอ เหมาะกับองค์กรที่มีอำนาจหน้าที่และทรัพยากรสำหรับดำเนินโครงการสถาปัตยกรรมอย่างเป็นทางการ.
แพลตฟอร์มจัดการ EA เช่น SAP LeanIX ให้บริการในรูปแบบ SaaS สำหรับจัดทำรายการแอปพลิเคชันและความสามารถ เหมาะกับองค์กรที่ต้องการเห็นภาพรวมแอปพลิเคชันและมีแนวทางจัดการ enterprise architecture อย่างเป็นระบบ.
เครื่องมือวาดแผนภาพและ ArchiMateเหมาะกับกรณีที่คุณต้องการสร้างและแบ่งปันโมเดลเป็นหลัก Archi เป็นตัวเลือกฟรี แบบโอเพนซอร์ส และรองรับ ArchiMate โดยตรง ส่วนการใช้ Visio ก็ช่วยจัดทำเอกสารสถาปัตยกรรมได้เช่นกัน ควรตรวจสอบว่าคลังข้อมูล ฟีเจอร์การทำงานร่วมกัน และการกำกับดูแลตรงกับความต้องการของคุณหรือไม่.
โมดูล ITSM และแพลตฟอร์มอาจเหมาะเมื่อคุณต้องการให้มุมมองสถาปัตยกรรมอยู่ร่วมกับระบบที่ใช้อยู่แล้ว ตรวจสอบว่าความละเอียดในการสร้างโมเดลและฟังก์ชันคลังข้อมูลของโมดูลตรงกับแนวทางด้านสถาปัตยกรรมของคุณหรือไม่.
ProcessMindตอบคำถามอีกแบบหนึ่งว่า งานดำเนินไปอย่างไร และข้อมูลการปฏิบัติงานแสดงอะไรบ้าง แพลตฟอร์มเชื่อมสายธารคุณค่าและระดับกระบวนการเข้ากับข้อมูลเหตุการณ์ที่ระบบของคุณบันทึกอยู่แล้ว ทำให้ดูสถาปัตยกรรมลงไปถึงกิจกรรมที่ผู้คนทำ และตรวจสอบกับสิ่งที่เกิดขึ้นจริงได้.
ไม่มีเครื่องมือใดเหมาะที่สุดสำหรับทุกประเภท เลือกเครื่องมือให้ตรงกับงานที่คุณต้องทำก่อน หากสิ่งที่ต้องการรู้คือพฤติกรรมของกระบวนการ ให้เริ่มจากหลักฐานในระดับกระบวนการ แล้วค่อยเพิ่มคลังข้อมูลเมื่อโครงการสถาปัตยกรรมของคุณต้องใช้.
ทำไม enterprise architecture จึงไม่ตรงกับความเป็นจริง?
Enterprise architecture อาจค่อยๆ ไม่ตรงกับความเป็นจริง เมื่อคลังข้อมูลต้องอาศัยการอัปเดตด้วยมือ และโมเดลอยู่ห่างจากงานที่ต้องการอธิบาย.
ปัจจัยเชิงโครงสร้าง 3 ข้อทำให้เกิดปัญหานี้ได้ง่ายขึ้น:
- ผู้คนดูแลคลังข้อมูลด้วยมือ การเปลี่ยนแปลงกระบวนการ แอปพลิเคชัน และผู้รับผิดชอบต้องมีคนป้อนข้อมูลและตรวจทาน
- ประโยชน์อาจเกิดขึ้นภายหลัง ทีมอาจต้องใช้รายการข้อมูลที่ถูกต้องในการตรวจสอบหรือวิเคราะห์ผลกระทบในอนาคต ขณะที่งานอัปเดตต้องทำในตอนนี้
- โมเดลแสดงสิ่งที่ตั้งใจ ไม่ใช่พฤติกรรมจริง กระบวนการที่บันทึกไว้อาจไม่แสดงการทำงานซ้ำ เส้นทางยกเว้น การส่งต่องาน หรือเวลารอที่เกิดขึ้นในกรณีจริง.
แผนที่ความสามารถและรายการแอปพลิเคชันช่วยให้เข้าใจองค์กรในภาพรวมได้ดี แต่ผู้ที่ทำงานจริงอาจไม่เห็นวิธีทำงานประจำวันของตนในโมเดลที่แสดงเพียงระดับความสามารถหรือแอปพลิเคชัน.
ความแตกต่างมักเห็นได้จากรายละเอียด เช่น รูปแบบกระบวนการ การส่งต่องาน การอนุมัติซ้ำ และเวลาที่ใช้รอ คลังข้อมูลบันทึกกระบวนการที่ตั้งใจให้เป็นได้ แต่ต้องมีหลักฐานอีกแหล่งเพื่อดูว่าคำอธิบายนั้นยังตรงกับการทำงานจริงหรือไม่.
สถาปัตยกรรมที่ผู้คนไม่เห็นว่าเกี่ยวข้องกับงานจริงมักล้มเหลวได้สองแบบ ผู้คนอาจหาทางเลี่ยง เพราะโมเดลระบุว่าต้องอนุมัติครั้งเดียว แต่ทีมรู้ว่าต้องอนุมัติสามครั้ง จึงไม่มีใครกลับมาเปิดดูโมเดล หรือโมเดลอาจกลายเป็นเอกสารประกอบการปฏิบัติตามข้อกำหนดที่อัปเดตก่อนการตรวจสอบ แล้วถูกละเลยในช่วงอื่น ทั้งสองกรณีไม่ได้เกิดจากเครื่องมือ แต่เกิดจากช่องว่างระหว่างโมเดลกับงานจริง.
การกำกับดูแลที่ดีขึ้นช่วยให้ดูแลคลังข้อมูลได้ต่อเนื่อง แต่ไม่ได้ให้หลักฐานอิสระว่าโมเดลตรงกับสิ่งที่เกิดขึ้นจริง การเชื่อมโมเดลกระบวนการกับข้อมูลการปฏิบัติงานช่วยให้คุณตรวจสอบส่วนนี้ได้.
จะเชื่อมสถาปัตยกรรมเข้ากับงานที่ผู้คนทำได้อย่างไร?
รายละเอียดจากจุดที่งานเกิดขึ้นช่วยให้ทีมเห็นภาพสถาปัตยกรรมได้ชัดขึ้น และทำให้คุณมีข้อมูลสำหรับตรวจสอบกับข้อมูลการปฏิบัติงาน.
แผนที่ความสามารถอธิบายว่าองค์กรต้องทำอะไร ส่วนโมเดลกระบวนการแสดงได้ว่างานนั้นทำอย่างไร ใครรับผิดชอบ และกระบวนการย่อยเชื่อมโยงกันอย่างไร ยิ่งเชื่อมระดับต่างๆ ได้ชัดเจนเท่าไร การสลับดูระหว่างมุมมองสถาปัตยกรรมกับงานที่มุมมองนั้นแทนอยู่ก็ยิ่งง่ายขึ้น.
บันทึกเหตุการณ์เพิ่มหลักฐานเกี่ยวกับกรณีที่ดำเนินการเสร็จแล้ว โดยแสดงได้ว่ามีกิจกรรมใดเกิดขึ้น ตามลำดับใด และใช้เวลานานเท่าไร เมื่อนำหลักฐานนี้มาเปรียบเทียบกับโมเดลกระบวนการ คุณจะเห็นว่าพฤติกรรมที่เกิดขึ้นจริงต่างจากเส้นทางที่บันทึกไว้อย่างไร.
ไม่ได้หมายความว่าคุณจะสร้าง enterprise architecture ทุกส่วนจากข้อมูลเหตุการณ์ได้ การตัดสินใจเรื่องพอร์ตโฟลิโอ มาตรฐาน และสถานะเป้าหมายยังต้องอาศัยแนวทางด้านสถาปัตยกรรมและการกำกับดูแล ข้อมูลช่วยยืนยันสิ่งที่เกิดขึ้นในชั้นกระบวนการได้ แต่ใช้แทนคลังข้อมูลทั้งหมดไม่ได้.
รายละเอียดกระบวนการจากจุดที่งานเกิดขึ้นช่วยป้องกันปัญหาทั้งสองแบบ เมื่อสถาปัตยกรรมแสดงถึงกิจกรรม การส่งต่องาน และเวลารอ ทีมก็ชี้ให้เห็นงานของตนในโมเดลได้ และผู้รับผิดชอบก็เห็นว่าตนต้องตัดสินใจเรื่องใด เครื่องมือ EA ช่วยจัดเก็บพอร์ตโฟลิโอได้ แต่สิ่งที่เชื่อมพอร์ตโฟลิโอนั้นกับผู้คนที่ทำให้เกิดผลจริงก็คือตัวงาน.
หลักฐานช่วยให้ผู้ตรวจสอบยืนยันความเชื่อมโยงนี้ได้ เวลารอในโมเดลควรตรงกับเวลารอในบันทึกข้อมูล หากไม่ตรงกัน การพูดคุยก็จะมุ่งไปที่กระบวนการแทนที่จะถกกันเรื่องแผนภาพ ซึ่งเป็นประโยชน์กว่าการกลับไปแก้เอกสารอีกครั้ง.
แนวทางนี้ยังเปลี่ยนลำดับการทำงานด้วย แทนที่จะทำคลังข้อมูลให้เสร็จก่อนแล้วหวังว่ารายละเอียดจะตามมาทีหลัง ให้เริ่มวัดกระบวนการหนึ่งรายการ เชื่อมกับระดับที่อยู่เหนือขึ้นไป แล้วสร้างความน่าเชื่อถือให้โมเดลด้วยการตรวจสอบได้ จุดเริ่มต้นนี้มีขอบเขตเล็กพอที่จะทำให้เสร็จ และช่วยให้โครงการสถาปัตยกรรมมีตัวอย่างที่ใช้งานได้จริงแทนที่จะมีเพียงแผน.
ดูเอกสารสถาปัตยกรรมกระบวนการเพื่อทำความเข้าใจวิธีแสดงระดับกระบวนการและความสัมพันธ์ หากต้องการดูเรื่องข้อมูล อ่านวิธีสร้างบันทึกเหตุการณ์สำหรับ process mining.
การทำแผนที่สายธารคุณค่าเป็นแนวทางที่นำไปใช้ได้จริงสำหรับ TOGAF หรือไม่?
TOGAF กำหนดให้สถาปัตยกรรมธุรกิจมีทั้ง value stream และแผนผังขีดความสามารถ การทำแผนที่ value stream ช่วยสร้างองค์ประกอบส่วนนี้ โดยเริ่มจากทำแผนที่ value stream เชื่อมโยงกระบวนการที่รองรับอยู่ด้านล่าง แล้วตรวจสอบให้ภาพรวมสอดคล้องกับงานที่เกิดขึ้นจริงโดยใช้ข้อมูลที่วัดได้ เราเริ่มที่ value stream ในระดับ Process Architecture เพราะช่วยให้ผู้คนเห็นความเชื่อมโยงระหว่างสถาปัตยกรรมกับการสร้างคุณค่าภายในองค์กร การทำโครงการ TOGAF ให้ครบถ้วนยังต้องมีคณะกรรมการกำหนดมาตรฐานและปฏิทินกำกับดูแลควบคู่ไปด้วย แต่ตัวโมเดลเริ่มต้นจากจุดนี้
ทำไม ProcessMind จึงใช้แนวทางด้านสถาปัตยกรรมต่างออกไป?
ProcessMind เริ่มจากส่วนของสถาปัตยกรรมที่พิสูจน์ได้ด้วยข้อมูล นี่คือความแตกต่างของแนวทางโดยตั้งใจ ไม่ใช่การทำสิ่งที่คลังข้อมูลทำได้ในรูปแบบที่เล็กลง.
เราได้พิจารณา TOGAF แล้ว แต่การเชื่อมโยงแนวทางนี้กับข้อมูลจริงยังทำได้ยาก ในตอนนี้เราจึงเลือกโฟกัสเฉพาะส่วนที่วัดผลและพิสูจน์ได้ เพราะการปรับปรุงกระบวนการในส่วนเหล่านี้สร้างคุณค่าได้มากที่สุด.
การจัดการพอร์ตโฟลิโอ วงจรชีวิตแอปพลิเคชัน และการกำกับดูแลมาตรฐานเป็นงานหลักของคลังข้อมูล ซึ่ง ARIS, SAP LeanIX, Bizzdesign, MEGA HOPEX, Orbus และ Sparx ทำได้ดี ส่วนชั้นกระบวนการก็มีพื้นที่ของตัวเองที่นี่.
เรามุ่งเน้นชั้นกระบวนการ ได้แก่ สายธารคุณค่า ระดับกระบวนการที่กำหนดค่าได้ ผู้รับผิดชอบแบบ RACI เวิร์กโฟลว์การกำกับดูแล และพอร์ทัลสำหรับผู้ดู โดยเชื่อมโยงกับข้อมูลเหตุการณ์ ชั้นนี้ใช้ตอบคำถามเกี่ยวกับกระบวนการได้ด้วยตัวเอง และยังทำงานร่วมกับคลังข้อมูลได้เมื่อโครงการสถาปัตยกรรมต้องการ.
ควรเลือกเครื่องมือ enterprise architecture อย่างไร?
เลือกจากคำถามที่ทีมต้องการคำตอบ และงานด้านสถาปัตยกรรมที่คุณต้องกำกับดูแล.
- **คุณต้องจัดการพอร์ตโฟลิโอ มาตรฐาน และแผนงาน:**คัดเลือกชุดเครื่องมือ EA แบบเต็มรูปแบบ และวางแผนจัดหาบุคลากรกับกระบวนการที่จำเป็นต่อการดูแลคลังข้อมูล
- **คุณต้องการรายการแอปพลิเคชันและความสามารถในรูปแบบ SaaS:**ประเมินแพลตฟอร์มจัดการ EA เช่น SAP LeanIX ให้ตรงกับความต้องการด้านรายการข้อมูลและการกำกับดูแล
- **คุณต้องการคำตอบเกี่ยวกับพฤติกรรมของกระบวนการ:**เริ่มจากโมเดลกระบวนการและข้อมูลการปฏิบัติงาน แล้วค่อยตัดสินใจว่าต้องใช้คลังข้อมูลที่มีขอบเขตกว้างขึ้นด้วยหรือไม่
- **คุณยังตัดสินใจไม่ได้:**ระบุคำถามที่ทีมถามบ่อยที่สุด วิธีนี้จะช่วยให้คุณเลือกได้ว่าจะเริ่มจากคลังข้อมูล หลักฐานกระบวนการ หรือทั้งสองอย่าง.
หากกำลังเปรียบเทียบเครื่องมือที่เน้นคลังข้อมูล โปรดอ่านการเปรียบเทียบทางเลือกแทน ARIS หากกำลังประเมินว่าโมเดลกับข้อมูลทำงานร่วมกันอย่างไร โปรดอ่านวิธีที่การสร้างแบบจำลองกระบวนการและ process mining ช่วยเสริมกัน.
เริ่มจากจุดที่คุณหาหลักฐานได้ แล้วเพิ่มคลังข้อมูลเมื่อโครงการสถาปัตยกรรมต้องใช้ความสามารถด้านการกำกับดูแลและการจัดการพอร์ตโฟลิโอในวงกว้าง.
ProcessMind เหมาะกับงานส่วนไหน?
ProcessMind เป็นชั้นสำหรับกระบวนการและสายธารคุณค่า ที่เชื่อมสถาปัตยกรรมเข้ากับหลักฐานว่าการทำงานดำเนินไปอย่างไร.
คลังข้อมูลใช้จัดเก็บพอร์ตโฟลิโอและมาตรฐาน ส่วน ProcessMind ใช้จัดการชั้นกระบวนการและหลักฐานที่เกี่ยวข้อง องค์กรที่ใช้ทั้งสองอย่างจะตรวจสอบรายละเอียดกระบวนการในสถาปัตยกรรมได้ ส่วนองค์กรที่ต้องการเพียงชั้นกระบวนการก็ใช้ ProcessMind ได้โดยไม่ต้องมีคลังข้อมูล.
คุณจัดกระบวนการเป็นระดับต่างๆ ที่กำหนดค่าได้ สร้างแบบจำลองด้วย BPMN 2.0 กำหนดผู้รับผิดชอบแบบ RACI และใช้เวิร์กโฟลว์การกำกับดูแลกับพอร์ทัลสำหรับผู้ดูได้ นอกจากนี้ยังเชื่อมโมเดลกระบวนการกับข้อมูลเหตุการณ์เพื่อเปรียบเทียบกระบวนการที่บันทึกไว้กับพฤติกรรมที่สังเกตได้ การจำลองกระบวนการช่วยให้คุณทดลองการเปลี่ยนแปลงในโมเดลก่อนนำไปปรับใช้กับกระบวนการจริง.
ดูรายละเอียดความสามารถด้านสถาปัตยกรรมกระบวนการของผลิตภัณฑ์ได้ที่หน้า enterprise process architecture และอ่านเพิ่มเติมเกี่ยวกับการกำกับดูแลกระบวนการและprocess mining คืออะไร.
Where to Go From Here
คุณต้องการสถาปัตยกรรมกระบวนการที่ลงรายละเอียดถึงระดับที่ทีมทำงาน และตรวจสอบกับข้อมูลการปฏิบัติงานได้.
