ข้ามไปยังเนื้อหาหลัก
FromNine
เมนู

วิศวกรรม

ซอฟต์แวร์องค์กรที่ทีมของคุณเองปรับเปลี่ยนต่อได้

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

สำหรับบริษัทผลิตภัณฑ์ซอฟต์แวร์และองค์กรที่ให้บริการผู้ใช้งานในหลายประเทศ หลายภาษา และภายใต้กฎหมายหลายระบบ

ปรึกษาโครงการของคุณดูโซลูชันปรับปรุงระบบเดิม
ซอฟต์แวร์องค์กรและ SaaS: ชั้นความสามารถสี่ชั้นเรียงซ้อนกัน จากบนลงล่าง ได้แก่ หน้าจอที่ทุกคนเข้าถึงได้ซึ่งผู้ใช้งานใช้ทำงาน โมดูลตามโดเมนที่เก็บกฎทางธุรกิจ บริการแพลตฟอร์มด้านผู้เช่าและการยืนยันตัวตน และไปป์ไลน์การส่งมอบที่ปลอดภัยอยู่เบื้องล่าง01หน้าจอที่ทุกคนเข้าถึงได้02โมดูลตามโดเมนและกฎ03ผู้เช่า ตัวตน ข้อมูล04ไปป์ไลน์ส่งมอบที่ปลอดภัย
  1. 01Domain-driven design สำหรับงานที่มีกฎซับซ้อน เช่น งานพิจารณาคำขอ
  2. 02การเข้าถึงได้ตาม EN 301 549 และ WCAG 2.2 ระดับ AA ตั้งแต่การออกแบบแรก
  3. 03เอกสารและบันทึกการตัดสินใจที่ทีมของคุณรับช่วงต่อได้

01 ปัญหา

สิ่งที่เราได้ยินก่อนการสร้างระบบใหม่

  1. 01

    ทุกการเปลี่ยนแปลงใช้เวลาเป็นไตรมาส

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

  2. 02

    พอร์ทัลใช้งานไม่ได้สำหรับคนที่ควรได้ใช้

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

  3. 03

    การเปลี่ยนแปลงของลูกค้ารายหนึ่งทำให้อีกรายเสียหาย

    ผลิตภัณฑ์ SaaS เติบโตจากการปรับแต่งให้ลูกค้าแต่ละราย ตอนนี้การเปิดใช้งานทุกครั้งต้องต่อรอง และผู้เช่าบางรายติดอยู่กับเวอร์ชันเก่า

  4. 04

    ความรู้หายไปพร้อมผู้พัฒนาเดิม

    ไม่เคยมีการจดบันทึกการตัดสินใจ ทีมที่สร้างระบบย้ายไปทำงานอื่นแล้ว และโค้ดเป็นเอกสารเพียงอย่างเดียว

  5. 05

    ลูกค้าในยุโรปเริ่มถามเรื่องความมั่นคงปลอดภัย

    ฝ่ายจัดซื้อของลูกค้าขอ SBOM กระบวนการจัดการช่องโหว่ และหลักฐานสำหรับ Cyber Resilience Act แต่ยังไม่มีใครเตรียมไว้

02 สิ่งที่เราส่งมอบ

สิ่งที่เราส่งมอบ

  1. 01 วิศวกรรมผลิตภัณฑ์ SaaS

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

    สิ่งที่เราทำ

    • เลือกรูปแบบผู้เช่า: ใช้ร่วมกัน รวมกลุ่ม หรือแยกต่อผู้เช่า
    • กลยุทธ์การตั้งค่าและ feature flag
    • การเชื่อมต่อการวัดการใช้งานและการเรียกเก็บเงิน
    • รอบการเปิดใช้งานที่ทยอยตามผู้เช่า

    สิ่งที่คุณได้รับ

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

  2. 02 การออกแบบตามโดเมนสำหรับกฎที่ซับซ้อน

    Domain-driven design สำหรับงานที่กฎคือตัวผลิตภัณฑ์ เช่น งานพิจารณาคำขอ การตรวจคุณสมบัติ และการคำนวณที่อิงกฎระเบียบ เราเลือกอย่างตั้งใจระหว่าง modular monolith กับ microservices และส่วนใหญ่เริ่มจากแบบแรก

    สิ่งที่เราทำ

    • Event storming ร่วมกับผู้เชี่ยวชาญในงาน
    • Bounded context และขอบเขตของโมดูล
    • ทำให้กฎชัดเจนและทดสอบได้
    • บันทึกการตัดสินใจด้านสถาปัตยกรรมสำหรับทางเลือกสำคัญ

    สิ่งที่คุณได้รับ

    • โมเดลโดเมนและแผนผังบริบท
    • โค้ดแบบโมดูลที่บังคับขอบเขตได้
    • ข้อกำหนดที่รันทดสอบได้สำหรับกฎหลัก

  3. 03 พอร์ทัลสำหรับประชาชนและพนักงาน

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

    สิ่งที่เราทำ

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

    สิ่งที่คุณได้รับ

    • พอร์ทัลบน design system ที่ใช้ซ้ำได้
    • รายงานความสอดคล้องด้านการเข้าถึงได้
    • ขั้นตอนการทำงานด้านเนื้อหาและการแปล

  4. 04 วิศวกรรมคุณภาพและการพัฒนาที่ปลอดภัย

    การทดสอบอัตโนมัติในระดับที่เหมาะสม การทดสอบข้อตกลงระหว่างบริการ การทดสอบประสิทธิภาพก่อนเปิดใช้งาน และวงจรการพัฒนาที่ปลอดภัยบนพื้นฐาน OWASP ASVS, SBOM และการควบคุมห่วงโซ่ซอฟต์แวร์

    สิ่งที่เราทำ

    • กลยุทธ์และระบบอัตโนมัติด้านการทดสอบ
    • การทดสอบข้อตกลงและการทดสอบประสิทธิภาพ
    • การวิเคราะห์ภัยคุกคามและการตรวจตาม ASVS
    • การสร้าง SBOM และนโยบายไลบรารีที่ใช้

    สิ่งที่คุณได้รับ

    • ชุดทดสอบอัตโนมัติในไปป์ไลน์
    • รายงานการตรวจสอบความมั่นคงปลอดภัย
    • กระบวนการจัดการช่องโหว่ที่พร้อมสำหรับ Cyber Resilience Act

  5. 05 ปรับปรุงระบบให้ทันสมัยทีละขั้น

    แทนที่แอปพลิเคชันเดิมทีละความสามารถ ผ่านชั้นกำหนดเส้นทาง (routing facade) ขณะที่ธุรกิจยังดำเนินต่อไป ดูเพิ่มเติมที่ปรับปรุงระบบเดิมให้ทันสมัย

    สิ่งที่เราทำ

    • แผนผังความสามารถของแอปพลิเคชันเดิม
    • การกำหนดเส้นทางแบบ strangler fig และการครอบด้วย API
    • การย้ายข้อมูลพร้อมรายงานการกระทบยอด
    • การรันคู่ขนานสำหรับการคำนวณที่สำคัญ

    สิ่งที่คุณได้รับ

    • ลำดับการปรับปรุงพร้อมหมุดหมายทางธุรกิจ
    • ชั้นกำหนดเส้นทางและโมดูลใหม่ที่ใช้งานจริง
    • ข้อมูลที่กระทบยอดแล้วในทุกการสลับระบบ

  6. 06 ความสามารถในการดูแลต่อและการส่งมอบงาน

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

    สิ่งที่เราทำ

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

    สิ่งที่คุณได้รับ

    • แผนส่งมอบงานพร้อมเกณฑ์การรับมอบ
    • ชุดเอกสารในที่เก็บโค้ดของคุณ
    • ทีมภายในที่ผ่านการฝึกฝน

03 สถาปัตยกรรม

ตัวอย่างสถาปัตยกรรมอ้างอิง

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

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

ชั้นในแผนภาพ

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

  1. ผู้ใช้งาน

    • ประชาชน ลูกค้า พนักงาน
    • หน้าจอที่ทุกคนเข้าถึงได้

  2. ปรับปรุงทีละขั้น

    • ชั้นกำหนดเส้นทาง
    • แอปพลิเคชันเดิม
    • ย้ายข้อมูลพร้อมกระทบยอด

  3. แพลตฟอร์ม

    • ชั้น API และข้อตกลง
    • ตัวตนและบทบาท
    • แกนกลางแบบโมดูล: รับเรื่อง งานพิจารณา การเรียกเก็บเงิน
    • ผู้เช่า การตั้งค่า feature flag
    • ที่เก็บข้อมูลของระบบงาน

  4. การส่งมอบที่ปลอดภัย

    • ทดสอบข้อตกลงและประสิทธิภาพ ตรวจตาม ASVS และ SBOM ในทุกการ build
แกนกลางแบบโมดูลหลังชั้นกำหนดเส้นทาง

ตัวอย่างสถาปัตยกรรม ไม่ใช่ระบบของลูกค้า

อ่านแผนภาพในรูปแบบข้อความ

เส้นทางหลักวิ่งจากผู้ใช้งานไปยังหน้าจอที่ทุกคนเข้าถึงได้ ผ่านชั้นกำหนดเส้นทางและชั้น API ไปยังแกนกลางแบบโมดูลที่จัดเป็น bounded context

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

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

04 ข้อพิจารณาและข้อจำกัด

ข้อพิจารณาทางวิศวกรรมและข้อจำกัด

  • เริ่มจาก modular monolith

    วิธีที่เราจัดการ

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

    ข้อจำกัดและเงื่อนไข

    Microservices แก้ปัญหาด้านองค์กรพอ ๆ กับปัญหาทางเทคนิค หากไม่มีทีมเป็นเจ้าของ จะเพิ่มต้นทุนและรูปแบบความล้มเหลว

  • การเข้าถึงได้เป็นงานวิศวกรรม

    วิธีที่เราจัดการ

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

    ข้อจำกัดและเงื่อนไข

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

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

  • การปรับปรุงระบบใช้เวลาเท่ากับที่ข้อมูลต้องการ

    วิธีที่เราจัดการ

    การย้ายข้อมูลวางแผนตามความสามารถ ซ้อม และกระทบยอด โดยฝ่ายธุรกิจรับรองทุกการสลับระบบ

    ข้อจำกัดและเงื่อนไข

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

  • กฎระเบียบสำหรับผลิตภัณฑ์ซอฟต์แวร์

    วิธีที่เราจัดการ

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

    ข้อจำกัดและเงื่อนไข

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

05 วิธีการทำงาน

วิธีการทำงานของเรา

รอบงานสั้น ผู้ใช้งานจริงเข้ามาตั้งแต่เนิ่น ๆ และวางแผนส่งมอบงานตั้งแต่สัปดาห์แรก

  1. 01

    ทำแผนผังโดเมน

    Event storming ร่วมกับผู้ที่รู้กฎ และแผนผังความสามารถของสิ่งที่มีอยู่ในปัจจุบัน

    ผลลัพธ์แผนผังบริบทและบันทึกการตัดสินใจชุดแรก

  2. 02

    ส่งมอบชิ้นงานแรกขนาดเล็ก

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

    ผลลัพธ์ส่วนแรกที่ใช้งานจริง

  3. 03

    ขยายทีละความสามารถ

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

    ผลลัพธ์แผนการเปิดใช้งานตามความสามารถ

  4. 04

    ส่งมอบงาน

    นักพัฒนาของคุณทำงานคู่กับทีมของเรา รับเวรดูแลระบบ และเป็นเจ้าของแผนงานเมื่อผ่านเกณฑ์การส่งมอบ

    ผลลัพธ์การส่งมอบงานที่ได้รับการยอมรับ

06 การควบคุมโดยมนุษย์

จุดที่คนยังเป็นผู้ควบคุม

ในซอฟต์แวร์ธุรกิจ การควบคุมหมายถึงการรู้ว่าใครเปลี่ยนอะไร ใครอนุมัติ และย้อนกลับอย่างไร

  • เจ้าของผลิตภัณฑ์กำหนดขอบเขต

    เจ้าของผลิตภัณฑ์ของคุณกำหนดลำดับความสำคัญและรับมอบงานแต่ละส่วน เราให้คำแนะนำ เจ้าของผลิตภัณฑ์เป็นผู้ตัดสิน

  • การตั้งค่ามีเจ้าของ

    การตั้งค่าผู้เช่าและ feature flag เปลี่ยนผ่านกระบวนการที่ตรวจสอบได้ โดยบทบาทที่คุณกำหนด

  • การสลับระบบต้องได้รับอนุมัติ

    การย้ายจากระบบเก่าไปยังระบบใหม่ทุกครั้งได้รับการรับรองจากฝ่ายธุรกิจ พร้อมแผนย้อนกลับที่ซ้อมแล้ว

  • การตัดสินใจถูกจดบันทึก

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

07 เทคโนโลยี

เทคโนโลยีที่เราใช้

ฝั่งหลังบ้าน (back end)
  • Java และ Kotlin
  • .NET
  • TypeScript และ Node.js
  • Python
ฝั่งหน้าบ้าน (front end)
  • React และ Next.js
  • Angular
  • Design system พร้อมคอมโพเนนต์ที่เข้าถึงได้
  • แอปพลิเคชันมือถือแบบ native และข้ามแพลตฟอร์ม
ข้อมูล
  • PostgreSQL
  • SQL Server และ Oracle (สำหรับระบบที่มีอยู่)
  • Event streaming
  • เครื่องมือค้นหา
คุณภาพและความมั่นคงปลอดภัย
  • Playwright และการทดสอบข้อตกลง
  • การทดสอบภาระงานและประสิทธิภาพ
  • SAST, DAST และการสแกนไลบรารี
  • SBOM ในรูปแบบ CycloneDX หรือ SPDX

การระบุชื่อเทคโนโลยีเป็นการบอกประสบการณ์ด้านวิศวกรรมของเรา ไม่ได้หมายความว่าเราเป็นพันธมิตรหรือได้รับการรับรองจากเจ้าของเทคโนโลยีนั้น

08 ตัวอย่าง

ตัวอย่างประกอบ

ตัวอย่างประกอบ

พอร์ทัลตัวแทนจำหน่ายเดียวสำหรับผู้ผลิตวัสดุก่อสร้างที่ขายทั้งในไทยและยุโรป

01สถานการณ์
ตัวอย่าง: ผู้ผลิตวัสดุก่อสร้างมีพอร์ทัลสำหรับตัวแทนจำหน่ายในประเทศไทยและพอร์ทัลสำหรับผู้จัดจำหน่ายในยุโรป ซึ่งผู้พัฒนาต่างรายสร้างไว้ แต่ละพอร์ทัลไม่ผ่านการตรวจการเข้าถึงได้ในจุดที่ต่างกัน และทุกการเปลี่ยนแปลงต้องทำสองครั้ง
02ระบบที่เราจะสร้าง
พอร์ทัลเดียวบน design system ร่วม โดยเก็บเนื้อหา ภาษา และการเชื่อมต่อของแต่ละตลาดไว้ในการตั้งค่า และใช้รอบการเปิดใช้งานเดียว
03จุดที่คนเป็นผู้ตัดสินใจ
ทีมของแต่ละตลาดอนุมัติเนื้อหาและการตั้งค่าของตลาดตน และเจ้าของผลิตภัณฑ์ตัดสินเรื่องฟีเจอร์ที่ใช้ร่วมกัน
04สิ่งที่เราจะวัดผล
จำนวนปัญหาด้านการเข้าถึงได้ต่อการเปิดใช้งาน เวลาที่ใช้เปลี่ยนแปลงให้ครบทุกตลาด และสัดส่วนการเปลี่ยนแปลงที่ทำครั้งเดียวแทนการทำแยกตามตลาด

09 มุมมองรายอุตสาหกรรม

ในอุตสาหกรรมของคุณ

  • ภาครัฐ

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

  • บริการทางการเงิน

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

  • การผลิตและอุตสาหกรรม

    ระบบกำหนดสเปกสินค้า พอร์ทัลบริการ และผลิตภัณฑ์ SaaS สำหรับผู้ผลิตเครื่องจักรและอุปกรณ์ ที่เชื่อมต่อกับ ERP และงานบริการภาคสนาม

ประเทศไทย

ตลาดใหม่คือการเปิดใช้งาน ไม่ใช่การแยกโค้ด

บริษัทซอฟต์แวร์ไทยที่ขายผลิตภัณฑ์เข้าสู่ตลาดสหภาพยุโรปต้องคำนึงถึง European Accessibility Act สำหรับผลิตภัณฑ์และบริการที่วางตลาดในสหภาพยุโรป และ Cyber Resilience Act ซึ่งเป็นระเบียบฉบับเดียวที่มีหน้าที่เริ่มใช้บังคับเป็นระยะ ส่วนผู้ใช้งานในประเทศไทยอยู่ภายใต้ PDPA และการออกใบกำกับภาษีในประเทศอาจใช้ระบบ e-Tax Invoice & e-Receipt ของกรมสรรพากร ซึ่งผู้ประกอบการเลือกใช้โดยสมัครใจ

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

คำถามเกี่ยวกับซอฟต์แวร์องค์กรและ SaaS

ควรพัฒนาเองหรือตั้งค่าบนแพลตฟอร์ม

ตั้งค่าบนแพลตฟอร์มเมื่อกระบวนการของคุณใกล้เคียงมาตรฐาน และพัฒนาเองเมื่อกระบวนการนั้นคือสิ่งที่ทำให้คุณแตกต่าง หรือเมื่อไม่มีแพลตฟอร์มใดรองรับกฎของคุณ เราทำงานทั้งกับ Salesforce, SAP และ Odoo และกับโค้ดที่พัฒนาเฉพาะ จึงไม่มีเหตุผลที่จะผลักดันคำตอบใดคำตอบหนึ่ง บริการสถาปัตยกรรมและการให้คำปรึกษาของเราช่วยให้การเลือกนี้ชัดเจน

รับประกันได้หรือไม่ว่าพอร์ทัลจะเข้าถึงได้

เราสร้างตาม EN 301 549 และ WCAG 2.2 ระดับ AA ทดสอบทั้งแบบอัตโนมัติและด้วยมือ และส่งมอบรายงานความสอดคล้องพร้อมปัญหาที่ทราบ WCAG 2.2 เป็นฉบับที่ใหม่กว่า WCAG 2.0 ซึ่งมาตรฐานการเข้าถึงเว็บไซต์ของไทย มอก. 2565-2555 นำมาใช้ เราไม่สัญญาว่าจะไม่มีปัญหาเลย แต่สัญญาว่าจะค้นหา รายงาน และแก้ไขสิ่งที่อยู่ในขอบเขตของเรา

ปรับปรุงระบบโดยไม่ต้องย้ายทั้งหมดในครั้งเดียวได้หรือไม่

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

ทีมของเราเองรับช่วงดูแลซอฟต์แวร์ต่อได้หรือไม่

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

Cyber Resilience Act มีความหมายอย่างไรต่อผลิตภัณฑ์ของเรา

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

บอกเราว่าอะไรต้องทำงานต่อไประหว่างที่ระบบเปลี่ยน

เราจะเสนอความสามารถแรกที่ควรย้าย และสิ่งที่ทีมของคุณจะเป็นเจ้าของเมื่อจบงาน

ปรึกษาโครงการของคุณดูโซลูชันปรับปรุงระบบเดิม