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

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

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

ทำไมคำถามเกี่ยวกับการบูรณาการจึงควรอยู่ในขั้นตอนการจัดซื้อ

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

นี่คือเหตุผลที่ควรปฏิบัติต่อการทำงานร่วมกันได้เป็นส่วนหนึ่งของการวางแผนโครงสร้างพื้นฐาน แทนที่จะเป็นงานหลังการติดตั้ง ผู้ซื้อที่กำลังดูเครือข่ายการชาร์จแบบเปิด OCPP OCPI การโรมมิ่ง และแนวโน้มการทำงานร่วมกันของเครื่องชาร์จ EV มักจะกำลังถามคำถามแรกที่ถูกต้อง: ระบบนี้ยังคงเปิดกว้างแค่ไหนเมื่อไซต์ทำงานอยู่แล้ว

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

เริ่มต้นด้วยการกำหนดว่าการเข้าถึง API หมายถึงอะไรจริงๆ

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

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

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

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

ถามว่าการบูรณาการของบุคคลที่สามใดที่ได้รับการพิสูจน์แล้ว

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

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

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

อย่าสับสนระหว่างการรองรับโปรโตคอลกับการบูรณาการทางธุรกิจอย่างสมบูรณ์

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

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

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

ชี้แจงขอบเขตการบูรณาการที่แท้จริงก่อนลงนามในสัญญา

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

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

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

ปฏิบัติต่อสิทธิ์ในการเป็นเจ้าของข้อมูลและการส่งออกข้อมูลเป็นประเด็นในการจัดซื้อ

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

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

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

ตรวจสอบความน่าเชื่อถือ ไม่ใช่แค่ความพร้อมใช้งานของเลเยอร์ API

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

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

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

ถามว่าการบูรณาการส่งผลต่อการย้ายและการขยายขนาดในอนาคตอย่างไร

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

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

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

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

ความปลอดภัยและการอนุญาตควรใช้งานได้จริง

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

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

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

คะแนนที่ใช้ได้จริงสำหรับผู้ซื้อเชิงพาณิชย์

คำถามของผู้ซื้อ	เหตุใดจึงสำคัญ	คำตอบที่แข็งแกร่งกว่ามีลักษณะอย่างไร
API เปิดเผยข้อมูลและการดำเนินการควบคุมใดบ้าง?	ยืนยันว่าการบูรณาการสามารถรองรับเวิร์กโฟลว์การปฏิบัติงานจริงได้หรือไม่	จุดสิ้นสุดที่มีเอกสารประกอบสำหรับข้อมูลการดำเนินงาน พร้อมขอบเขตการควบคุมที่กำหนดไว้อย่างชัดเจน
การบูรณาการของบุคคลที่สามใดที่ผ่านการพิสูจน์แล้วในการผลิต?	แยกความเข้ากันได้จริงออกจากความเข้ากันได้ในทางทฤษฎี	ระบบที่มีชื่อ, การใช้งานที่มีอยู่, และความเป็นเจ้าของการสนับสนุนที่ชัดเจน
มีการเข้าถึงแซนด์บ็อกซ์และเอกสารประกอบที่มีเวอร์ชันหรือไม่?	ลดความเสี่ยงในการปรับใช้และบำรุงรักษา	เอกสารนักพัฒนา, ข้อมูลประจำตัวทดสอบ, หมายเหตุประกอบการเผยแพร่, และนโยบายการเลิกใช้
ใครเป็นเจ้าของความล้มเหลวในระบบเครื่องชาร์จ, แบ็กเอนด์, และระบบของบุคคลที่สาม?	ป้องกันช่องว่างการตำหนิระหว่างเหตุการณ์	เมทริกซ์ความรับผิดชอบที่ชัดเจนและเส้นทางการยกระดับ
ข้อมูลใดที่สามารถส่งออกได้, ในรูปแบบใด, และตามกำหนดการใด?	ปกป้องการวิเคราะห์, การปฏิบัติตามข้อกำหนด, และตัวเลือกการย้ายในอนาคต	การเข้าถึงการส่งออกที่มีโครงสร้างสำหรับเซสชัน, การแจ้งเตือน, การกำหนดค่า, และประวัติ
การเปลี่ยนแปลง API ได้รับการสื่อสารและทดสอบอย่างไร?	รักษาความต่อเนื่องทางธุรกิจเมื่อระบบพัฒนา	การแจ้งล่วงหน้า, ระเบียบวินัยในการรักษาความเข้ากันได้ย้อนหลัง, และกระบวนการย้อนกลับ
มีการจำกัดอัตรา, การลองเว็บฮุคซ้ำ, หรือข้อผูกมัดเวลาทำงานของ API หรือไม่?	ทดสอบว่าการบูรณาการแข็งแกร่งพอสำหรับการขยายขนาดหรือไม่	พารามิเตอร์การทำงานที่โปร่งใสและการสนับสนุนสำหรับการใช้งานในการผลิต
การบูรณาการใดที่เป็นแบบดั้งเดิมและแบบใดที่ต้องใช้มิดเดิลแวร์ที่กำหนดเอง?	ชี้แจงต้นทุนรวมและความซับซ้อนของโครงการ	การแยกส่วนอย่างตรงไปตรงมาระหว่างตัวเชื่อมต่อมาตรฐานและความพยายามในการใช้งานที่กำหนดเอง

เมื่อใดที่ความเปิดกว้างของ API ที่ลึกขึ้นมีความสำคัญที่สุด

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

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

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

สรุปเชิงปฏิบัติ

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

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

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