Hummix ไม่เปิดราคาตัวเลข ทีมไทยต้องขอใบเสนอราคาก่อนเทียบต้นทุน

Hummix แสดงแพ็กเกจ Standard สำหรับผู้ใช้สูงสุด 200 ราย และ Enterprise สำหรับมากกว่า 200 ราย แต่ระบุให้ขอใบเสนอราคาทั้งคู่แทนการแสดงค่าบริการเป็นตัวเลข Standard มีรูปแบบ SaaS ส่วน Enterprise มีทางเลือก SaaS, On-Premises และ Private Cloud จึงยังนำข้อมูลบนหน้าเว็บมาคำนวณยอดจ่ายไม่ได้

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

แยกคนที่มีบัญชีออกจากคนที่ใช้งานพร้อมกัน

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

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

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

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

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

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

ปริมาณเอกสารและงานเชื่อมต่อกำหนดขอบเขตมากกว่าชื่อโมดูล

Hummix อธิบายว่าแพลตฟอร์มผสาน AI, Low-Code, Workflow Automation, Data และ Integration พร้อมการกำหนดสิทธิ์ตามโครงสร้างองค์กรในข้อมูลการเปิดตัวแพลตฟอร์ม ความสามารถที่ระบุเป็นกรอบสำหรับเลือกงานที่จะนำขึ้นระบบ แต่ไม่ได้ระบุว่าการออกแบบทุกกระบวนการ การประมวลผล AI หรือการเชื่อมระบบทุกชุดรวมอยู่ในค่าบริการเดียว

สำหรับงานเอกสาร หน้าDocument-Centric BPM ของ Hummix ระบุการจัดเก็บเอกสารพร้อมสิทธิ์เข้าถึงและประวัติกิจกรรม การอนุมัติที่รองรับผู้ปฏิบัติงานแทน การดึงข้อมูลจากเอกสารด้วย AI และการเชื่อมต่อ API รายการเหล่านี้ทำให้คำว่า “ใช้ระบบเอกสาร” กว้างเกินกว่าจะตีราคาได้ เพราะงานจัดเก็บ งานออกแบบลำดับอนุมัติ และงานสกัดข้อมูลมีขอบเขตต่างกัน

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

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

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

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

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

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

รูปแบบติดตั้งเปลี่ยนต้นทุนและผู้รับผิดชอบ

ตัวเลือก SaaS, On-Premises และ Private Cloud บอกตำแหน่งและแนวทางจัดสภาพแวดล้อมในระดับกว้าง แต่ไม่บอกรายละเอียดว่าใครจ่ายทรัพยากรประมวลผล ใครสำรองข้อมูล และใครติดตั้งการอัปเดต ทีมที่ขอราคา Enterprise จึงควรส่งกรณีใช้งานและจำนวนผู้ใช้ชุดเดียวกันให้ผู้ขายตีราคาทุกทางเลือกที่ต้องการพิจารณา

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

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

Private Cloud ต้องระบุให้ชัดว่าเป็นสภาพแวดล้อมของฝ่ายใด ใครเป็นผู้ทำสัญญากับผู้ให้บริการโครงสร้างพื้นฐาน และค่าใช้ทรัพยากรปรากฏในใบเสนอราคาของ Hummix หรือเรียกเก็บแยก ผู้ขายอาจรับดูแลซอฟต์แวร์ ขณะที่องค์กรรับค่าโครงสร้างพื้นฐาน หรือจัดขอบเขตความรับผิดชอบอีกแบบหนึ่งได้ จึงควรตัดสินจากรายละเอียดข้อเสนอแทนชื่อรูปแบบติดตั้งเพียงคำเดียว

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

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

การเปรียบเทียบควรกำหนดระยะสัญญาและขอบเขตเดียวกันก่อนรวมยอด จากนั้นแยกเงินที่จ่ายให้ผู้ขายออกจากทรัพยากรที่องค์กรจัดหาเอง วิธีนี้ทำให้ค่า On-Premises หรือ Private Cloud ที่อยู่นอกใบเสนอราคาไม่หายไปจากการประเมิน

สามขนาดการใช้งานบอกทางเลือกได้ แต่ยังบอกยอดจ่ายไม่ได้

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

• ทีมขนาดเล็ก: สมมติผู้ต้องมีบัญชี 60 ราย และใช้งานพร้อมกันสูงสุด 20 ราย ใช้กระบวนการอนุมัติหนึ่งงานบน SaaS จำนวนบัญชีอยู่ในขอบเขต Standard ส่วนการใช้งานพร้อมกันคิดเป็นหนึ่งในสามของจำนวนบัญชี ผลที่คำนวณได้คือควรขอข้อเสนอเปรียบเทียบสิทธิ์ 60 Named User กับความจุ 20 Concurrent User ภายใต้กระบวนการเดียวกัน ยอดจ่ายหนึ่งปียังระบุไม่ได้
• องค์กรขนาดกลาง: สมมติผู้ต้องมีบัญชี 180 ราย และใช้งานพร้อมกันสูงสุด 45 ราย มีหลายฝ่ายอนุมัติและเชื่อมระบบเดิมหนึ่งชุด จำนวนบัญชียังอยู่ในขอบเขต Standard ขณะที่จำนวนผู้ใช้พร้อมกันเท่ากับหนึ่งในสี่ของจำนวนบัญชี ควรขอราคาสำหรับสิทธิ์ทั้งสองแบบพร้อมแยกค่าเชื่อมต่อ หากต้องติดตั้งนอก SaaS ต้องขอข้อเสนอ Enterprise สำหรับงานชุดเดียวกัน ส่วนต่างราคายังหาไม่ได้
• องค์กรขนาดใหญ่: สมมติผู้ต้องมีบัญชี 360 ราย และใช้งานพร้อมกันสูงสุด 120 ราย พร้อมงานเอกสารหลายประเภท จำนวนบัญชีเกินขอบเขต Standard จึงต้องขอข้อเสนอ Enterprise ผู้ใช้พร้อมกันเท่ากับหนึ่งในสามของบัญชีทั้งหมด แต่ยังสรุปไม่ได้ว่าควรซื้อความจุ 120 สิทธิ์หรือใช้เกณฑ์นับอีกแบบ ต้องให้ผู้ขายยืนยันเงื่อนไข Concurrent User และตีราคา SaaS, On-Premises หรือ Private Cloud ตามขอบเขตเดียวกัน

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

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

แบบฟอร์มขอบเขตที่ทำให้ใบเสนอราคาเทียบกันได้

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

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

เมื่อได้รับข้อเสนอ ให้รวมต้นทุนเฉพาะรายการที่มีราคาและแสดงรายการที่ยังไม่รวมไว้ข้างยอดนั้นอย่างชัดเจน ข้อเสนอที่ราคาต่ำกว่าแต่เว้นงานย้ายข้อมูล การเชื่อมต่อ หรือการดูแลโครงสร้างพื้นฐานไว้ ยังสรุปว่าประหยัดกว่าไม่ได้จนกว่าทุกฝ่ายจะตีราคางานชุดเดียวกัน