การกำหนดขีดจำกัดขนาดของการอัปโหลด PDF มีต้นทุนที่แท้จริง และเป็นหนึ่งในตัวเลขที่ถูกอ้างอิงเกินจริงที่สุดในซอฟต์แวร์ระดับองค์กร ดังนั้นบทความนี้จึงให้วิธีการวัดค่าของคุณเองแทนตัวเลขที่ถูกสร้างขึ้นให้คุณ
บทนำ
ระบบจัดการเอกสารแบบดั้งเดิมมักบังคับขีดจำกัดที่แน่นอน 25 เมกะไบต์ สำหรับการอัปโหลด PDF การจำกัดนี้ดูเหมือนจะไม่มีอันตราย — เอกสารส่วนใหญ่อยู่ต่ำกว่ามัน — จนกระทั่งไฟล์หนึ่งไม่เป็นเช่นนั้นและต้องมีคนทำอะไรบางอย่างด้วยตนเอง
เราควรพูดตรง ๆ เกี่ยวกับตำแหน่งของเราในที่นี้ เพราะมันจะดูแปลกถ้าไม่ทำ: ตัวดูฟรีที่ Doconut.app ก็หยุดที่ 25 MB สำหรับ PDF ด้วย นั่นคือขีดจำกัดของเรา และบทความนี้ไม่ได้โต้แย้งว่าขีดจำกัดเป็นสิ่งที่ไม่สามารถปกป้องได้ แต่เป็นการโต้แย้งว่าคุณควรรู้ว่าขีดจำกัดของคุณมีค่าใช้จ่ายเท่าไหร่ก่อนที่คุณจะจ่ายเพื่อขยับมัน
หมายเหตุเกี่ยวกับตัวเลขในบทความนี้ หรือพูดถึงการไม่มีตัวเลขนั้น โมเดลต้นทุนในประเภทนี้มักอิงกับการสำรวจที่ไม่มีใครสามารถตรวจสอบได้และเกณฑ์อ้างอิงที่ไม่มีใครสามารถหาแหล่งได้ เราไม่มีข้อมูลเหล่านั้น ดังนั้นเราจะไม่พิมพ์อะไรออกมา สิ่งที่ตามมาคือการคำนวณและคำถาม — คุณจะต้องใส่ค่าจากระบบของคุณเองที่เป็นจริง
1. ค่าใช้จ่ายที่เกิดจากการอัปโหลดที่ถูกปฏิเสธจริง ๆ
เมื่อ PDF เกินขีดจำกัด ใครสักคนจะต้องแยก, บีบอัด หรือสร้างใหม่ นั่นคือค่าใช้จ่ายโดยตรงและมีสามส่วนที่คุณสามารถวัดได้:
ปริมาณ จำนวนการอัปโหลดที่ถูกปฏิเสธเนื่องจากขนาด? บันทึกการทำงานของแอปพลิเคชันของคุณจะรู้ หากบันทึกสาเหตุการปฏิเสธไม่ได้ นั่นคือสิ่งแรกที่ต้องแก้ไข เพราะทุกอย่างต่อจากนี้ขึ้นอยู่กับตัวเลขนี้และการประมาณของใคร ๆ ก็ไม่มีประโยชน์
เวลาในการจัดการ เวลาที่ใช้ในการแก้ปัญหาเท่าไหร่? วัดโดยใช้ไฟล์จริงห้าชิ้นแทนการคาดเดา การบีบอัดสัญญาที่สแกนใน Acrobat แล้วอัปโหลดใหม่ไม่เท่ากับการแยกคู่มือ 400 หน้าเป็นส่วน ๆ ที่แต่ละส่วนสามารถทำงานได้เอง
อัตราตั๋ว สัดส่วนของการปฏิเสธที่กลายเป็นตั๋วสนับสนุนแทนที่จะถูกแก้ที่โต๊ะทำงานคือเท่าไหร่? ดึงข้อมูลจากระบบตั๋วของคุณโดยใช้คำค้นหา
การคำนวณจึงเป็นดังนี้:
rejections per quarter
x handling time in hours
x blended hourly rate
+ (rejections x ticket rate x cost per ticket)
= direct quarterly cost
เหตุผลที่คุณควรทำเองคือผลลัพธ์จะแตกต่างกันมากกว่าหนึ่งลำดับขนาดระหว่างองค์กรต่าง ๆ เนื่องจากส่วนใหญ่ขึ้นกับปริมาณ สำหรับทีมที่ถึงขีดจำกัดสองครั้งต่อเดือน คำตอบที่ซื่อสัตย์คือค่าใช้จ่ายนี้ไม่มีความสำคัญและคุณควรหยุดอ่าน สำหรับแผนกเคลมที่ประมวลผลไฟล์สแกนตลอดวัน มันเป็นรายการค่าใช้จ่ายที่แท้จริง
2. ค่าใช้จ่ายทางอ้อมที่ควรให้ความสำคัญ
ความล่าช้าและการสูญเสียโอกาสเป็นส่วนที่สองตามปกติ และเราจะข้ามการโมเดลรายได้ เพราะการอ้างอิงการสูญเสียการขายต่อข้อจำกัดการอัปโหลดต้องอาศัยหลักฐานที่แทบไม่มีใครมี
ค่าใช้จ่ายทางอ้อมหนึ่งที่ควรตั้งชื่อคือ เพราะมันแตกต่างเชิงคุณภาพ: การแยกเอกสารทำให้เอกสารเสียหาย
PDF ที่แยกเป็นสามส่วนคือสามไฟล์ที่สามารถส่งแยกกัน, มีเวอร์ชันแยกกันและถูกเก็บไม่ครบถ้วน ลายเซ็นไม่คงอยู่หลังการดำเนินการ — PDF ที่มีลายเซ็นดิจิทัลแล้วถูกแยกจะมีลายเซ็นที่ไม่ถูกต้องในทุกส่วน เพราะลายเซ็นครอบคลุมไบต์ของไฟล์ทั้งหมด เมตาดาต้า, แท็กและโครงสร้างที่ทำให้ PDF/A สามารถเก็บถาวรได้จะถูกเก็บไม่สม่ำเสมอโดยเครื่องมือใดก็ตามที่ผู้ใช้เลือกใช้
หากข้อผูกมัดการเก็บรักษาหรือการตรวจสอบของคุณสมมติว่าเอกสารเป็นวัตถุเดียว ขีดจำกัดขนาดที่บังคับให้ต้องแยกบ่อย ๆ จะกลายเป็นปัญหาการปฏิบัติตามที่สวมใส่ชุดผลิตภาพ นั่นคุ้มค่าที่จะยกระดับโดยไม่คำนึงว่าการคำนวณแรงงานจะบอกว่าอย่างไร
3. ก่อนที่คุณจะซื้ออะไร ตรวจสอบสิ่งที่อยู่ในไฟล์
ขั้นตอนนี้มักถูกข้ามจนถึงจุดที่ควรมีส่วนของมันเอง เพราะบางครั้งมันทำให้โครงการหยุดลง
นำไฟล์ที่ถูกปฏิเสธจำนวนห้าสิบไฟล์มาดูว่าทำไมมันถึงใหญ่ ในประสบการณ์ของเรากับรูปแบบไฟล์ คำตอบส่วนใหญ่คือรูปภาพที่ยังคงความละเอียดดั้งเดิม: สัญญาที่สแกนที่ 600 dpi ในสีเมื่อ 200 dpi ขาว‑ดำก็พออ่านได้, หรือรายงานที่ภาพถ่ายถูกใส่ตรงจากโทรศัพท์ PDF แบบนี้มักใหญ่กว่าที่ต้องการหลายเท่า และการแก้ที่ต้นทาง — โปรไฟล์สแกนเนอร์, การตั้งค่าการส่งออก — จะลบการปฏิเสธออกโดยไม่ต้องมีการจัดซื้อใด ๆ
บางครั้งคำตอบคือเอกสารขนาดใหญ่จริง ๆ และนั่นคือความต้องการที่แท้จริง จุดสำคัญคือการรู้ว่าคุณอยู่ในกรณีใด
4. คำถามที่ควรถามผู้ขาย รวมถึงเรา
หากคุณต้องการยกขีดจำกัด คำถามที่สำคัญไม่ได้เกี่ยวกับขีดจำกัดเอง:
- ขีดจำกัดถูกบังคับที่ไหนและทำไม? ขีดจำกัดที่ตั้งโดยการจัดการอัปโหลดของแอปพลิเคชันต่างจากที่บังคับโดยเครื่องยนต์การแสดงผลของเราเป็นแบบแรก: 25 MB คือสิ่งที่เว็บไซต์สาธารณะของเรายอมรับ ไม่ใช่สิ่งที่เครื่องยนต์สามารถวาดได้
- เกิดอะไรขึ้นเมื่อถึงขีดจำกัด? การปฏิเสธที่อัปโหลดพร้อมระบุตัวเลขนั้นอ่อนโยนกว่าการหมดเวลาเมื่อ 90 % — ผู้ใช้จะได้เรียนรู้อะไรบางอย่างไม่ว่าอย่างไร แต่เพียงหนึ่งในนั้นที่เร็ว
- กราฟหน่วยความจำเป็นอย่างไร? การแสดงผล PDF ขนาดใหญ่ต้องใช้หน่วยความจำของเซิร์ฟเวอร์ หากคุณโฮสต์ด้วยตนเอง ค่าใช้จ่ายนั้นย้ายไปยังโครงสร้างพื้นฐานของคุณและ “ไม่มีขีดจำกัด” หมายถึง “จำกัดโดยฮาร์ดแวร์ที่คุณกำลังซื้ออยู่”
- อะไรบ้างที่ถูกเก็บไว้? หากคุณยกขีดจำกัดเพื่อหยุดการแยกไฟล์ ให้ยืนยันว่าเอกสารยังคงอยู่ครบถ้วน — รวมถึงลายเซ็น, แท็กและเมตาดาต้า
เพื่อเป็นข้อมูลบันทึก บทความนี้ไม่มีตัวเลขที่เราไม่สามารถยืนหยัดได้: Doconut SDK เป็นคอมโพเนนต์ .NET ที่คุณติดตั้งในสภาพแวดล้อมของคุณเอง ซึ่งขีดจำกัดขนาดที่ใช้งานได้จริงคือหน่วยความจำของเซิร์ฟเวอร์ของคุณ ไม่ใช่นโยบายของเรา เราจะไม่พิมพ์ตัวเลขเมกะไบต์สำหรับมัน เพราะมันขึ้นกับฮาร์ดแวร์และเอกสารของคุณ และตัวเลขใด ๆ เพียงหนึ่งเดียวก็จะเป็นการตลาดมากกว่าการวัดผล
5. ขั้นตอนที่ทำได้จริง
- บันทึกการปฏิเสธ บันทึกสาเหตุและขนาดไฟล์ ไตรมาสหนึ่งของข้อมูลจริงดีกว่าโมเดลใด ๆ
- สุ่มตรวจไฟล์ PDF ที่ถูกปฏิเสธห้าสิบไฟล์จะบอกคุณว่าคุณมีปัญหาขนาดหรือปัญหาการตั้งค่าสแกนเนอร์
- รันการคำนวณข้างต้น ด้วยปริมาณและอัตราของคุณเอง และพร้อมสรุปว่าค่าใช้จ่ายนั้นเล็กเกินกว่าจะดำเนินการ
- ตรวจมุมการปฏิบัติตามแยกต่างหาก หากการแยกทำลายลายเซ็นหรือร่องรอยการตรวจสอบ การโต้แย้งนั้นยืนหยัดด้วยตัวเองและไม่ต้องการโมเดลต้นทุนสนับสนุน
- ทดลองกับไฟล์ที่แย่ที่สุดของคุณ ไม่ใช่ตัวอย่าง แต่ชุดสแกน 300 หน้า ที่เริ่มต้นการสนทนา
สรุป
ขีดจำกัดขนาดเป็นข้อจำกัดที่แท้จริงพร้อมต้นทุนที่แท้จริง และมันยังเป็นจุดที่ง่ายที่สุดในซอฟต์แวร์ระดับองค์กรที่จะถูกขายเป็นตัวเลข ค่าใช้จ่ายคือสิ่งที่ปริมาณ, เวลาในการจัดการและอัตราของคุณกำหนด — ซึ่งอาจเป็นจำนวนที่สำคัญ หรืออาจเป็นศูนย์
วัดมันก่อนที่คุณจะขยับมัน และหากคุณมี PDF เพียงไฟล์เดียวที่ใหญ่เกินไปที่จะอ่านวันนี้, Doconut.app รองรับ 25 MB, ไม่เสียค่าใช้จ่าย, และลบไฟล์เมื่อคุณปิดแท็บ
กำลังพิจารณาว่า SDK เหมาะกับคุณหรือไม่? หน้า หน้าดาวน์โหลด มีรุ่นทดลอง, และการทดสอบกับเอกสารที่หนักที่สุดของคุณจะบอกคุณมากกว่าตัวคำนวณใด ๆ.
