DIGITAL UNIVERSITY · ARTICLE

เมื่อพูดถึงระบบบริหารการศึกษา เรามักเริ่มจากคำถามว่า “ระบบนี้มี Feature อะไรบ้าง?” แต่คำถามที่สำคัญกว่าอาจเป็น “อะไรควรเป็นมาตรฐานร่วม และอะไรควรปล่อยให้มหาวิทยาลัยกำหนดเอง?”

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

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

โจทย์จึงไม่ใช่การเลือกระหว่าง Standardization หรือ Flexibility แต่คือการออกแบบให้ทั้งสองอย่างอยู่ร่วมกันได้

ไม่ใช่ทุกอย่างควร Customize และไม่ใช่ทุกอย่างควร Standardize

ระบบบริหารการศึกษามีบางส่วนที่ควรใช้โครงสร้างร่วมกัน เพราะเป็นกระบวนการพื้นฐานที่เกิดขึ้นในแทบทุกสถาบัน เช่น:

• การจัดการข้อมูลผู้เรียน
• การจัดโครงสร้างหลักสูตรและรายวิชา
• การรับสมัครและลงทะเบียน
• การประเมินผลการศึกษา
• การจัดการเอกสารทางการศึกษา
• การชำระเงินและค่าธรรมเนียม

การมีโครงสร้างกลางช่วยให้ระบบทำงานเป็นมาตรฐาน ดูแลต่อได้ง่าย และลดการสร้างกระบวนการใหม่ซ้ำๆ ในทุกโครงการ แต่ขณะเดียวกัน รายละเอียดภายในกระบวนการเหล่านี้อาจต่างกันอย่างมาก

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

จาก Customization ไปสู่ Configuration

ในอดีต เมื่อสถาบันมี Requirement เฉพาะ วิธีแก้ที่พบได้บ่อยคือการ Customize ระบบเพิ่มเติม แต่เมื่อจำนวน Requirement เพิ่มขึ้น การ Customize แบบเฉพาะรายอาจทำให้ระบบมีหลาย Version และดูแลรักษายากขึ้นในระยะยาว

แทนที่จะเขียนระบบใหม่ทุกครั้งที่กฎเปลี่ยน Platform สามารถเปิดให้ผู้ดูแลกำหนด Rule หรือ Condition บางอย่างได้ผ่าน Configuration ตัวอย่างเช่น:

• เกณฑ์การประเมินผล
• ลำดับขั้นตอนอนุมัติ
• รูปแบบเอกสาร
• เงื่อนไขค่าธรรมเนียม
• ข้อกำหนดของแต่ละหลักสูตร

แนวทางนี้ช่วยให้มหาวิทยาลัยยังรักษาวิธีการทำงานของตัวเองไว้ได้ ขณะที่ Platform ยังมีโครงสร้างกลางที่สามารถพัฒนาและดูแลต่อได้

Adaptability ไม่ได้แปลว่า “ปรับได้ทุกอย่าง”

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

เพราะหากทุกส่วนของระบบสามารถเปลี่ยนได้ทั้งหมด สุดท้ายอาจกลับไปสู่ปัญหาเดิม คือแต่ละมหาวิทยาลัยมีระบบเฉพาะของตัวเองมากจนไม่สามารถ Upgrade หรือพัฒนาร่วมกันได้

แล้ว u-next วางบทบาทตัวเองไว้ตรงไหน?

แนวคิดของ u-next คือการสร้าง Platform ที่มี Core Process สำหรับงานบริหารการศึกษา พร้อมรองรับกฎและเงื่อนไขเฉพาะของแต่ละสถาบัน จึงไม่ใช่การเริ่มระบบใหม่ทุกครั้งที่มีมหาวิทยาลัยใหม่ และไม่ใช่การบังคับให้ทุกมหาวิทยาลัยใช้ Process เดียวกันทั้งหมด แต่เป็นการมี Platform Foundation ร่วม แล้วเปิดพื้นที่ให้แต่ละสถาบัน Configure สิ่งที่จำเป็นตามบริบทของตัวเอง

แนวคิดนี้ทำให้ Core Value ของ u-next เชื่อมกันอย่างเป็นเหตุเป็นผล — กดเพื่อดูรายละเอียด

สิ่งที่มหาวิทยาลัยควรถาม ก่อนเลือกระบบใหม่

ก่อนพิจารณาว่าระบบหนึ่งมี Feature ครบหรือไม่ อาจลองถามคำถามเพิ่มเติมว่า:

• ถ้ากฎการศึกษาของมหาวิทยาลัยเปลี่ยน ระบบปรับตามได้แค่ไหน?
• ถ้า Approval Flow ของแต่ละคณะไม่เหมือนกัน ต้องแก้ Code ทุกครั้งหรือไม่?
• ถ้ามี Requirement ใหม่ ระบบสามารถ Configure เพิ่มได้หรือจำเป็นต้องทำ Custom Project?
• เมื่อ Upgrade ระบบ ส่วนที่ Customize ไว้จะได้รับผลกระทบหรือไม่?
• หากต้องเชื่อมระบบอื่นในอนาคต Architecture รองรับหรือไม่?

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

ระบบที่ดี ไม่ควรทำให้ทุกมหาวิทยาลัยเหมือนกัน

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

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

นี่คือหนึ่งในแนวคิดสำคัญของการออกแบบ Platform สำหรับมหาวิทยาลัยที่ต้องพร้อมรับการเปลี่ยนแปลงในระยะยาว