Skip to Content

Category Archives: Digital Business

Rabbit MQ ตอนที่ 2 – Exchanges, Routing Keys, and Bindings

สวัสดีครับ ในตอนที่แล้ว เราได้แนะนำ Rabbit MQ กันไปแล้ว สำหรับตอนที่ 2 นี้ เราจะเจาะลึกให้ละเอียดขึ้นอีกว่า องค์ประกอบของ Rabbit MQ มีอะไรบ้าง

Rabbit MQ มีองค์ประกอบอย่างไร

ภาพจาก: Introduction to RabbitMQ, Randhir Kumar, Software Consultant, Knoldus Inc.

 

องค์ประกอบของ Rabbit MQ มีดังนี้

  • Producer : โปรแกรมที่เป็นผู้ส่ง Message (Publish Message) โดยที่ Message อาจจะเป็นงานที่ต้องการส่งให้ระบบอื่นไปทำ หรืออาจเป็นการแจ้งข้อมูลข่าวสารให้ระบบอื่น ๆ รับทราบ
  • Exchange : ทำหน้าที่รับ Message และนำส่ง Message ไปให้ Queue ต่าง ๆ โดยพิจารณาจาก Routing Key ซึ่งเป็น Attribute ในแต่ละ Message
  • Binding : คือ การกำหนด “Link”  ว่า Queue ต่าง ๆ จะรับ Message ใดจาก Exchange โดย Binding จะเกี่ยวข้องกับ Routing Key และ Header
  • Queue : ทำหน้าที่คล้ายตู้จดหมาย (Post Box) ซึ่งอยู่ภายใน Rabbit MQ  เป็นที่เก็บ Message ทุกอย่างที่ผ่าน Rabbit MQ เข้ามาและออกไปยัง application โดยอาศัย Memory และ Disk ของเครื่อง Host ทำหน้าที่เป็น Buffer สำหรับเก็บ Message ดังนั้นปริมาณ Message ที่เก็บได้ ก็จะขึ้นกับขนาดของ Memory และ Disk ที่มี ในการใช้งาน Queue นั้น สามารถให้หลาย ๆ Producer ส่ง Message เข้าไปที่ Queue เดียวกันได้ และสามารถให้หลาย ๆ Consumer รับ Message จาก Queue เดียวกันได้เช่นกัน
  • Consumer : โปรแกรมที่เป็นผู้รอรับ Message (Consume Message) โดยอาจจะเป็นระบบที่รับงานจาก Producer มาดำเนินการ หรือรับข้อมูลข่าวสารมาอัพเดตในระบบ หรือส่งต่อให้ระบบอื่น

 

ประเภทของ Exchange

Rabbit MQ รองรับ Exchange ได้หลายประเภท เช่น Direct, Fanout, Topic, Header เป็นต้น แต่ละประเภทจะมีวิธีต่างกันในการกำหนด Binding เพื่อเชื่อมโยงกับ Queue

ภาพจาก: https://www.cloudamqp.com/blog/part1-rabbitmq-best-practice.html

 

1. Direct Exchange

Direct Exchange จะส่ง Message โดยอาศัย Routing Key เป็นตัวกำหนดว่า Message จะถูกส่งอย่างเจาะจงไปยัง Queue ที่มี Binding Key ตรงกับ Routing Key เท่านั้น

ตัวอย่างเช่น ระบบงานเพื่อประมวลผล pdf_events ประกอบด้วย Direct Exchange 1 ตัว และ Queue 2 ตัว

  • Queue A สำหรับทำงาน pdf create และมี routing key คือ pdf_create
  • Queue B สำหรับทำงาน pdf log และมี routing key คือ pdf_log

การทำงานเริ่มจาก Exchange ได้รับ Message จาก Producer เข้ามา Exchange จะตรวจสอบ Binding key ที่แนบมากับ Message ถ้า Routing key เป็น pdf_create ก็จะส่ง Message ไปยัง Queue A (เนื่องจากมี Binding key = pdf_create ตรงกัน) หรือถ้า Routing key เป็น pdf_log ก็จะส่งไปยัง Queue B (เนื่องจากมี Binding key = pdf_log ตรงกัน)

 

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

 

2. Fanout Exchange

Fanout Exchange ทำการส่ง Message ไปยังทุก Queue ที่ผูกกับ Exchange นั้น โดยไม่สนใจ Routing Key วิธีการนี้เหมาะสำหรับงานลักษณะ Broadcasting

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

 

ตัวอย่างการใช้งาน #1

เมื่อระบบประมวลผลข่าวกีฬา (Sports News)  ได้บันทึกข้อมูลข่าวกีฬาใหม่แล้ว ทำการ Publish Message นี้ (ซึ่งมีรายละเอียดของข่าว) ลงใน Fanout Exchange  จากนั้น Fanout Exchange ทำการ Broadcast ไปยังระบบช่องทางการรายงานข่าวต่างๆ เช่น ช่องทาง Web, Mobile, TV, Radio ซึ่งแต่ละช่องทางสามารถมีวิธีการนำข้อมูลรายละเอียดของข่าวไปใช้งานแตกต่างกัน

ตัวอย่างการใช้งาน #2

เมื่อระบบงาน HR ได้บันทึกข้อมูลพนักงานใหม่แล้ว ทำการ Publish Message ลงใน Fanout Exchange ซึ่ง Messageประกอบด้วยข้อมูลของพนักงานใหม่ จากนั้น Fanout Exchange ทำการ Broadcast ไปยังระบบงานอื่นที่เกี่ยวข้อง เช่น ระบบการจองคอมพิวเตอร์ เพื่อจองเครื่องให้กับพนักงานใหม่, ระบบการพิมพ์นามบัตร เพื่อจัดพิมพ์นามบัตรให้กับพนักงานใหม่, ระบบการฝึกอบรม เพื่อจองวันปฐมนิเทศพนักงานใหม่ เป็นต้น ระบบงานเหล่านี้สามารถรับ Message ไปประมวลผลได้ทันที นอกจากนี้ระบบงาน HR ซึ่งเป็น Publisher ก็ทำงานแบบ Asynchronous คือสามารถทำงานอื่นของตนเองต่อได้ โดยไม่ต้องรอผลลัพธ์จากระบบงานอื่นๆ กลับมาก่อน

 

3. Topic Exchange

Topic Exchange เหมาะสำหรับงานลักษณะ Multicast เพื่อส่ง Message ให้กับ Consumer บางส่วน โดยอาศัยการ Match Pattern ของ Routing Key กับ Binding Key โดย Routing Key มีลักษณะเป็นคำคั่นด้วยจุด เช่น agreements.eu.stockholm

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

 

ตัวอย่างเช่น ระบบงานสำหรับประมวลผล agreements  ใช้ Topic Exchange และ Queue 3 ตัว ดังนี้

Queue A สำหรับรับ Message ที่เกี่ยวกับ agreement ของ berlin เท่านั้นและกำหนด routing key = agreements.eu.berlin.#
Queue B สำหรับรับ Message เกี่ยวกับ agreement ทุกอย่าง routing key = agreements. #
Queue C สำหรับรับ Message เกี่ยวกับ agreement ของ headstore routing key = agreements.*.headstore

หมายเหตุ:

  • เครื่องหมาย * หมายถึงตำแหน่งนี้ต้องมีคำปรากฏ 1 คำ
    • เช่น binding key = “agreements.*.*.b.*” หมายถึง คำที่หนึ่งเป็น agreements, คำที่สี่เป็น b, ส่วนคำที่สอง สาม และห้า เป็นคำอะไรก็ได้แต่ต้องมี
  • เครื่องหมาย # หมายถึงตำแหน่งนี้จะมีคำใดๆปรากฏหรือไม่มีเลยก็ได้
    • เช่น binding key = “agreements.eu.berlin.#” หมายถึง คำที่หนึ่งเป็น agreements, คำที่สองเป็น eu, คำที่สามเป็น berlin, ส่วนคำที่สี่จะมีหรือไม่มีก็ได้

 

Example Scenario

 

Message #1 เข้ามา

ด้วย routing key = agreements.eu.

berlin.headstore

Message #1 จะถูกส่งไปยัง

Queue A เนื่องจาก 3 คำแรก (agreements, eu, berlin) ตรงกับ binding key

agreements.eu.berlin.headstore  VS  agreements.eu.berlin.#

 

Queue B เนื่องจากคำแรก (agreements) ตรงกับ binding key

agreements.eu.berlin.headstore  VS agreements.#

 

Queue C เนื่องจากคำที่หนึ่งและสี่ (agreements, headstore) ตรงกับ binding key

agreements.eu.berlin.headstore  VS agreements.*.headstore

 

Message #2 เข้ามา

ด้วย routing key = agreements.eu.

berlin.tailstore

Message #2 จะถูกส่งไปยัง Queue A, B

Queue A เนื่องจาก 3 คำแรก (agreements, eu, berlin) ตรงกับ binding key

agreements.eu.berlin.tailstore  VS  agreements.eu.berlin.#

 

Queue B เนื่องจากคำแรก (agreements) ตรงกับ binding key

agreements.eu.berlin.tailstore  VS agreements.#

 

Message #3 เข้ามา

ด้วย routing key = agreements.us.

headstore

Message #3 จะถูกส่งไปยัง Queue B, C

Queue B เนื่องจากคำแรก (agreements) ตรงกับ binding key

agreements.us.headstore  VS agreements.#

 

Queue C เนื่องจากคำที่หนึ่งและสี่ (agreements, headstore) ตรงกับ binding key

agreements.us.headstore  VS agreements.*.headstore

 

 

4. Header Exchange

Header Exchange อาศัยข้อมูลใน Header ในการกำหนดเส้นทางการส่ง Message โดยไม่ได้อาศัย Routing Key

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

 

ตัวอย่างเช่น ระบบงานสำหรับประมวลผล agreements  ใช้ Header Exchange และ Queue 3 ตัว

Queue A สำหรับรับ Message ที่รูปแบบเป็น pdf และเป็นข้อมูลประเภท report x-match = all
Queue B สำหรับรับ Message ที่รูปแบบเป็น pdf และเป็นข้อมูลประเภท log x-match = any
Queue C สำหรับรับ Message ที่รูปแบบเป็น zip และเป็นข้อมูลประเภท report x-match = all

X-match = any หมายถึง ต้องมี Header value อย่างน้อย 1 ตัว ใน Message ที่จะต้อง Match กับ Binding

ส่วน X-match = all หมายถึงทุก Header value ใน Message จะต้อง Match กับ Binding

Example Scenario

Message #1 มี Header Argument format=pdf, type=report –        Message #1 ถูกส่งไป Queue A เนื่องจาก Message Header ทั้ง format: pdf, type: report ตรงกับ Binding ทั้งหมดของ Queue A (X-Match = all)

–        Message #1 ถูกส่งไป Queue B ด้วย เนื่องจาก Message Header format: pdf, type: report ตรงกับ Binding ของ Queue B อย่างน้อย 1 ตัว (X-Match = any)

–        Message #1 ไม่ถูกส่งไป Queue C เนื่องจาก Queue C กำหนด X-Match = all คือต้องมีทั้ง format: zip และ type: log

Message #2 มี Header Argument format=pdf –        Message #2 ถูกส่งไป Queue B เนื่องจาก Message Header มี format: pdf ตรงกับ Binding 1 อย่าง (X-Match = any)

–        Message #2 ไม่ถูกส่งไป Queue A เนื่องจาก Queue A กำหนด X-Match = all คือต้องมีทั้ง format: pdf และ type: report

–        Message #2 ไม่ถูกส่งไป Queue C เนื่องจาก Queue C กำหนด X-Match = all คือต้องมีทั้ง format: zip และ type: log

 

Message #3 มี ด้วย Header Argument format=zip, type=log –        Message #2 ถูกส่งไป Queue B เนื่องจาก Message Header มี type: log ตรงกับ Binding 1 อย่าง (X-Match = any)

–        Message #2 ไม่ถูกส่งไป Queue A เนื่องจาก Queue A กำหนด X-Match = all คือต้องมีทั้ง format: pdf และ type: report

–        Message #2 ไม่ถูกส่งไป Queue C เนื่องจาก Queue C กำหนด X-Match = all คือต้องมีทั้ง format: zip และ type: log

 

 

ทั้งหมดนี้ก็คือส่วนสำคัญของ Rabbit MQ ครับ หากใครยังไม่ทันได้อ่านตอนที่ 1 ไปติดตามกันในลิ้งก์ https://www.stream.co.th/rabbit-mq-part1/ นะครับ

สนใจโซลูชั่นด้านดิจิทัล สามารถติดต่อเราได้ที่อีเมล Marketing@stream.co.th หรือโทร. 02-679-2233 ครับ

 

เรียบเรียงโดย Siripod Surabotsophon

0 2 Continue Reading →

Rabbit MQ ตอนที่ 1

Rabbit MQ คืออะไร

Rabbit MQ เป็น Software จำพวก Message Broker ซึ่งรับ Message จากระบบหนึ่งแล้วส่ง Message ต่อไปยังอีกระบบหนึ่ง นึกภาพคล้ายกับที่ทำการไปรษณีย์ (Post Office) คือผู้ส่งจดหมายซึ่งระบุชื่อและที่อยู่ของผู้รับ นำจดหมายที่ต้องการส่งไปยังตู้ไปรษณีย์ จากนั้นบุรุษไปรษณีย์ (Postman) จะทำการนำจดหมายนั้นส่งไปถึงผู้รับ

Rabbit MQ เป็นเสมือนทั้งตู้ไปรษณีย์ ที่ทำการไปรษณีย์ และบุรุษไปรษณีย์ เพียงแต่ Rabbit MQ ไม่ได้ทำงานกับจดหมายกระดาษ เพราะเป็นข้อมูลอิเล็กทรอนิกส์

Credit: ภาพจาก https://www.youtube.com/watch?v=dTx4MONz9CQ

Rabbit MQ ใช้ทำอะไร

การมีระบบจัดการด้าน Messaging ช่วยให้ Software Application ต่าง ๆ สามารถ Connect หากันได้และสามารถ Scale ได้ การ Connect นี้ก็มีทั้ง Application หลาย ๆ ตัว Connect ถึงกันได้ (ซึ่งแต่ละชิ้นก็เป็นองค์ประกอบของ Application ที่ใหญ่กว่า) หรือ Application connect ไปหาอุปกรณ์ต่าง ๆ หรือข้อมูลต่าง ๆ

เราสามารถนำแนวคิดของ Message Queue มาใช้จัดการเรื่อง data delivery, Non-blocking operation หรือ Push Notification รวมทั้งสามารถใช้ในงานแบบ Publish/Subscribe, Asynchronous processing, Work queues

Rabbit MQ เป็น Message Broker ซึ่งเป็นตัวกลางของระบบ Messaging โดยช่วยให้ Application ของเรามี platform ร่วมกันสำหรับส่งและรับ Message นอกจากนี้ยังเป็นที่จัดเก็บ Message ที่ปลอดภัยจนกว่าผู้รับจะได้รับ Message

 

1. Data Delivery

บางครั้ง หลายระบบงานที่ทำงานร่วมกัน อาจมีการส่งข้อมูลปริมาณมาก ๆ ระหว่างกัน ซึ่งไม่สามารถทำงานแบบ Real-time ได้เสมอไป ในบางองค์กรใช้วิธีการ Batch โดยตั้ง Schedule ให้ระบบสร้างไฟล์ Batch ออกมา แล้วส่งให้อีกระบบหนึ่งตาม Schedule ที่ตกลงกัน (ตัวอย่างเช่นระบบงาน Human Resource ส่งรายชื่อพนักงานใหม่ทุกสิ้นวันผ่าน Batch File ซึ่งส่งกระจายให้กับระบบงานอื่น ๆ เพื่อไป Create user account ให้พนักงานใช้) หากทำ Message Broker มาช่วยจัดการ จะลดการทำงานแบบ Batch นี้ออกไปได้

 

 

2. Non-Blocking Operation และ Asynchronous Operation

บางระบบงานที่ประกอบด้วยหลาย Process ทำงานร่วมกันนั้น มักจะมีการเรียกใช้งานระหว่างกัน ซึ่งหลาย ๆ ครั้งเกิดปัญหา Blocking ได้

Credit: ภาพจาก: https://www.researchgate.net/figure/Blocking-and-non-blocking-operation-calls_fig18_312384750

 

Credit: ภาพจาก https://www.koyeb.com/blog/introduction-to-synchronous-and-asynchronous-processing

 

รูปด้านซ้ายแสดงการทำงานที่เกิด Blocking operations คือ Process A ส่งงานให้ Process B ทำงาน ระหว่าง B ทำงานอยู่ A จะต้องรอจน B ทำเสร็จ แล้ว A จึงจะทำงานต่อได้ (เรียกว่าเป็น Synchronous) จะเห็นได้ว่าระบบจะเสียทรัพยากรไปเปล่าประโยชน์ในช่วงที่ A รอ B เพราะ A ไม่ได้ทำงานช่วงนั้นเลย อีกทั้งหาก B ทำงานช้า จะทำให้ A ทำงานช้าไปด้วย และภาพรวมของระบบก็จะทำงานได้ Throughput น้อยลง

ส่วนรูปด้านขวาแสดงการทำงานแบบ Non-blocking operations (เป็นแบบ Asynchronous) คือ Process A ส่งงานให้ Process B ทำงาน ระหว่างที่ B ทำงานอยู่ A ก็สามารถทำงานอื่นของตนต่อได้ เมื่อ B ทำเสร็จก็จะแจ้งกลับมาที่ A จะเห็นได้ว่าระบบใช้ทรัพยากรคุ้มค่ากว่า

เราสามารถนำ Software จำพวก Message Broker มาช่วยปรับปรุงระบบในลักษณะนี้ได้ โดยให้ Message Broker รับคำสั่งจาก Process A แล้วให้ Broker ส่งให้ Process B เมื่อ A ส่งให้ Broker แล้ว A สามารถทำงานอื่นต่อได้โดยไม่ต้องรอ (แต่มีเงื่อนไขว่างานอื่นที่ A หยิบมาทำระหว่างนั้น ไม่จำเป็นต้องใช้ผลลัพธ์จาก B)

 

3. Push Notification

Push Notification เป็นการส่งข้อความจากระบบไปยังอุปกรณ์หรือเครื่องคอมพิวเตอร์ของ User เพื่อแจ้งข้อมูล ข่าวสาร หรือร้องขอให้ทำ Action บางอย่างกลับไป ในระบบที่มีปริมาณการใช้งาน Notification สูง ๆ อาจะเกิด Blocking ขึ้นในจุดนี้ได้ ดังนั้นการนำ Message Broker มาช่วยจัดการส่วนนี้ จะลด Blocking Operation จากการที่ระบบต้นทางต้องรอ Push Server ทำงาน

 

4. Publish/Subscribe

Credit: ภาพจาก https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber

ในเชิง Software Architecture นั้น Publish/Subscriber จัดว่าเป็นรูปแบบหนึ่งของ Messaging ซึ่งผู้ส่ง Message (เรียกว่า Publisher) จะไม่ถูกกำหนดให้ส่ง Message ให้หาผู้รับ (Subscriber) โดยตรง แต่ละจัดแบ่งหมวดหมู่ของ Published Message โดยมักจะไม่สนใจว่า Subscriber คือใคร ส่วน Subscriber จะรับ Message เฉพาะที่ตนเองสนใจเท่านั้น โดยไม่ต้องรับรู้ว่ามาจาก Publisher รายใด ดังนั้น Message Broker จึงทำหน้าที่เป็นตัวกลางอย่างดีในการจัดการ Message เหล่านี้ ระหว่าง Publisher และ Subscriber โดย Publisher ทำการ Publish Message ไปยัง Input Channel ของ Broker และ Subscriber จะคอยรับ Message จาก Output Channel ของ Broker

 

Rabbit MQ เหมาะกับงานลักษณะใด

  • Data Delivery
  • Non-blocking operation
  • Push notification
  • Publish/Subscribe
  • Asynchronous Processing
  • Work Queues

 

Case Study

1. การส่งข้อความแจ้งเตือนเมื่อมีการ Login เข้าใช้งานระบบ

ระบบงานหนึ่งมี Requirement ว่า เมื่อ User ได้ Login ผ่านแล้ว ระบบจะต้องส่ง Email แจ้งไปยังผู้ใช้งานว่ามีการ Login ซึ่งจะช่วย User ในกรณีมีผู้อื่นแอบนำ Credential ของตนเองไปแอบใช้ การส่งแจ้งเตือนจะทำให้ User ตัวจริงทราบว่ามีการเข้าใช้งาน และดำเนินการระงับการใช้งานได้ทัน ก่อนจะเกิดความเสียหายได้

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

การทำงานลักษณะนี้ สามารถปรับปรุงได้ โดยให้โปรแกรมส่วนหลักทำการ Publish ข้อมูลสำหรับการส่ง Email Notification ไปยัง Message Queue แล้วให้ Consumer ดำเนินการส่งอีเมลผ่าน Mail Gateway ส่วนโปรแกรมส่วนหลักก็ Execute ต่อไปโดยไม่ต้องรอผลการส่ง Email

2. การ Generate Report ผ่านหน้า Web Application

ระบบงานหนึ่งมี Requirement ให้สร้าง Export ข้อมูลธุรกรรมย้อนหลังจำนวนมาก และข้อมูลแต่ละ Row ก็มี Column จำนวนหลายร้อย Column จึงใช้เวลานานมากในการสร้างไฟล์ หากเราออกแบบให้ทำงานแบบ Synchronous ก็จะเกิด Waiting Time ยาวนาน และ User ต้องรอจนกว่าจะเสร็จ หน้าจอ ขึ้น pop-up ให้ Save แล้วกด Save File ได้ จึงจะไปทำงานหน้าจออื่นได้

การออกแบบ จึงเลือกใช้ Message Broker เข้ามาช่วย โดยโปรแกรมส่วนหลัก (Publisher) ทำการ Publish คำสั่ง Export ไปยัง MQ แล้ว Update สถานะของ Job นี้เป็น In Progress  จากนั้น Consumer Process ดำเนินการ Export ข้อมูลและ Save File ลงใน Disk จากนั้นจึง Update สถานะของ Job เป็น Finish เมื่อ User เห็นสถานะนี้แล้วจึงกด Link เพื่อ Download File นั้นไปใช้งานในช่วงเวลาหลังจากที่ Publish คำสั่งเข้า MQ นั้น ไปจนถึง Consumer ทำงานเสร็จนั้น ทาง User ไม่จำเป็นรออยู่ที่หน้าจอเดิม สามารถไปหน้าจออื่นเพื่อทำงานอื่นได้

3. การยืนยันตัวตนใน NDID Platform

ปัจจุบัน Mobile Banking Application ของสถาบันการเงินต่าง ๆ มี Feature เรื่อง NDID Service ซึ่งเป็นบริการยืนยันตัวตนและขอข้อมูลส่วนบุคคลระหว่างสถาบันการเงิน โดยลูกค้าของธนาคารสามารถขอให้ Application สถาบันการเงินที่ตนติดต่ออยู่ เชื่อมต่อไปยังระบบของอีกสถาบันการเงิน เพื่อให้ทำการยืนยันตัวตนให้ ซึ่งการยืนยันตัวตนนี้อาจใช้เวลานาน เพราะมีทั้งการตรวจสอบสิทธิ์ด้วย PIN หรือ One-Time Password, การตรวจทานข้อมูลส่วนตัว, การทำ Face Recognition ดังนั้นจึงมีการนำ MQ เข้ามาใช้ในการรับส่งข้อมูลการขอยืนยันตัวตนระหว่างสถาบันการเงินด้วยกัน

Credit: ภาพจาก NDID Platform

 

สำหรับในส่วน Introduction จะขอจบเพียงเท่านี้ ในตอนถัดไปจะกล่าวถึงการใช้งาน Rabbit MQ ในรูปแบบต่าง ๆ ครับ

เรื่องของ NDID สามารถอ่านได้ที่ https://www.stream.co.th/why-ndid/

หากสนใจโซลูชั่นด้านดิจิทัล สามารถติดต่อเราได้ที่อีเมล Marketing@stream.co.th หรือโทร. 02-679-2233 นะครับ

 

เรียบเรียงโดย Siripod Surabotsophon

1 4 Continue Reading →

AMLO Report System สำคัญอย่างไร ทำไมสถาบันการเงินต้องมี?

AMLO หรือ สำนักงานป้องกันและปราบปรามการฟอกเงิน หรือ สำนักงาน ปปง. (The Anti-Money Laundering Office : AMLO) เป็นหน่วยงานของรัฐซึ่งมีอำนาจหน้าที่ในการวางหลักเกณฑ์ และดูแลให้มีการปฏิบัติตามกฎหมาย ว่าด้วยการป้องกันและปราบปรามการฟอกเงิน รวมทั้งเป็นหน่วยงานตรวจสอบวิเคราะห์ข้อมูลทางการเงินที่เกี่ยวข้องกับการฟอกเงิน ในหน้าที่ของหน่วยงานวางหลักเกณฑ์ (Regulator)

สำนักงาน ปปง.มีบทบาทในการศึกษาหามาตรการในการป้องกัน และปราบปรามการฟอกเงิน โดยมีฐานะเป็นฝ่ายเลขานุการของคณะกรรมการป้องกันและปราบปรามการฟอกเงิน (คณะกรรมการ ปปง.) ส่วนในฐานะของหน่วยงานผู้บังคับใช้กฎหมาย (Law Enforcement) สำนักงาน ปปง. มีอำนาจหน้าที่ในการตรวจสอบและดำเนินการเกี่ยวกับธุรกรรมหรือทรัพย์สินที่เกี่ยวข้องกับการกระทำความผิดฟอกเงิน ตามมติของคณะกรรมการธุรกรรม ตลอดจนดูแลให้ผู้มีส่วนเกี่ยวข้องปฏิบัติตามกฎหมายว่าด้วยการป้องกันและปราบปรามการฟอกเงินดังกล่าว

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

(อ้างอิง: https://www.amlo.go.th/)

AMLO Report System คืออะไร

ระบบ AMLO Report เป็น Web Application เพื่อให้สถาบันการเงินจัดการข้อมูล ที่จะต้องรายงานต่อสำนักงานป้องกันและปราบปรามการฟอกเงิน (สนง.ปปง. / AMLO) รายงานที่จัดการมี 4 ประเภท คือ

  1. ปปง. 1-01 (รายงานธุรกรรมที่ใช้เงินสด)
  2. ปปง. 1-02 (รายงานการทำธุรกรรมที่เกี่ยวกับทรัพย์สิน)
  3. ปปง. 1-03 (รายงานธุรกรรมที่มีเหตุอันควรสงสัย)
  4. ปปง. 1-05-9 (รายงานธุรกรรมที่เกี่ยวข้องกับการโอนเงินหรือชำระเงินทางอิเล็กทรอนิกส์)

AMLO Report System เหมาะสำหรับองค์กรใด

ระบบงานนี้เป็นสิ่งจำเป็นสำหรับสถาบันการเงินทุกแห่ง ที่อยู่ภายใต้กฎระเบียบว่าต้องรายงานธุรกรรมที่เข้าเกณฑ์ต่อสำนักงานป้องกันและปราบปรามการฟอกเงิน (ปปง. / AMLO) โดยความถี่ในการส่งขึ้นกับกฎเกณฑ์ที่กำหนดไว้ เช่น รายงาน ปปง. 1-01, 1-02 และ 1-05-9 ต้องรวบรวบข้อมูลคราวละ 15 วัน คือข้อมูลวันที่ 1 ถึงวันที่ 15 ของแต่ละเดือนต้องส่งภายในวันที่ 22 ของเดือนนั้น ข้อมูลวันที่ 16 ถึงสิ้นเดือน ต้องส่งภายในวันที่ 7 ของเดือนถัดไป)

AMLO Report System ทำอะไรได้บ้าง

ฟีเจอร์ของระบบโดยสังเขป มีดังนี้

  1. การบันทึก, แก้ไข, ยืนยันข้อเท็จจริง, ค้นหารายงานประเภท 1-01, 1-02, 1-03, 1-05-9
  2. Import ข้อมูลจาก Source/Application ต่าง ๆ ตามรูปแบบที่กำหนด เช่น Fix Length, XML เป็นต้น
  3. เชื่อมต่อกับระบบของธนาคาร เพื่อดึงข้อมูลลูกค้า, บัญชี
  4. Export ข้อมูลรูปแบบ CSV, EXCEL
  5. Export ข้อมูลในรูปแบบ XML File ตามที่ ปปง. กำหนด
  6. Operation Report เช่น สรุปข้อมูลรายวัน/รายเดือน, ข้อมูลที่บันทึกใหม่, ข้อมูลที่ยังไม่ได้ยืนยันข้อเท็จจริง แยกตามประเภทรายงาน
  7. Audit Log เพื่อติดตามการใช้งานของ User
  8. User & Role Management
  9. System Configuration สำหรับปรับแต่งการทำงานของระบบ

 

AMLO Report System มีส่วนประกอบซอฟต์แวร์อะไรบ้าง

  • Front-end เป็นส่วนของ User Interface ซึ่งพัฒนาด้วย Angula JS ทำงานบน Node JS และมี Apache HTTP Server สำหรับติดต่อกับ End User ผ่าน Web Browser
  • Back-end เป็นส่วนของการประมวลผล ทั้ง Online และ Batch ส่วนนี้พัฒนาด้วย Java และใช้ Framework Spring Boot และใช้ Rabbit MQ สำหรับจัดคิวงานต่าง ๆ
  • Data เป็นส่วนที่เก็บข้อมูลของระบบ ซึ่งใช้ MS SQL Server จัดการ

 

 

ผลงานที่ผ่านมา สตรีมฯ เป็นผู้วางแผนและติดตั้งระบบ AMLO Report System ให้กับธนาคารเอกชนขนาดใหญ่ มีผู้ใช้งานในหลายร้อยสาขาของธนาคาร และในสำนักงานใหญ่ หากสถาบันการเงินหรือผู้ให้บริการทางการเงินใด สนใจติดตั้งระบบนี้ สามารถติดต่อได้ที่ฝ่ายการตลาด อีเมล Marketing@stream.co.th หรือโทร. 02-679-2233 นะครับ

 

เรียบเรียงโดย Siripod Surabotsophon

0 0 Continue Reading →

คุณทราบหรือไม่ ตราสารบางประเภท สามารถเสียอากรแสตมป์เป็นอิเล็กทรอนิกส์ได้!!

ตั้งแต่วันที่ 1 กรกฎาคม 2562 ที่ผ่านมา มีประกาศอธิบดีกรมสรรพากร เกี่ยวกับอากรแสตมป์ (ฉบับที่ 58) กำหนดวิธีในการชำระอากรแสตมป์รูปแบบใหม่สำหรับตราสารที่เป็นอิเล็กทรอนิกส์ 5 ประเภท

 

ข้อดี คือ องค์กรที่มีการทำเอกสารสัญญาเป็นไฟล์อิเล็กทรอนิกส์ จะได้รับความสะดวกสบายในการทำธุรกรรมออนไลน์ สามารถชำระภาษีผ่านระบบชำระเงินผ่านอินเตอร์เน็ตของกรมสรรพากร (E-Filing) ได้โดยตรง ไม่ต้องออกเอกสารเป็นกระดาษ

 

ตราสารอิเล็กทรอนิกส์ 5 ประเภท มีอะไรบ้าง

  1. ตราสาร 4 จ้างทำของ
  2. ตราสาร 5 กู้ยืมเงินหรือทำการตกลงให้เบิกเงินเกินบัญชีจากธนาคาร
  3. ตราสาร 7 ใบมอบอำนาจ
  4. ตราสาร 8 ใบมอบฉันทะสำหรับให้ลงมติในที่ประชุมบริษัท
  5. ตราสาร 17 ค้ำประกัน

 

ในกรณีที่องค์กรทำเอกสารตราสารด้านบนเป็นอิเล็กทรอนิกส์ จะต้องมีการชำระอากรแสตมป์เป็นตัวเงินด้วยแบบ อ.ส. 9 โดยมี 2 ช่องทางในการยื่นแบบคือ

  1. ชำระด้วยตนเองผ่านระบบยื่นแบบภาษีด้วยอินเตอร์เน็ต
  2. ยื่นชำระผ่านทาง Application Programming Interface (API) ของผู้ให้บริการที่ได้รับอนุมัติให้เชื่อมต่อกับกรมสรรพากรได้

 

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

 

หากต้องการชำระอากรแสตมป์เป็นอิเล็กทรอนิกส์ผ่านทาง API ต้องทำอย่างไร?

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

ภาพจาก: https://estamp.rd.go.th/stampweb/#/document/support

 

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

 

ระบบของสตรีมฯ ทำอะไรได้บ้าง

  1. การรับและการส่งไฟล์จำนวนมากหรือไฟล์ขนาดใหญ่ โดยกำหนดตารางเวลาทำงานอัตโนมัติตามรอบหรือระยะเวลาได้
  2. รองรับรูปแบบของข้อมูล และตรวจสอบความถูกต้องของข้อมูลตามที่กำหนดไว้ในระบบ รวมถึงเติมเต็มข้อมูลให้ครบถ้วนก่อนส่งไปยังกรมสรรพากร
  3. รองรับการตรวจสอบและอนุมัติตามที่กำหนด เพื่อเตรียมนำส่งข้อมูล
  4. สามารถปรับเปลี่ยนข้อมูลที่มีรูปแบบที่แตกต่างกัน ให้เป็นรูปแบบมาตรฐานกระบวนการในการรับส่งข้อมูลตามที่สรรพากรกำหนด พร้อมทั้งมีการเข้ารหัสข้อมูล ช่วยรักษาข้อมูลต่าง ๆ ให้มีความปลอดภัย และรองรับตามมาตรการตามกฎหมาย
  5. รองรับการกำหนดตารางเวลา การนำส่งข้อมูลให้ใหม่โดยอัตโนมัติ หากเกิดข้อผิดพลาดขึ้น รวมถึงสามารถดำเนินการส่งใหม่โดยผู้ใช้งานแบบ manual
  6. สามารถดาวน์โหลดเอกสาร ชุดชำระเงิน ใบเสร็จรับเงิน รหัสรับรองการเสียอากรแสตมป์
  7. รองรับการสร้างข้อมูลการชำระเงิน เพื่อบริการโอนเงินเข้าบัญชีระหว่างธนาคารอัตโนมัติ
  8. กำหนดผู้เข้าถึงระบบและสิทธิ์การใช้งานได้ กำหนดข้อมูลระบบ และกำหนดข้อมูลของระบบที่เกี่ยวข้อง
  9. ตรวจสอบสถานะการทำงานในแต่ละขั้น ตอนตั้งแต่จัดเตรียมข้อมูล จัดส่งไปยังกรมสรรพากร และผลการตรวจสอบจากกรมสรรพากรได้
  10. สามารถกำหนดการแจ้งเตือนให้ผู้ใช้งานในแต่ละขั้นตอนได้
  11. จัดทำรายงานการเข้าระบบของผู้ใช้งาน รายงานการจัดเตรียมข้อมูล และรายงานผลการตรวจสอบจากกรมสรรพากร

 

สรุปจุดเด่นของระบบสตรีมฯ

– รองรับการจัดการ รายงานการนำส่ง และนำส่งข้อมูลเป็นจำนวนมากได้อย่างมีประสิทธิภาพ

– ใช้ชุดคำสั่งคอมพิวเตอร์ที่เป็นมาตรฐานในการเชื่อมต่อกับระบบงานของกรมสรรพากร และมีความปลอดภัย

– สามารถเรียกดูหรือดาวน์โหลดเอกสารตราสารอิเล็กทรอนิกส์ ใบเสร็จรับเงิน และรหัสรับรองการชำระอากรแสตมป์

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

 

ท่านใดในองค์กรมีตราสาร  5 ประเภท ที่ต้องการชำระเป็นอิเล็กทรอนิกส์จำนวนมาก ไม่ว่าจะเป็นตราสารสัญญาจ้างทำของ สัญญากู้ยืมเงินหรือทำการตกลงให้เบิกเงินเกินบัญชีจากธนาคาร ใบมอบอำนาจ ใบมอบฉันทะสำหรับให้ลงมติในที่ประชุมบริษัท และสัญญาค้ำประกัน ถ้าต้องการทำระบบชำระอากรแสตมป์เป็นตัวเงินสำหรับตราสารอิเล็กทรอนิกส์ สามารถติดต่อสตรีมฯ ได้ที่ฝ่ายการตลาด อีเมล Marketing@stream.co.th หรือโทร. 02-679-2233

ฝากอีกนิดค่ะ เราให้บริการทำระบบ “e-Withholding Tax” ให้กับธนาคารและผู้ให้บริการทางการเงินด้วยนะคะ อ่านต่อได้ที่ https://www.stream.co.th/e-wht-for-banking/

0 0 Continue Reading →

หยุด! ละเลยข้อมูลส่วนบุคคลที่สำคัญ ด้วย CipherTrust Data Security Platform by THALES

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

 

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

 

ทำอย่างไรจึงจะจัดการและปกป้องข้อมูลที่มีอยู่ ได้ดีที่สุด

 

เมื่อพูดถึงการบริหารการจัดการภายใต้ข้อจำกัดที่กล่าวมา มีอยู่แพลตฟอร์มหนึ่งที่จะช่วยจัดการข้อมูลได้อย่างดี ซึ่งมีชื่อว่า “CipherTrust Data Security Platform” โดยเป็นผลิตภัณฑ์ของ Thales ผู้เชี่ยวชาญด้านแพลตฟอร์มรักษาความปลอดภัยข้อมูลอันดับต้น ๆ ของโลก

 

 

CipherTrust Data Security Platform ทำอะไรได้บ้าง

 

  • Data Discovery and Classification ช่วยคุณค้นหาว่า ข้อมูลส่วนบุคคลว่าถูกจัดเก็บอยู่ในระบบใดบ้าง เช่น บัตรประชาชน, เบอร์โทรศัพท์, หมายเลขบัตรเครดิต หรือข้อมูลที่เกี่ยวข้องที่สามารถระบุตัวตนของลูกค้าได้ ซึ่งมีความเสี่ยงหากข้อมูลหลุดไป ระบบจะวิเคราะห์ออกมาเป็น report สรุปความเสี่ยงที่เกิดขึ้น เพื่อหาทางป้องกันต่อไป

 

  • Data Masking หรือการปิดบังไม่ให้เห็นข้อมูลทั้งหมด ซึ่งไม่ใช่การเข้ารหัส สามารถทำได้ง่าย โดยเฉพาะสำหรับ application ที่มีความหลากหลายของภาษาที่พัฒนา การใช้งานฟังก์ชั่นแบบ Tokenization จะลดเวลาในการ coding application ที่ต้องการปกป้องข้อมูลของลูกค้าในรูปแบบของ API template สามารถกำหนดรูปแบบตามมาตราฐาน Data Masking ด้วยฟีเจอร์ที่มีชื่อว่า “CipherTrust Tokenization

 

  • File Protection ปกป้องข้อมูลที่เข้ารหัสไฟล์ไว้ ด้วยฟีเจอร์ “CipherTrust Transparent Encryption” ความยากไม่ได้อยู่ที่การเข้ารหัส หรือการเข้าถึงไฟล์ตามสิทธิ์ที่ระบุ แต่อยู่ที่การทำให้การเข้ารหัสนั้นมีระบบบริหารการจัดการ key ที่ทำ encryption ในรูปแบบ real-time และไม่ให้ระบบมี downtime ในกรณีที่ key ที่ทำ encryption file นั้นสูญหายหรือถูกขโมยไป ตัว CTE นี้จะช่วยคุณกำหนดบทบาทการทำงานของระบบรักษากุญแจดิจิทัลได้แบบอัตโนมัติ

 

  • Database Protection ทั้งรูปแบบ “Transparent Data Encryption: TDE” หรือ Column Encryption Database ซึ่งต้องบริหารจัดการ การเข้ารหัสของข้อมูลที่สำคัญในฐานข้อมูล เช่น Oracle, Microsoft SQL โดยใช้ “CipherTrust Database Encryption” เชื่อมโยงการบริหารจัดการ Key ในรูปแบบ TDE ได้ทั้งในส่วน Oracle และ Microsoft SQL และยังมีฟีเจอร์ในการทำ Column Encryption Database เพื่อให้ตอบโจทย์การปกป้องข้อมูลขององค์กรธุรกิจคุณ

 

  • Bring Your Own Key: BYOK ซึ่งเป็นเรื่อง Key ของการทำ Encryption บน Cloud Provider ก็เป็นอีกเรื่องที่องค์กรต้องคอยกำกับดูแล นอกเหนือไปจากการบริหารจัดการ encryption เพื่อช่วยลดความยุ่งยาก จึงเกิดเป็นโซลูชั่น “CipherTrust Cloud Key Manager” ที่จะช่วยบริหารจัดการ Key เป็น Centralize Management ได้ โดยมีการเชื่อมโยงกับ Cloud Provider และยังสามารถกำหนด Key ที่ใช้ Encryption ได้จากระบบ Data Center (On-premise) ขององค์กรคุณเอง เพื่อการปกป้องข้อมูลของคุณบน Cloud ได้อย่างมีประสิทธิภาพ

 

นอกจากตัว platform ที่โดดเด่นเรื่องบริหารจัดการข้อมูล ไม่ว่าจะเป็นการค้นหาข้อมูล แบ่งประเภทข้อมูล ปิดบังข้อมูลสำคัญบางส่วน จัดการ encryption ในระดับไฟล์และ database รวมถึงการจัดการเรื่อง key บน cloud แล้ว ทางทีมงานของสตรีมฯ มีความเชี่ยวชาญด้าน Data Security ด้วยประสบการณ์มากกว่า 10 ปี

 

ผลงานที่ผ่านมา อาทิเช่น การทำ Database Protect and Application Protection ให้กับกลุ่มธุรกิจประกันภัยและสถานพยาบาล ซึ่งต้องการทำระบบ Digital Signature เพื่อป้องกันเอกสารที่ส่งผ่านระบบออนไลน์ภายในองค์กรหรือภายนอกองค์กร การทำ Mobile Security ให้กับหน่วยงานภาครัฐ ในการทำระบบการบริหารการจัดการออนไลน์ ภายใต้ความปลอดภัยบน Mobile Application และการทำ Cloud Security ให้กับสถาบันการเงินและหน่วยงานกำกับดูแลที่ให้ความสนใจการบริหารจัดการ key (BYOK) เพื่อความปลอดภัยในการใช้ key ที่ใช้ encryption บน cloud ทำให้มั่นใจได้ว่า เราจะให้คำปรึกษาและส่งมอบงานที่ดีที่สุดให้กับองค์กรของคุณ

 

สนใจโซลูชั่นและขอคำปรึกษา ติดต่อได้ที่ฝ่ายการตลาด อีเมล Marketing@stream.co.th หรือโทร. 02-679-2233 นะคะ

0 2 Continue Reading →

เทรนด์เทคโนโลยีที่ธุรกิจจำเป็นต้องรู้: Mobile application – Web application และ Chatbot ไม่มีก็อยู่ยาก

คุณทราบหรือไม่ ผลสำรวจบอกว่า ปัจจุบันผู้บริโภคเข้าดูเว็บไซต์ค้าปลีกผ่านอุปกรณ์มือถือมากกว่าเดสก์ท็อป (Adobe Digital Insights, 2020) นอกจากนี้ ผู้บริโภค 63% ต้องการให้แบรนด์ต่าง ๆ นำเสนอคำแนะนำแบบเฉพาะบุคคล (Accenture, 2019) ทำให้แบรนด์จะต้องใส่ใจเรื่องการพัฒนาแพลตฟอร์ม Mobile Application เพื่อที่จะตอบสนองกับผู้ใช้งานหรือลูกค้าโดยตรง ซึ่งจะทำให้ธุรกิจเข้าไปนั่งในใจลูกค้า สร้างความได้เปรียบเหนือคู่แข่ง
.

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

  • หากต้องการ Platform ในการสร้าง Web application โดยนำไปพัฒนาต่อ
    สตรีมฯ เป็น partner กับผู้ผลิตซอฟต์แวร์หลายแบรนด์ที่เป็นแบรนด์ชั้นนำในตลาด ซึ่งจะช่วยลดเวลาในการพัฒนา application ลงได้มาก เพราะเป็น platform สำเร็จรูป เรียกง่าย ๆ ว่า Low-code Platform เพียงแค่คลิก ลาก วาง อีกทั้งยังไม่อาศัยความรู้ด้านไอทีในระดับลึก ทำให้ทุกคนใช้งานได้สะดวก รวมไปถึงการสร้างระบบงาน (workflow) ให้ราบรื่นยิ่งขึ้น ออกรายงาน (report) และเป็นศูนย์กลางในการประมวลผลข้อมูลและส่งข้อมูลไปให้ระบบอื่น ๆ ได้ด้วย ซึ่งสตรีมฯ เรามีทีมงานผู้เชี่ยวชาญช่วยแนะนำดูแล สอบถามได้ค่ะ
    .
  • แต่หากคุณต้องการความยืดหยุ่น อยากให้ทั้ง Web application – Mobile application มีลักษณะเฉพาะ
    ตัวแอปพลิเคชั่นมีรายละเอียด รองรับความต้องการรูปแบบต่าง ๆ สตรีมฯ ก็มีซอฟต์แวร์ที่เป็นแบบ Open Source สามารถตอบสนองกับผู้ใช้งานหรือลูกค้าของตนเองได้ดียิ่งขึ้น ยกตัวอย่างเช่น การกรอกข้อมูลในแอปพลิเคชั่นเพื่อเก็บประวัติ การปรับระบบงาน การอนุมัติเอกสารผ่านระบบ รวมถึงการดาวน์โหลดเอกสารออกมาจัดเก็บในถังจัดเก็บข้อมูล และส่งเอกสารให้ลูกค้าอัตโนมัติผ่านทางอีเมล เป็นต้น ขึ้นอยู่กับความต้องการของลูกค้าเป็นหลัก สตรีมฯ ก็สามารถพัฒนาให้ได้เช่นกันค่ะ

 

ดังนั้นเพื่อให้เห็นภาพมากยิ่งขึ้น เราขอยกตัวอย่างประสบการณ์ที่สตรีมฯ ทำให้กับกลุ่มธุรกิจประกันภัยมานานหลายปี
เรามี Web application – Mobile application ที่ครอบคลุมบริการของกลุ่มประกัน ไม่ว่าจะเป็น

  • Web & Mobile Application for Customer สำหรับลูกค้าให้เข้ามาเปรียบเทียบแพ็กเกจประกันออนไลน์ มี Self-service ในการตรวจสภาพรถ การชำระเบี้ยประกันผ่านระบบ Internet Banking, Mobile Banking, Credit Card, Debit Card, e-Wallet, Promptpay รวมทั้งรอรับกรมธรรม์ผ่านแอปได้โดยตรง
  • Web & Mobile Application for Agent สำหรับตัวแทนประกัน ในการนำเสนอแพ็กเกจให้ลูกค้าได้สะดวกรวดเร็ว มีการตรวจสภาพรถก่อนซื้อ การชำระเบี้ยประกันได้หลายช่องทาง การแจ้งสลักหลังกรมธรรม์ แก้ไขข้อมูลกรมธรรม์ ระบบแจ้งเตือนต่ออายุประกัน การบริหารจัดการตัวแทนลูก รวมถึงมี report และ dashboard
  • Web Application for Garage สำหรับอู่ ในการคุยกับบริษัทประกัน ไม่ว่าจะเป็นเรื่องอะไหล่ ค่าแรง เป็นต้น

 

จุดเด่น

  1. ระบบหลังบ้านที่ทางสตรีมฯ พัฒนา สามารถติดตั้งได้ทั้งแบบ On-premise บน Server ของลูกค้า และแบบ On-cloud เช่น AWS, Google Cloud, Huawei Cloud หรือ Azure Cloud
  2. ระบบ Mobile Agent ถูกออกแบบให้ติดตั้งได้ทั้งสมาร์ทโฟนระบบ IOS และ Android
  3. รองรับการเชื่อมต่อกับระบบอื่น ๆ ได้ เช่น ERP , Core Insurance , Email Gateway เป็นผ่านทาง API
  4. ทีมงานผู้เชี่ยวชาญสามารถให้คำปรึกษา และออกแบบหน้าจอของระบบได้ตามต้องการ
  5. เรามี Module พร้อมให้บริการ เพียงแค่ปรับตามความต้องการลูกค้า ก็สามารถส่งมอบได้อย่างรวดเร็ว

 

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

ภาพเบื้องหน้านั้นสำคัญ แต่เบื้องหลังก็ละเลยไม่ได้ เราจึงทำโซลูชั่นการขอความยินยอมในการเก็บข้อมูลส่วนบุคคลและนำข้อมูลไปใช้ หรือที่เรียกว่า Consent Management ซึ่งออกมาตอบรับกับ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (Personal Data Protection Act B.E. 2562: PDPA) ที่สอดคล้องกับ GDPR เพื่อปกป้องข้อมูลส่วนบุคคลของผู้ใช้แอปพลิเคชั่น โดยทีมงานผู้เชี่ยวชาญของสตรีมฯ ได้พัฒนาตัวระบบ consent ขึ้นมาเอง เพื่อเป็น portal กลาง เชื่อมกับแอปพลิเคชั่นอื่น ๆ ที่มีการตอบสนองกับลูกค้า ในการส่งข้อมูลและจัดการข้อมูลส่วนบุคคลผ่านระบบ ทั้งยังสามารถเชื่อมต่อกับแพลตฟอร์มด้าน data protection เพื่อป้องกันการโจมตีจาก IP ที่ผิดปกติได้ด้วย

ภายใต้ Digital solution ที่หลากหลาย เรียกได้ว่าสตรีมฯ มีบริการครบวงจรสำหรับการทำแอปพลิเคชั่น ไม่ว่าจะเป็น Web application – Mobile application ลักษณะใด ๆ ที่ลูกค้ามองหา ไปถึงการทำให้แอปพลิเคชั่นสื่อสารกับผู้บริโภคอย่างรวดเร็วโดยใช้ chatbot และดูแลเรื่องความเป็นส่วนตัวของข้อมูลส่วนบุคคลในแอปพลิเคชั่นด้วย

สุดท้ายนี้ การทำความเข้าใจผู้บริโภคและนำเสนอประสบการณ์ที่ดีผ่านสมาร์ทโฟนและหน้าเว็บ จะเป็นกุญแจสำคัญในการสร้างความได้เปรียบให้กับองค์กรของคุณในยุคที่ทุกอย่างต้องเร็ว สนใจปรึกษาเรื่องการสร้างแอปพลิเคชั่น ทำ chatbot และ consent กับสตรีมฯ วันนี้ ติดต่อแผนกการตลาดได้ที่อีเมล Marketing@stream.co.th หรือ โทร. 02-679-2233

0 0 Continue Reading →

สตรีมฯ พร้อมให้บริการระบบ “e-Withholding Tax” สำหรับธนาคารและผู้ให้บริการทางการเงิน

     สตรีมฯ พร้อมให้บริการจัดทำ “e-Withholding Tax” ระบบการหักภาษี ณ ที่จ่าย และนำส่งข้อมูลการหักภาษี ณ ที่จ่าย แบบอิเล็กทรอนิกส์ สำหรับกลุ่มธนาคารและผู้ให้บริการทางการเงิน!!

หลังจากที่กรมสรรพากรได้มีมาตรการคืนสภาพคล่องให้แก่ผู้ประกอบการในประเทศ และพยายามผลักดันให้ผู้ประกอบการ จ่ายและนำส่งภาษีแบบ e-Withholding Tax โดยจะได้ลดหย่อนอัตราภาษีเงินได้หัก ณ ที่จ่าย จาก 3% เหลือ 2% ในช่วงวันที่ 1 ตุลาคม 2563 – 31 ธันวาคม 2564 อีกด้วย

 

วัตถุประสงค์หลักของ e-Withholding Tax

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

 

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

 

     สตรีมฯ เราจัดทำระบบการหักภาษี ณ ที่จ่าย และนำส่งข้อมูลการหักภาษี ณ ที่จ่าย แบบอิเล็กทรอนิกส์ (e-Withholding Tax) ให้กับกลุ่มธนาคาร

 

จุดเด่นของระบบ “e-Withholding Tax”

  1. การรับและส่งไฟล์จำนวนมากหรือไฟล์ขนาดใหญ่ โดยกำหนดตารางเวลาทำงานอัตโนมัติตามรอบหรือระยะเวลา
  2. มีการเข้ารหัสข้อมูล ช่วยรักษาข้อมูลต่าง ๆ ให้มีความปลอดภัย และรองรับมาตรการตามกฎหมาย
  3. มีการรองรับรูปแบบของข้อมูลหลากหลาย ได้แก่ Domestic, Cross-border, BP256 และ Bank statements พร้อมตรวจสอบความถูกต้องของข้อมูลตามที่กำหนดไว้ในระบบ รวมถึงเติมเต็มข้อมูลให้ครบถ้วนก่อนส่งไปยังกรมสรรพากร
  4. กำหนดผู้เข้าถึงระบบและสิทธิ์การใช้งานได้
  5. ตรวจสอบสถานะการทำงานในแต่ละขั้นตอนตั้งแต่จัดเตรียมข้อมูล จัดส่งไปยังกรมสรรพากร และผลการตรวจสอบจากกรมสรรพากร ได้ทั้งแบบไฟล์และแบบรายการ
  6. สามารถกำหนดการแจ้งเตือนให้ผู้ใช้งานในแต่ละขั้นตอนได้
  7. จัดทำรายงานการเข้าระบบของผู้ใช้งาน รายงานการจัดเตรียมข้อมูล และรายงานผลการตรวจสอบจากกรมสรรพากร

 

เหตุใดถึงควรเลือกสตรีมฯ

  • สตรีมฯ มีประสบการณ์กว่า 10 ปี ในการทำโซลูชั่นรับส่งไฟล์แบบ Host-to-Host (H2H) โดยเฉพาะในกลุ่มธนาคาร
  • บริษัทได้รับการรับรองมาตรฐานการทำงานจาก ISO9001:2015 และ ISO27001
  • เราร่วมพัฒนาและติดตั้งโครงการของกรมสรรพากร ในโครงการพัฒนาระบบการนำเข้าและคัดแยกข้อมูลการชำระเงินแบบอิเล็กทรอนิกส์ และยังเป็น Service Provider ของกรมสรรพากร ในโซลูชั่น e-Tax Invoice
  • ทีมงานที่ปรึกษามีความเชี่ยวชาญ สามารถแนะนำขั้นตอนการลงทะเบียนให้กับผู้นำส่งข้อมูลได้
  • ระบบเสถียร มีประสิทธิภาพ นำส่งข้อมูลรวดเร็ว และมีความปลอดภัยขั้นสูง
  • มีการตรวจสอบข้อมูลที่นำเข้าระบบและนำส่งให้ถูกต้อง ครบถ้วน

 

หากธนาคารหรือผู้ให้บริการด้านการเงิน สนใจทำโซลูชั่น e-Withholding Tax สามารถติดต่อได้ที่ Marketing@stream.co.th หรือโทร. 02-679-2233 ค่ะ

0 0 Continue Reading →

ธุรกิจไม่สะดุด รับส่งไฟล์ไม่ติดขัด ด้วยโซลูชั่น Data Gateway

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

 

สตรีมฯ เข้าใจปัญหานี้ดี เรามีโซลูชั่นเกี่ยวกับ Data Gateway ในการรับส่งข้อมูลให้หลายองค์กร ด้วยซอฟต์แวร์ “IBM Sterling Connect:Direct” ซึ่งเป็นซอฟต์แวร์ Managed File Transfer ที่พัฒนาต่อยอดจาก FTP (File Transfer Protocol) โดยเพิ่มฟังก์ชั่นความปลอดภัยของข้อมูล การ monitor และฟังก์ชั่นอื่น ๆ ซึ่งจะทำงานโดยการรับส่งไฟล์แบบ peer-to-peer หรือระหว่าง node ในการรับส่งไฟล์ระหว่างองค์กร

 

ข้อดีของ Sterling คือ

  1. กำหนดตารางเวลาทำงานอัตโนมัติ ตั้งค่าจุด checkpoint สำหรับเริ่มต้น download ใหม่ และการกู้คืนแบบอัตโนมัติ เพื่อช่วยให้มั่นใจได้ว่าจะสามารถส่งมอบไฟล์ได้อย่างแน่นอน
  2. มีการเข้ารหัสข้อมูล ช่วยรักษาข้อมูลส่วนตัวของผู้ใช้งาน และรองรับมาตรการตามกฎหมาย
  3. จัดการงานได้ตามความต้องการ ตั้งแต่ไฟล์ขนาดเล็ก ๆ จำนวนมาก ไปจนถึงไฟล์ขนาดหลาย Gigabyte
  4. ลดระยะเวลาในการติดตั้งหรือการแพตช์ จากหลักชั่วโมงเป็นหลักนาที โดยการติดตั้งบน Certified Container ที่รองรับได้หลากหลาย protocol เช่น FTP, FTPS, SSH/SFTP, HTTP, HTTPS, IBM® Sterling Connect:Direct®, IBM®Sterling Connect:Direct® Secure Plus, WebDAV, SOAP, ODETTE
  5. รองรับการติดตั้งและใช้งานหลายระบบปฏิบัติการ ได้แก่ Windows, UNIX, Linux, IBM z/OS, OpenVMS, i5/OS, HP

 

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

ตัวอย่างโครงการที่เราทำ ได้แก่ โครงการพัฒนาระบบการนำเข้าและคัดแยกข้อมูลการชำระเงินแบบอิเล็กทรอนิกส์ ภายใต้แผนยุทธศาสตร์ National e-Payment ให้กับหน่วยงานราชการแห่งหนึ่ง เพื่อให้สามารถรับข้อมูล transaction จากธนาคารและสถาบันการเงินอื่น ๆ ที่เป็นตัวแทนในการชำระภาษี กว่า 70 สถาบัน

สนใจใช้ IBM Sterling Connect:Direct ติดต่อได้ที่อีเมล Marketing@stream.co.th หรือโทร. 092-283-5904 นะคะ

0 0 Continue Reading →

ปรับกระบวนการทำงานขององค์กรอย่างไรให้ปัง – RPA นวัตกรรมตัวช่วยสุดล้ำ

ทุกวันนี้โลกของเราพัฒนาไปข้างหน้าอย่างต่อเนื่อง วิธีการทำงานของผู้คนก็เปลี่ยนแปลงไป จากแต่เดิมเราใช้แรงงานของคนในการทำงาน ก็พัฒนาสิ่งต่าง ๆ มาทดแทนและเสริมสร้างกระบวนการทำงานให้มีประสิทธิภาพสูงขึ้น ทุกวันนี้มีการใช้หุ่นยนต์ และปัญญาประดิษฐ์ (AI) เข้ามาช่วยในการทำงานของผู้คนอย่างมาก ที่เกริ่นมานี้ เพราะเรามีเทคโนโลยีหนึ่งที่อยากแนะนำให้ทุกท่านรู้จักคือ “Robotic Process Automation” หรือเรียกย่อ ๆ ว่า “RPA” ซึ่งแน่นอนว่าเทคโนโลยีนี้จะช่วยให้กระบวนทำงานของท่านเป็นระบบและง่ายขึ้น

RPA เป็น software solution ที่มีความสามารถในการทำงานแทนมนุษย์ ข้อดีหลัก ๆ ของ RPA ก็คือการลดความผิดพลาดที่เกิดจากมนุษย์ (Human Error) ลดระยะเวลาทำงานลง และทำให้ได้ผลลัพธ์ของงานในปริมาณที่มากยิ่งขึ้น โดยที่การทำงานแทนของ RPA จะทำงานบน software อื่น ๆ บนเครื่องคอมพิวเตอร์ ใช้งานร่วมกับโปรแกรมต่าง ๆ เช่น Microsoft Excel, Web browser หรือแม้กระทั่ง SAP GUI ก็สามารถใช้ได้

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

ขอยก use case เพื่อช่วยอธิบายข้อดีของ RPA ให้เห็นภาพชัด ๆ สมมติว่า ณ บริษัทหนึ่งได้มีงานประเภท Finance เยอะมาก การทำงาน Finance ในส่วนของงาน Payment Process ใช้คนในการทำงานมากกว่า 20 คน เพื่อทำงานดังกล่าวให้เสร็จสิ้นใน 1 วัน แต่หลังจากนำ RPA มาประยุกต์ใช้ในงานนี้แล้ว จะสามารถลดปริมาณคนลงเหลือเพียงไม่กี่คน เพื่อตรวจสอบข้อมูลผิดปกติ ซึ่งเป็นปัญหาให้ไม่สามารถทำงานได้ตามกระบวนการเท่านั้น

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

สำหรับองค์กรที่อยากทราบข้อมูลของ RPA ให้มากขึ้น ทางสตรีมฯ สามารถให้คำปรึกษา วางแผน ไปจนถึงติดตั้งระบบ และดูแลระบบของท่านให้ดำเนินการเป็นปกติเรียบร้อย สนใจติดต่อฝ่ายการตลาด อีเมล Marketing@stream.co.th หรือโทร. 02-679-2233

0 0 Continue Reading →

NDID มีแล้วดีอย่างไร? ใครได้รับประโยชน์บ้าง?

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

ภายใต้ระบบการพิสูจน์ตัวตนนี้ มีองค์ประกอบหลักๆ 3 ส่วนด้วยกัน ได้แก่
1. Identity Provider (IDP) ผู้ทำหน้าที่สำคัญในการเป็นผู้พิสูจน์และยืนยันตัวตน และเป็นผู้รับลงทะเบียนยืนยันการพิสูจน์ตัวตนให้กับผู้ที่จะขอใช้ข้อมูล อาทิเช่น กรมการปกครอง หรือธนาคาร เป็นต้น

2. Authoritative Source (AS) กลุ่มผู้ให้บริการข้อมูลของลูกค้าตามที่ร้องขอ เช่น ข้อมูลเครดิตแห่งชาติ, ข้อมูลธุรกรรมทางการเงิน, ข้อมูลด้านสุขภาพ เป็นต้น ซึ่งข้อมูลจะถูกตรวจสอบ ต้องผ่านสถานะการยืนยันตัวตนและยินยอมให้ใช้ข้อมูล จึงจะสามารถให้ผู้ใช้บริการเข้าถึงได้

3. Relying Party (RP) กลุ่มผู้ให้บริการในการทำธุรกรรมต่างๆ เช่น ธนาคารให้บริการเปิดบัญชี, การขอสินเชื่อ, สมัครบัตรเครดิต หรือบริษัทหลักทรัพย์ ให้บริการเปิดบัญชีซื้อขายหลักทรัพย์ เป็นต้น ซึ่งจะสามารถดึงข้อมูลในรูปแบบดิจิทัลไปใช้ได้เมื่อมีการติดตั้งระบบ NDID

ทั้งนี้ ข้อสำคัญคือการจะเข้าถึงข้อมูลต้องได้รับการยินยอมจากเจ้าของข้อมูลก่อนทุกครั้ง ล้อกับ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562

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

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

แต่หากธนาคารมีการใช้งาน NDID และทำหน้าที่เป็น IDP เพื่อจัดทำข้อมูลในการพิสูจน์และยืนยันตัวตนของลูกค้า และมีการจัดทำระบบ e-KYC ขึ้นมา ซึ่งก็มีค่าใช้จ่ายในการลงทุนทางด้านซอฟต์แวร์และฮาร์ดแวร์ ยกตัวอย่างเช่น การทำ Facial Recognition และ Hardware Security Module (HSM) แต่ความคุ้มค่าหลังจากธนาคารมีระบบนี้แล้วคือ ธนาคารเรียกใช้ข้อมูลลูกค้าระหว่างสำนักงานใหญ่กับสาขาต่างๆ ด้วย ทำให้ลูกค้าผู้ใช้งานธนาคารนั้นๆ ได้รับความสะดวกสบายเนื่องจากไม่ต้องวุ่นวายเรื่องเอกสาร และยังสามารถให้ข้อมูลที่มีการยินยอมให้ใช้งานจากลูกค้าเพื่อนำไปสร้างรายได้ เมื่อมีหน่วยงานอื่นที่มีการเชื่อมต่อเข้ากับ NDID ต้องการขอใช้ข้อมูลดังกล่าว

โดยหากลูกค้าประสงค์ที่จะเปิดบัญชีที่ธนาคารอื่นๆ ที่ยังไม่เคยมีการเปิดบัญชีมาก่อน หากธนาคารนั้นๆ มีเชื่อมต่อกับ NDID และทำหน้าที่เป็น IDP  ก็จะสามารถขอใช้ข้อมูลการพิสูจน์และยืนยันตัวตนจาก IDP ของธนาคารที่ลูกค้าเคยให้การยินยอม และขอข้อมูลเฉพาะจาก AS ได้ ทำให้ไม่ต้องเสียเวลาในการขอเอกสารจากลูกค้าใหม่ นั่นคือข้อดีของระบบ NDID

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

ในช่วงแรกของโครงการ NDID นี้ เริ่มจากในเฟสแรก ที่ธนาคารใช้เทคโนโลยี Facial Recognition ในกระบวนการ KYC เพื่อเปิดบัญชี ในปัจจุบันเราอยู่ในเฟสสอง ซึ่งเป็นการพิสูจน์และยืนยันตัวตนข้ามธนาคารผ่าน NDID หลังจากนี้มีความเป็นไปได้ที่จะต่อยอดไปสู่เรื่องของการตรวจเครดิตบูโร (National Credit Bureau: NCB) หรือ Statement นอกจากนี้ ภาครัฐยังสามารถใช้ประโยชน์จาก e-KYC และ NDID ได้อีกมาก เช่น กระทรวงสาธารณสุขสามารถนำ e-KYC ไปใช้ในการจัดทำข้อมูลสุขภาพของประชาชน เพื่อให้ประกันสามารถดึงข้อมูลไปใช้ เป็นต้น

สำหรับองค์กรที่อยากทราบข้อมูลของ NDID ให้มากขึ้น ทางสตรีมฯ สามารถให้คำปรึกษา วางแผน ไปจนถึงติดตั้งตัวระบบ และดูแลระบบของท่านให้ดำเนินการเป็นปกติเรียบร้อย เรามีประสบการณ์ในการทำ NDID ให้กับธนาคารชั้นนำ สนใจติดต่อฝ่ายการตลาด โทร. 02-679-2233 อีเมล Marketing@stream.co.th

0 1 Continue Reading →

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

Privacy Preferences

คุณสามารถเลือกการตั้งค่าคุกกี้โดยเปิด/ปิด คุกกี้ในแต่ละประเภทได้ตามความต้องการ ยกเว้น คุกกี้ที่จำเป็น

Allow All
Manage Consent Preferences
  • คุกกี้ที่จำเป็น
    Always Active

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

  • คุกกี้เพื่อการวิเคราะห์

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

Save