Final 12

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

วิทยาศาสตรมหาบัณฑิต
สาขาวิชาอุปกรณ์การแพทย์ ภาควิชาฟิ สิ กส์อุตสาหกรรมและอุปกรณ์การแพทย์
บัณฑิตวิทยาลัย มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนือ
ปี การศึกษา 2555
ลิขสิ ทธิ์ ของมหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนือ
ชื่อ : นายก้องเกียรติ มีใหญ่
ชื่อวิทยานิพนธ์ : การออกแบบและพัฒนาระบบจัดซื้ ออิเล็กทรอนิกส์สาํ หรับ
เครื่ องมือแพทย์
สาขาวิชา : อุปกรณ์การแพทย์
มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนื อ
อาจารย์ที่ปรึ กษาวิทยานิพนธ์หลัก : รองศาสตราจารย์ ดร.ชิษณุ ทศั น์ บรรลือโชคชัย
อาจารย์ที่ปรึ กษาวิทยานิพนธ์ร่วม : รองศาสตราจารย์วรี ะศักดิ์ อัศววงศ์อารยะ
ปี การศึกษา : 2555
บทคัดย่ อ
การจัดซื้ อจัดหาวัสดุและเครื่ องมือทางการแพทย์น้ นั มีส่วนสําคัญที่ช่วยตอบสนองความ
ต้องการของโรงพยาบาลอย่างยิ่ง แต่เนื่องจากในปั จจุบนั การจัดซื้ อยังประสบปั ญหาความล่าช้าและ
มีขอ้ จํากัดในการจัดซื้ อจัดหาจึงจําเป็ นต้องมีโปรแกรมเพื่อสนับสนุ นงานจัดซื้ อให้มีความรวดเร็ ว
และถู กต้องเพื่ อตอบสนองความต้องการดังกล่ าว งานวิจยั นี้ เป็ นการศึ กษาออกแบบและพัฒนา
โปรแกรมจัดซื้ อเครื่ องมือแพทย์ด้วยระบบอิเล็กทรอนิ กส์ โดยการนํากระบวนการต่างๆของงาน
จัดซื้ อตั้งแต่การขอสั่งซื้อกําหนดคุณสมบัติ คัดเลือกผูข้ ายการเสนอราคาการพิจารณาสั่งซื้ อ การออก
ใบสั่งซื้ อ และการเก็บข้อมูลให้อยู่ในรู ปแบบอิเล็กทรอนิ กส์ ทําให้สามารถทํางานได้บนอุปกรณ์
อิ เล็ก ทรอนิ ก ส์ เช่ น คอมพิ วเตอร์ โทรศัพ ท์มื อ ถื อ แท็บ เล็ ต เป็ นต้น ทั้ง นี้ ก ระบวนการทั้ง หมด
สามารถดํา เนิ น การได้ผ่า นระบบอิ นเทอร์ เ น็ ต โดยโปรแกรมจัดซื้ อเครื่ อ งมื อ แพทย์ด้วยระบบ
อิเล็กทรอนิ กส์ น้ ี ถูกออกแบบขึ้นด้วยโปรแกรมคอมพิวเตอร์ ซ่ ึ งจากการทดสอบโปรแกรมและการ
ประเมินผลจากผูใ้ ช้งานมีระดับความพึงพอใจเฉลี่ยที่ 4.52 จากคะแนนเต็ม 5 แสดงว่าระดับความพึง
พอใจของผูใ้ ช้งานที่มีต่อโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิ กส์ อยู่ในระดับสู ง
แต่อย่างไรก็ตามโปรแกรมสามารถยังปรับปรุ งและพัฒนาให้เข้ากับความต้องการเพื่อเพิ่มศักยภาพ
ของกระบวนการจัดซื้ อจัดหาให้มีความรวดเร็ วและมีประสิ ทธิ ภาพดียงิ่ ขึ้น
(วิทยานิพนธ์มีจาํ นวนทั้งสิ้ น 78 หน้า)
คําสําคัญ : โปรแกรมจัดซื้ อ จัดซื้ อเครื่ องมือแพทย์ จัดซื้ อระบบอิเล็กทรอนิกส์
อาจารย์ที่ปรึ กษาวิทยานิพนธ์หลัก
ข
Name : Mr.Gongkiat Meeyai
Thesis Title : Design and Development of the Electronic Procurement System for Medical
Equipment
Major Field : Medical Instrumentation
King Mongkut’s University of Technology North Bangkok
Thesis Advisor : Associate Professor Dr.Chissanuthat Bunluechokchai
Co-Advisor : Associate Professor Weerasak Ussawawongaraya
Academic Year : 2012
Abstract
The procurement of medical equipment is an essential part in response to hospitals’ need.
Nevertheless, most hospitals are still encountering some significant limitations such as time
constraint, high cost, etc. To eliminate those limitations and enhance the procurement process, it
is necessary to initiate a supporting tool. This research aims at studying, designing, and
developing the electronic medical procurement system as such mentioned tool. The procurement
processes including purchase requisition, vendor selection, quotation issuance, confirmation, and
purchase order, were collected in electronic formats to enable the more efficient working
processes through electronic devices such as computers, smart phones, and tablets via the internet.
This electronic medical procurement system was written by computer programming. The
evaluation of the use of this system was conducted to check the satisfaction level. The result
demonstrated that users were quite satisfied with this system (score 4.52 from the highest of 5).
Despite of many benefits and improvements, this proposed system can be adjusted and modified
to enhance the efficiency and effectiveness of overall operations.
(Total 78 pages)
Keywords : Procurement Application; Medical Equipment Procurement; Electronic

Procurement
Advisor
ค
กิตติกรรมประกาศ
วิ ท ยานิ พ นธ์ ฉ บับ นี้ สํ า เร็ จ ลุ ล่ ว งได้ จากการให้ โ อกาสและสนับ สนุ น จากหลาย ๆ ท่ า น
ขอขอบพระคุ ณ อาจารย์ที่ ป รึ ก ษารองศาสตราจารย์ ดร.ชิ ษ ณุ ท ัศ น์ บรรลื อ โชคชัย และรอง
ศาสตราจารย์วีระศักดิ์ อัศววงศ์อารยะ ที่ให้ความรู้และคําปรึ กษาในการทําวิทยานิ พนธ์เสมอมา
ขอบพระคุณคณาจารย์ทุกท่านในภาควิชาฟิ สิ กส์อุตสาหกรรมและอุปกรณ์การแพทย์
ขอขอบพระคุ ณ รองศาสตราจารย์นั น ทชัย ทองแป้ น สํ า หรั บ คํา ปรึ กษาที่ ดี เ สมอมา
ขอบพระคุณแผนกจัดซื้ อ บริ ษทั เนชัน่ แนล เฮลท์แคร์ ซิ สเต็มส์ จํากัด ในเครื อโรงพยาบาลกรุ งเทพ
ที่ ใ ห้ โ อกาสเข้า มาปฏิ บ ัติ ก ารภายในแผนก ขอบคุ ณ แผนกจัด ซื้ อ โรงพยาบาลหัว เฉี ย ว และ
โรงพยาบาลบีแคร์ แผนกเทคโนโลยีสารสนเทศ บริ ษทั เอส ซี จี จํากัด ที่ให้ความช่วยเหลือในด้าน
ข้อมูล
สุ ดท้ายนี้ขอขอบพระคุณคุณพ่อ คุณแม่ และภรรยาที่ให้กาํ ลังใจ และสนับสนุนการศึกษาที่ดี
เสมอมา
ก้องเกียรติ มีใหญ่
ง
สารบัญ
หน้า
บทคัดย่อภาษาไทย ข
บทคัดย่อภาษาอังกฤษ ค
กิตติกรรมประกาศ ง
สารบัญตาราง ช
สารบัญภาพ ซ
บทที่ 1 บทนํา 1
1.1 ความเป็ นมาและความสําคัญของปั ญหา 1
1.2 วัตถุประสงค์การวิจยั 1
1.3 ขอบเขตการศึกษาวิจยั 1
1.4 ประโยชน์ที่คาดว่าจะได้รับจากการศึกษาวิจยั 2
บทที่ 2 ทฤษฎี 3
2.1 การประกันคุณภาพ 3
2.2 เทคโนโลยีในการพัฒนาเว็ปไซต์ 5
2.3 ระบบฐานข้อมูล 6
2.4 กระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์ 12
2.5 ผลการศึกษางานวิจยั ที่เกี่ยวข้อง 15
บทที่ 3 ขั้นตอนและการดําเนินงาน 18
3.1 เครื่ องมือที่ใช้ในการวิจยั 18
3.2 ขั้นตอนการศึกษาระบบจัดซื้ อเครื่ องมือแพทย์ 18
3.3 ขั้นตอนการศึกษาปั ญหาและความต้องการจากระบบจัดซื้ อเครื่ องมือ
แพทย์ 19
3.4 การวิเคราะห์และออกแบบโปรแกรมจัดซื้ อเครื่ องมือแพทย์ 19
3.5 การทดสอบการใช้งานของโปรแกรมจัดซื้ อเครื่ องมือแพทย์ 32
บทที่ 4 ผลการวิจยั 33
4.1 ส่ วนการขอซื้ อ 33
4.2 ส่ วนการแจ้งรายละเอียดและขอเสนอราคาสั่งซื้ อ 35
4.3 ส่ วนของการเสนอราคาโดยผูข้ าย 36
4.4 ส่ วนแสดงตารางเปรี ยบเทียบและรายละเอียดจากผูข้ าย 38
จ
สารบัญ (ต่ อ)
หน้า
4.5 ส่ วนของการบันทึกข้อมูลเข้าสู่ ระบบ 40
4.6 การทดสอบระบบการทํางานของโปรแกรมจัดซื้ อเครื่ องมือแพทย์ 45
บทที่ 5 สรุ ปผลและข้อเสนอแนะ 49
5.1 สรุ ปผลการวิจยั 49
5.2 ข้อเสนอแนะ 51
บรรณานุกรม 52
ภาคผนวก ก 53
รายละเอียดของโปรแกรม 54
ภาคผนวก ข 69
ความสัมพันธ์ระหว่างข้อมูลและพจนานุกรมข้อมูล 70
ภาคผนวก ค 76
ดัชนีขอ้ มูล 77
ประวัติผวู ้ ิจยั 78
ฉ
สารบัญตาราง
ตารางที่ หน้า
3-1 ตารางรายละเอียดกระบวนการของการสร้างคําร้องขอซื้ อ 23
3-2 ตารางรายละเอียดกระบวนการของขั้นตอนการสร้างคําร้องขอซื้อ 25
3-3 ตารางรายละเอียดกระบวนการของการยืนยันการอ่านข้อมูลคําร้องขอซื้ อ 26
3-4 ตารางรายละเอียดกระบวนการแก้ไขคําร้องขอซื้ อ 27
3-5 ตารางรายละเอียดกระบวนการการแสดงใบเสนอราคา 28
3-6 ตารางรายละเอียดกระบวนการส่ งใบคําร้องขอซื้อไปยังผูข้ าย 29
3-7 ตารางรายละเอียดกระบวนการการส่ งใบเสนอราคาของผูข้ าย 30
ข-1 ตารางแสดงบทบาท (Roles) 71
ข-2 ตารางแสดงผูใ้ ช้งาน (Users) 71
ข-3 ตารางแสดงผูข้ าย (Vendor) 71
ข-4 ตารางแสดงผูข้ ายที่ได้รับการคัดเลือกให้เสนอราคา (Order Vendors) 72
ข-5 ตารางแสดงรายละเอียดคุณสมบัติหลัก (Order Main Specification) 72
ข-6 ตารางแสดงรายการสั่งซื้อ (Orders) 72
ข-7 ตารางแสดงรายละเอียดจากการเสนอราคา (Offer) 73
ข-8 ตารางแสดงรายละเอียดจากการเสนอราคาเฉพาะคุณสมบัติหลัก (Offer Main
Specification) 74
ข-9 ตารางแสดงชื่อ (Title) 74
ข-10 ตารางแสดงยีห่ ้อแนะนําที่จดั เก็บในระบบ (Brand Prefer) 74
ข-11 ตารางแสดงยีห่ ้อที่ผขู ้ อซื้ อแนะนํา (Order Brand Prefer) 74
ช
สารบัญภาพ
ภาพที่ หน้า
2-1 แสดงฐานข้อมูลการขายสิ นค้า 7
2-2 แสดงองค์ประกอบของระบบฐานข้อมูล 8
2-3 แสดงตารางบันทึกข้อมูลลูกค้า 9
2-4 แสดงความสัมพันธ์แบบ 1-1 10
2-5 แสดงความสัมพันธ์แบบ 1-M 10
2-6 แสดงความสัมพันธ์แบบ M-N 11
3-1 โครงสร้างและกระแสข้อมูลของระบบจัดซื้ อเครื่ องมือแพทย์ 18
3-2 ตัวอย่างแผนภาพแสดงกระแสข้อมูลโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ย
ระบบอิเล็กทรอนิกส์โดยแบ่งเป็ นระดับ 20
3-3 แผนภาพกระแสข้อมูลระดับสู งสุ ดโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบ
อิเล็กทรอนิกส์ 20
3-4 แผนภาพกระแสข้อมูลระดับที่ 1 21
3-5 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 1 การสร้างคําร้อง
ขอซื้ อ 23
3-6 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของกระบวนการที่ 1.1 ขั้นตอนการ
สร้างคําร้องขอซื้อ 24
3-7 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของกระบวนการที่ 1.2 การอ่านข้อมูล
คําร้องขอซื้อ 26
3-8 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 กระบวนการที่ 2 แก้ไขคําร้องขอซื้ อ 27
3-9 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 3 การแสดงใบ
เสนอราคา 28
3-10 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 4 การส่ งใบคําร้อง
ขอซื้ อไปยังผูข้ าย 29
3-11 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 5 การส่ งใบเสนอ
ราคาของผูข้ าย 30
3-12 โครงสร้างการทํางานของโปรแกรมจัดซื้ อเครื่ องมือแพทย์ 31
4-1 ตัวอย่างหน้าจอสําหรับลงชื่อเข้าสู่ ระบบ 33
ซ
สารบัญภาพ (ต่ อ)
ภาพที่ หน้า
4-2 ตัวอย่างหน้าจอส่ วนการขอซื้อ 34
4-3 ตัวอย่างหน้าจอสําหรับตรวจสอบรายละเอียด คัดเลือกผูข้ ายและแจ้งเสนอ
ราคาให้กบั ผูข้ าย 36
4-4 ตัวอย่างจดหมายอิเล็กทรอนิ กส์ที่ผขู ้ ายจะได้รับจากระบบ 37
4-5 ตัวอย่างหน้าจอสําหรับให้ผขู ้ ายกรอกข้อมูลและเสนอราคา 37
4-6 ตัวอย่างหน้าจอแสดงการเปรี ยบเทียบข้อมูลต่างๆ เพื่อเลือกซื้ อเครื่ องมือ 39
4-7 ตัวอย่างใบสั่งซื้อที่ระบบทําการส่ งให้กบั ผูข้ าย 40
4-8 ตัวอย่างส่ วนของการบันทึกข้อมูลเข้าสู่ ระบบ 41
4-9 ตัวอย่างการบันทึกค่าประเภทผูใ้ ช้งาน 42
4-10 ตัวอย่างการบันทึกข้อมูลชื่อรายการคําขอซื้ อ 43
4-11 ตัวอย่างการบันทึกข้อมูลยีห่ ้อแนะนํา 44
4-12 ตัวอย่างการบันทึกข้อมูลผูข้ าย 45
4-13 แบบสํารวจความพึงพอใจในการใช้โปรแกรมจัดซื้ อเครื่ องมือแพทย์ 46
ข-1 ความสัมพันธ์ระหว่างข้อมูล 70
ฌ
บทที่ 1
บทนํา
1.1 ความเป็ นมาและความสํ าคัญของปัญหา

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

1.2.1 เพื่อจัดทําระบบจัดซื้ อเครื่ องมือแพทย์ที่มีประสิ ทธิ ภาพมากยิ่งขึ้น ด้วยโปรแกรมจัดซื้ อ
เครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์
1.2.2 เพื่อลดต้นทุนและกระบวนการของระบบจัดซื้ อให้มีความรวดเร็ วยิง่ ขึ้น
1.2.3 เพื่อพัฒนาระบบการเก็บข้อมูลจัดซื้ อเครื่ องมือแพทย์ให้ง่ายและสะดวกในการใช้งาน
1.3 ขอบเขตการศึกษาวิจัย
1.3.1 เก็ บ รวบรวมข้อมู ล และสั ง เกตการณ์ ท าํ งานของการจัดซื้ อ เครื่ องมื อแพทย์ใ นแต่ ล ะ
ขั้นตอนเพื่อศึกษากระบวนการจัดซื้ อ
2
1.3.2 ออกแบบและสร้างโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์ และพัฒนา

ระบบการเก็บข้อมูลจัดซื้ อเครื่ องมือแพทย์
1.4 ประโยชน์ ทคี่ าดว่ าจะได้ รับจากการศึกษาวิจัย

1.4.1 สามารถนําไปเพิ่มประสิ ทธิ ภาพในกระบวนการจัดซื้ อเครื่ องมือแพทย์ทาํ ให้เกิ ดความ
สะดวก รวดเร็ วยิง่ ขึ้น
1.4.2 ลดต้นทุนและทรัพยากรที่ใช้ในกระบวนการจัดซื้ อเครื่ องมือแพทย์
บทที่ 2
ทฤษฎี
2.1 การประกันคุณภาพโรงพยาบาล (Hospital Accreditation , HA) (สิ ทธิศกั ดิ์, 2543)

2.1.1 โรงพยาบาลกับการประกันคุณภาพของประเทศไทยคือ ลักษณะโดยรวมของสิ่ งต่างๆ ที่
แสดงออกมาซึ่ งสามารถในการที่จะตอบสนองต่อความต้องการของลูกค้า หรื อผูใ้ ห้บริ การโดยรวม
ซึ่งระบุโดยชัดแจ้งหรื อที่ควรเป็ น
2.1.2 มาตรฐานทัว่ ไป เป็ นมาตรฐานที่แสดงหลักการสําคัญการจัดบริ การ หรื อการบริ หาร
หน่วยงานครอบคลุ มในเรื่ องทิศทางการทํางานที่ชดั เจน ทรัพยากรที่เหมาะสม ระบบงานหรื อ
กระบวนการทํางานที่เหมาะสม ระบบการติดตามประเมินคุณภาพซึ่ งจะเป็ นตัวสะท้อนการทํางาน
และนําไปสู่ กิจกรรมการพัฒนาอย่างต่อเนื่ อง มาตรฐานนี้ มุ่งหมายที่จะเป็ นพื้นฐานสําคัญในการ
ประเมินการจัดการบริ หารผูป้ ่ วยในสาขาต่างๆ เช่น บริ การผูป้ ่ วยอายุรกรรม บริ การผูป้ ่ วยศัลยกรรม
ซึ่ งเกี่ยวข้องกับการทํางานหลายหน่วยงาน และประเมินการให้บริ การเฉพาะหน่วยงาน มาตรฐาน
ทัว่ ไปมี 9 ข้อดังนี้
2.1.2.1 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 1 (GEN.1) พันธกิ จ เป้ าหมาย และ
วัตถุประสงค์ เป็ นการกําหนดพันธกิจ ปรัชญา ขอบเขต เป้ าหมาย แลวัตถุประสงค์ของการจัดการ
บริ หาร หรื อของหน่วยงานเป็ นลายลักษณ์อกั ษรอย่างชัดเจน
2.1.2.2 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 2 (GEN.2) การจัดรู ปแบบองค์กร และการ
บริ หารในลักษณะที่เอื้อต่อการให้บริ การต่อผูป้ ่ วย ตามพันธกิจที่กาํ หนดไว้อย่างมีคุณภาพ และ
ประสิ ทธิ ภาพ
2.1.2.3 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 3 (GEN.3) การจัดการทรัพยากรบุคคลมี
การจัดทรัพยากรบุคคล เพื่อให้บริ การผูป้ ่ วยได้ตามพันธกิ จที่กาํ หนดไว้อย่างมีคุณภาพ และมี
2.1.2.4 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 4 (GEN.4) การพัฒนาทรัพยากรบุคคลมี
การเตรี ยมความพร้อม การเพิ่มพูนความรู ้และทักษะ เพื่อให้เจ้าหน้าที่ปฏิบตั ิหน้าที่ได้อย่างมีคุณภาพ
2.1.2.5 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 5 (GEN.5) นโยบาย และวิธีปฏิบตั ิ มี
นโยบายและวิธีปฏิบตั ิเป็ นลายลักษณ์อกั ษร ซึ่ งสะท้อนความรู้ และหลักการของวิชาชีพที่ทนั สมัย
4
สอดคล้องกับพันธกิจในการให้บริ การผูป้ ่ วย และกฎระเบียบที่เกี่ยวข้อง และเจ้าหน้าที่ยึดถือเป็ น

แนวทางปฏิบตั ิ
2.1.2.6 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 6 (GEN.6) สิ่ งแวดล้อม อาคาร สถานที่ มี
สิ่ งแวดล้อมอาคาร สถานที่ เอื้ออํานวยต่อการให้บริ การอย่างสะดวก ปลอดภัย มีคุณภาพและ
2.1.2.7 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7 (GEN.7) เครื่ องมือ อุปกรณ์ และสิ่ ง
อํานวยความสะดวก มีเครื่ องมือ อุปกรณ์และสิ่ งอํานวยความสะดวกที่ได้มาตรฐาน เพื่อให้บริ การ
ผูป้ ่ วยได้อย่างปลอดภัย มีคุณภาพและประสิ ทธิ ภาพ
2.1.2.8 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 8 (GEN.8) ระบบงาน หรื อกระบวนการ
ให้บริ การ มีระบบงานหรื อกระบวนการให้บริ การที่มีประสิ ทธิ ภาพตามมาตรฐานวิชาชี พ และ
ตอบสนองความต้องการของผูป้ ่ วยแต่ละราย
2.1.2.9 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 9 (GEN.9) กิจกรรมพัฒนาคุณภาพ มี
กิจกรรมติดตามประเมินและพัฒนาคุณภาพของหน่วยงาน หรื อบริ การ โดยทํางานเป็ นทีม และมี
การพัฒนาอย่างต่อเนื่อง
2.1.3 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7 (GEN.7) ตามข้อกําหนดมาตรฐานทัว่ ไปข้อที่ 7 มี
ข้อกําหนดดังนี้
2.1.3.1 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7.1 (GEN.7.1) มีหลักเกณฑ์ กลไกในการ
คัดเลื อกเครื่ องมื อ และอุ ปกรณ์ ที่จาํ เป็ นในการให้บริ การ ซึ่ งหลักเกณฑ์กลางการคัดเลือกจัดซื้ อ
จัดหาเครื่ องมือตาม HA
2.1.3.1.1 เป็ นเครื่ องมื อที่ มี คุณสมบัติตรงกับวัตถุ ป ระสงค์ของผูใ้ ช้ง านและ
ผูเ้ กี่ยวข้อง (แพทย์, ทันตแพทย์, เภสัชกร, พยาบาลและเจ้าหน้าที่อื่นๆ)
2.1.3.1.2 บริ ษทั ตัวแทนจําหน่ายและผลิตภัณฑ์ได้ตามมาตรฐาน
2.1.3.1.3 บริ ษทั ตัวแทนจําหน่ ายต้องเป็ นตัวแทนจําหน่ายโดยตรงโดยได้รับ
การแต่งตั้งจากบริ ษทั ผูผ้ ลิตหรื อตัวแทนจําหน่าย และมีประวัติในการบริ การหลังการขายดี มีความ
รับผิดชอบสู ง
2.1.3.1.4 บริ ษทั ตัวแทนจําหน่ายต้องทําการเทียบมาตรฐาน (Calibrate) เครื่ อง
ให้ 2 ครั้ง/ปี ในปี แรก หรื อ จ่ายค่าการเทียบมาตรฐานให้แทน
2.1.3.1.5 บริ ษ ทั ตัว แทนจํา หน่ า ยต้องทํา การรั บ ประกัน การซ่ อ มบํา รุ ง หรื อ
ความเสี ยหายของเครื่ องมือใน 1 ปี แรกฟรี และมีการสํารองอะไหล่ไว้ให้อย่างน้อย 5 ปี
5
2.1.3.1.6 อุ ป กรณ์ ที่ เ ป็ นเครื่ อ งใช้ไ ฟฟ้ าชนิ ด ที่ มี ค วามละเอี ย ดอ่ อ นในการ
ทํางานและต้องทํางานตลอดเวลาเมื่อไฟฟ้ าเกิดขัดข้องอาจทําให้เกิ ดผลเสี ยต่อผูป้ ่ วยต้องมีเครื่ อง
สํารองกระแสไฟฟ้ า (UPS) แถมมากับเครื่ อง
2.1.3.1.7 ราคาสมเหตุสมผลเมื่อเทียบกับคุณภาพและคุณสมบัติของเครื่ องมือ
นั้นๆ
2.1.3.1.8 ห้ามมีการกําหนดคุณสมบัติเฉพาะเจาะจงในเครื่ องมือยี่ห้อใดๆ เป็ น
การเฉพาะ (Locked Spec)
2.1.3.2 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7.2 (GEN.7.2) มีเครื่ องมือ และวัสดุ
อุปกรณ์เพียงพอสําหรับการปฏิบตั ิงาน โดยที่
2.1.3.2.1 แต่ละหน่วยงาน จะมีจาํ นวนเครื่ องมือพื้นฐานที่จาํ เป็ นต่อผูป้ ่ วยตาม
หลักเกณฑ์ของการพัฒนาระบบเครื อข่ายบริ การสุ ขภาพเดิม
2.1.3.2.2 แต่ ล ะหน่ ว ยงานจะทํา การสํ า รวจและประเมิ น เครื่ อ งมื อ ภายใน
หน่ วยงานว่ามี พ อเพียงต่ อผูป้ ่ วยหรื อไม่ โดยแต่ ละหน่ วยงานจะต้องทํา แผนจัดซื้ อเครื่ องมื อเพื่อ
ทดแทนเครื่ องมือที่ชาํ รุ ด และเครื่ องมือใหม่เพื่อให้พอเพียงต่อการบริ การผูป้ ่ วยที่เพิม่ มากขึ้นทุกปี
2.1.3.3 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7.3 (GEN.7.3) ผูใ้ ช้เครื่ องมือพิเศษมีการ
อบรมเฉพาะ
2.1.3.4 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7.4 (GEN.7.4) มีระบบสํารองเครื่ องมือ
และวัสดุทางการแพทย์ที่จาํ เป็ น พร้อมที่จะใช้ในการให้บริ การได้ตลอดเวลา
2.1.3.5 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7.5 (GEN.7.5) มีระบบบํารุ งรักษา
เครื่ องมือแพทย์ที่มีประสิ ทธิ ภาพ
2.1.3.6 ข้อกําหนดของมาตรฐานทัว่ ไปข้อที่ 7.6 (GEN.7.6) มีระบบตรวจสอบ เพื่อ
เตรี ยมเครื่ องมือ และอุปกรณ์ให้พร้อมที่จะใช้งานได้ตลอดเวลา
2.2 เทคโนโลยีในการพัฒนาเว็ปไซต์ (Technology for Website Development) (กรี วธุ , 2555)

ในปั จจุบนั นี้มีเทคโนโลยีที่สนับสนุ นภาษาคอมพิวเตอร์ ที่ใช้ในการสร้างเว็ปไซต์ (Website)
มากมายให้ เ ลื อ ก โดยแต่ ล ะชนิ ด มี รู ปแบบแตกต่ า งกั น ไป รวมถึ ง ขึ้ นอยู่ ก ั บ ลั ก ษณะของ
ภาษาคอมพิ วเตอร์ ที่ เ ลื อกใช้ ซึ่ งเอเอสพี ดอทเน็ ท (ASP.NET) เป็ นหนึ่ ง ในเทคโนโลยีสํ า หรั บ
พัฒนาเว็ปไซต์ที่นิยมใช้กนั อย่างแพร่ หลายในปัจจุบนั
6
2.2.1 เอเอสพีดอทเน็ท (ASP.NET)

เอเอสพีดอทเน็ท คือ เฟรมเวิร์ค (Framework) ที่ใช้ในการสร้างเว็ปไซต์หรื อเว็ปแอพพลิเคชัน่
(Web Application) โดยเฟรมเวิร์ค นั้นจะหมายถึ งแพล็ ตฟอร์ ม (Platform) ที่ ประกอบไปด้วย
เครื่ องมือ รวมถึงไลบรารี (Library) ต่างๆ ที่ใช้ในการพัฒนาโปรแกรม
2.2.2 ข้อดีของเอเอสพีดอทเน็ท
2.2.2.1 ง่ายต่อการเขียนโค้ดเพราะมีการจัดการกับคําสั่งต่างๆ ที่ดี
2.2.2.2 มีเครื่ องมีต่างๆ ช่วยสนับสนุนทําให้การสร้างเว็ปไซต์เป็ นเรื่ องง่าย
2.2.2.3 มีระบบการติดต่อและจัดการกับฐานข้อมูลที่ดี
2.2.2.4 มีความยืดหยุ่นสู ง รวมถึงมีการแบ่งหน้าออกเป็ นส่ วนของการออกแบบและ
โค้ด ทําให้ง่ายต่อการออกแบบและเขียนโค้ดไปพร้อมๆ กัน
2.2.2.5 รองรับซิ ลเวอร์ไลท์ (Silverlight) เพื่อที่สร้างเว็ปไซต์ให้มีลูกเล่นต่างๆ
2.2.2.6 มีเครื่ องมือในการพัฒนาที่ดีเยีย่ มอย่างวิชวลสตูดิโอ (Visual Studio) ให้ใช้งาน
2.2.2.7 มีไลบรารี ต่างๆ ให้เลือกใช้มากมาย
2.2.2.8 สามารถเลือกใช้ภาษาซี ชาร์ ฟ (C#) หรื อ วีบีดอทเน็ท (VB.Net)
2.2.2.9 รองรับแอลไอเอ็นคิว (LINQ), เอ็นตีต้ ี เอสคิวแอล (Entity SQL), ไดนามิค
ดาต้า (Dynamic Data) ที่ช่วยให้การจัดการกับข้อมูลเป็ นเรื่ องง่ายและยืดหยุน่
2.2.2.10 สามารถทําให้การสร้ าง เว็ปเซอร์ วิส (Web Service) รวมถึ งติดต่อกับเว็ป
เซอร์ วสิ เป็ นเรื่ องง่าย
2.2.2.11 มีเครื่ องมือที่ช่วยในการออกแบบหน้าเว็ปเพจ (Webpage) อย่างเอกซ์เพรสชัน่
เบลน (Expression Blend) ทําให้การออกแบบเป็ นเรื่ องง่าย
2.3 ระบบฐานข้ อมูล (Database)

พันจันทร์ (2548) กิตติ (2546) กล่าวว่า ฐานข้อมูล คือ ที่อยูข่ องข้อมูลที่มีความสัมพันธ์กนั
หรื ออาจจะเปรี ยบเทียบเป็ นคลังของข้อมูลก็ได้ขอ้ มูลเหล่านี้ จะถูกจัดเก็บรวมกันอย่างมีระบบและ
รู ปแบบ ทําให้ง่ายต่อการประมวลผลและการจัดการ โดยปกติการใช้งานจะต้องมีโปรแกรมเพื่อการ
จัดการฐานข้อมูลที่มีอยูซ่ ่ ึ งเรี ยกว่า Database Management System (DBMS) สําหรับฐานข้อมูลที่
ได้รับความนิ ยมมากที่สุดในปั จจุบนั จะเป็ นแบบ Relational Database ซึ่ งการจัดเก็บข้อมูลอยูใ่ นรู ป
ของตาราง โดยที่ขอ้ มูลในแต่ละ ตารางจะมีความสัมพันธ์ซ่ ึ งกันและกัน
7
ฐานข้อมูล (Database)
ใบกํากับสิ นค้า
สิ นค้า พนักงานขาย ลูกค้า
รายการขาย
ภาพที่ 2-1 แสดงฐานข้อมูลการขายสิ นค้า
ตัวอย่างดังภาพที่ 2-1 แสดงฐานข้อมูลการขายสิ นค้า ซึ่ งประกอบไปด้วยตารางใบกํากับ

สิ นค้า รายการขาย ลูกค้า สิ นค้า และพนักงานขายตามลําดับ จะสังเกตว่าในแต่ละตารางจะมี
ความสัมพันธ์ซ่ ึ งกันและกัน และตารางที่ถูกจัดเก็บในฐานข้อมูลจะเป็ นข้อมูลที่มีความสัมพันธ์กนั
เท่านั้น ข้อมูลใดที่ไม่เกี่ยวข้องจะถูกแยกไปในฐานข้อมูลอื่นที่ไม่เกี่ยวข้องกัน
2.3.1 องค์ประกอบของระบบฐานข้อมูล (Database System) ระบบฐานข้อมูลจะประกอบไป
ด้วย ฐานข้อมูล (Database) ระบบจัดการฐานข้อมูล (Database Management System หรื อ DBMS)
และData Dictionary โดยที่ฐานข้อมูลจะเป็ นที่จดั เก็บข้อมูลต่างๆ ที่เกี่ยวข้องไว้ดว้ ยกัน มี DBMS
ทําหน้าที่จดั การกับฐานข้อมูลดังกล่าและโครงสร้างของฐานข้อมูลจะถูกเก็บไว้ใน Data Dictionary
ระบบฐานข้อมูลจะต้องประกอบด้วย 3 ส่ วน คือ ฐานข้อมูล, DBMS และ Data Dictionary แต่
สําหรับฐานข้อมูลนั้นจะประกอบด้วยตารางและความสัมพันธ์ระหว่างตาราง และเป็ นส่ วนหนึ่งของ
ระบบฐานข้อมูล แสดงดังภาพที่ 2-2
8
ภาพที่ 2-2 แสดงองค์ประกอบของระบบฐานข้อมูล
สําหรับ DBMS นับว่าเป็ นส่ วนสําคัญในระบบฐานข้อมูลเป็ นอย่างยิ่ง เปรี ยบเสมือนผูจ้ ดั การ

ฐานข้อมูล ทําหน้าที่เป็ นตัวกลางระหว่างผูใ้ ช้งานกับฐานข้อมูล โดยที่ DBMS จะรับคําสั่งจาก
ผูใ้ ช้ง านหรื อ จากโปรแกรมต่ า งๆ หลัง จากนั้นจะทํา การประมวลผลกับ ฐานข้อ มูล โดยอาศัย
โครงสร้างที่จดั เก็บไว้ใน Data Dictionary (โครงสร้างของฐานข้อมูลเหล่านี้จะเรี ยกว่า Meta Data)
และทําหน้าที่ส่งผลลัพธ์ที่ได้กลับคืนไปยังผูใ้ ช้งาน หรื อโปรแกรมโดยที่ผใู ้ ช้งานไม่จาํ เป็ นต้องรู้เลย
ว่า DBMS จัดเก็บข้อมูลอย่างไร มีกลไกในการเข้าถึงหรื อค้นหาข้อมูลอย่างไร ขอเพียงรู้คาํ สั่งที่
ต้องการสั่งงานเพื่อให้ได้ผลลัพธ์ที่ตอ้ งการเท่านั้น ที่เหลือเป็ นหน้าที่ของ DBMS ในการดึงข้อมูล
หรื อการประมวลผลต่างๆ ดังนั้น สําหรับผูใ้ ช้งานจะรู้สึกว่าการใช้งาน DBMS ทําได้อย่างง่ายดาย
เพราะ DBMS จะซ่ อนความยุง่ ยากในการเข้าถึงข้อมูลไว้เอง สําหรับ DBMS ที่ได้รับความนิยม
สู งสุ ดในปั จจุบนั จะเรี ยกว่า Relational DBMS (RDBMS) ซึ่ ง RDBMS นี้ จะมีให้เลือกใช้งาน
มากมายทั้งแบบใช้งานคนเดียวหรื อหลายคนพร้อมๆกัน เช่น MS Access, FoxPro, Paradox เป็ นต้น
จนถึงระดับ Sever ที่เรี ยกว่า Database Sever เช่น SQL Sever, Oracle, Informix, Sybase เป็ นต้น
2.3.2 รายละเอียดภายในฐานข้อมูล
2.3.2.1 ตาราง (Table)
เป็ นที่จดั เก็บข้อมูล (บางส่ วน) ของฐานข้อมูล โดยปกติในฐานข้อมูลหนึ่ง จะประกอบไป
ด้วยหลายๆ ตารางรวมกัน โดยที่ตารางจะประกอบไปด้วยเรคอร์ ด และฟิ ลด์ แสดงตารางลูกค้าซึ่ ง
ประกอบไปด้วยฟิ ลด์ท้ งั สิ้ น 5 ฟิ ลด์ได้แก่ รหัสลูกค้า (Customer Id), คํานําหน้า (Title), ชื่ อ (First
9
Name), นามสกุล (Last Name) และเบอร์ โทรศัพท์ (Telephone) และมีท้ งั สิ้ น 4 เรคอร์ ด เป็ นต้น
แสดงโครงสร้างของส่ วนประกอบต่างๆ ดังภาพที่ 2-3
ฟิ ล์ด (Field)
ชื่อฟิ ล์ด Customer ID Title Name Last name Telephone

A02568 นาย สมพงษ์ ทองวิวฒั น์ 089-991-xxxx
เรคอร์ด A02875 นาง ปราณี ทองวิวฒั น์ 089-997-xxxx
(Record) B01782 นาย คงศักดิ์ เอกชัย 081-552-xxxx
B02548 นาย สมบูรณ์ รัศมี 089-449-xxxx
ภาพที่ 2-3 แสดงตารางบันทึกข้อมูลลูกค้า
2.3.3 Structured Query Language (SQL)

เป็ นภาษามาตรฐานที่ใช้ในการจัดการฐานข้อมูล เช่น การเรี ยกค้นข้อมูล การเพิ่มเติมแก้ไข
หรื อลบข้อมูลที่มีอยู่ ส่ วนใหญ่จะใช้ใน Relational Database
2.3.4 คิวรี (Query) เป็ นการเรี ยกค้นข้อมูลที่ตอ้ งการ ส่ วนใหญ่จะใช้ SQL เป็ นภาษาในการ
คิวรี
2.3.5 เรคอร์ ดเซต (Record Set) เป็ นกลุ่มของข้อมูลที่ได้จากการทําคิวรี สําหรับเรคอร์ ดเซตที่
ได้ สามารถนําไปประมวลผลต่อไปได้
2.3.6 อินเด็กซ์ (Index) คือ การทําดัชนีของข้อมูลเพื่อให้การค้นหาข้อมูลทําได้อย่างรวดเร็ ว
โดยที่อินเด็กซ์สามารถประกอบไปด้วยหลายๆ ฟิ ลด์รวมกันหรื อเพียงฟิ ลด์เดียวก็ได้
2.3.7 ไพรมารี่ ย ์ คีย ์ (Primary Key) เป็ นตัวแทนของเรคอร์ ดในตารางเพื่อใช้ในการเข้าถึง
ข้อมูล ซึ่ งค่าของ Primary Key ใน เรคอร์ ดหนึ่งๆ จะต้องไม่ซ้ าํ กับเรคอร์ ดอื่นในตาราง โดย ปกติจะ
ใช้ฟิลด์ที่ทาํ อินเด็กซ์มาเป็ น Primary Key
2.3.8 ฟอร์ เรนจ์ คีย ์ (Foreign Key) คือฟิ ลด์ที่อยูใ่ นตารางหนึ่ง (อาจเป็ นหลายฟิ ลด์ก็ได้) เพื่อใช้
อ้างอิงถึงข้อมูลในอีกตารางหนึ่ ง ซึ่ งฟิ ลด์ที่ใช้เป็ น Foreign Key มักจะเป็ น Primary Key ของอีก
ตารางที่มีความสัมพันธ์กนั
2.3.9 ความสัมพันธ์ระหว่างตาราง (Relationship) ซึ่ งประกอบด้วยความสัมพันธ์แบบ 1:1
(One – To – One), 1:M (One – To – Many) และ M:M (Many – To – Many) สําหรับทุกตารางใน
10
ฐานข้อมูลจะต้องมีฟิลด์เพื่อเชื่ อมความสัมพันธ์ระหว่างตาราง และเรี ยกฟิ ลด์น้ ี วา่ Foreign Key

สําหรับตัวอย่างที่ใช้อธิ บายถึงความสัมพันธ์แบบต่างๆ ต่อไปนี้ประกอบไปด้วย 2 ส่ วน คือ
2.3.9.1 รู ปแสดงความสัมพันธ์ซ่ ึ งจะแสดงโครงสร้ างของตารางต่างๆ รวมถึ งความ
สัมพันธ์ระหว่างตารางด้วย สําหรับหมายเลขกํากับเส้น (1, M หรื อ N) จะหมายถึงความสัมพันธ์จาก
ตารางหนึ่งไปยังตารางหนึ่ง
2.3.9.2 ตัวอย่างข้อมูลในตาราง
2.3.9.2.1 ความสัมพันธ์แบบ 1:1 เป็ นความสัมพันธ์ที่ในหนึ่ งเรคอร์ ดของ
ตารางหนึ่ งมีความสัมพันธ์กบั อีกเรคอร์ ดของตารางอื่นสําหรับบริ ษทั ทัว่ ไป แผนกหนึ่งสามารถมี
หัวหน้าแผนกได้เพียงคนเดียวเท่านั้น ดังนั้นความสัมพันธ์ระหว่างตารางแผนกกับตารางพนักงานจึง
เป็ นความสัมพันธ์แบบ 1:1 แสดงดังภาพที่ 2-4
หัวหน้ าแผนก
ภาพที่ 2-4 แสดงความสัมพันธ์แบบ 1-1
2.3.9.2.2 ความสัมพันธ์แบบ 1:M เป็ นความสัมพันธ์ที่ในหนึ่ งเรคอร์ ดของ

ตารางหนึ่ งมีความสัมพันธ์กบั อีกหนึ่ งหรื อหลายเรคอร์ ดของตารางอื่น ดังภาพที่ 2-5 ลูกค้าหนึ่ งคน
สามารถสั่งสิ นค้าได้หลายครั้งและใบกํากับสิ นค้าหนึ่ งใบก็สามารถมีลูกค้าได้เพียงคนเดียวเท่านั้น
ดังนั้นความสัมพันธ์ระหว่างตารางลูกค้ากับใบกํากับสิ นค้า จึงเป็ นความสัมพันธ์แบบ 1:M
ซื ้อ
ภาพที่ 2-5 แสดงความสัมพันธ์แบบ 1-M

11
2.3.9.2.3 ความสัมพันธ์แบบ M:N เป็ นความสัมพันธ์ที่ขอ้ มูลหนึ่ งหรื อหลายเร

คอร์ ดในตารางหนึ่ งมีความสัมพันธ์กบั หนึ่ งหรื อหลายเรคอร์ ดในตารางอื่น ดังภาพที่ 2-6 สําหรับ
ลูกค้าคนหนึ่งสามารถซื้ อสิ นค้าได้หลายรายการ และสิ นค้าหนึ่ งรายการสามารถถูกซื้ อโดยลูกค้า
หลายคนเช่นกัน ซึ่ งความสัมพันธ์ลกั ษณะนี้จะเรี ยกว่าความสัมพันธ์แบบ M:N
089-991-xxxx
089-997-xxxx
081-552-xxxx
089-449-xxxx
ภาพที่ 2-6 แสดงความสัมพันธ์แบบ M-N
2.3.10 โปรแกรมต่อประสานการประยุกต์เอสคิวแอล (SQL Application Program Interfaces)

โปรแกรมต่อประสานการประยุกต์เอสคิวแอล เอสคิวแอลเป็ นภาษาเชิ งโครงสร้างมีความ
ใกล้เคียงภาษาเขียนมนุ ษย์มาก จึงมีการนํารู ปแบบของภาษาเอสคิวแอลไปใช้ในงานร่ วมกับภาษา
โปรแกรมมิ่ง ซึ่ งจะมีอยู่ 2 รู ปแบบคือ ภาษาเอสคิวแอลแบบฝังตัว (Embedded SQL) เอสคิวแอลซี
แอลไอ (SQL CLI : Structure Query Language Call Level Interface) ภาษาเอสคิวแอลแบบฝังตัว
หรื ออีเอสคิวแอล เป็ นมาตรฐานไอเอสโอ เอสคิวแอล 92 (ISO SQL-92) ที่กาํ หนดรู ปแบบการฝัง
ตัวสเตทเมนต์เอสคิวแอล ลงในภาษาซี ปาสคาล โคบอล ฟอร์ แทรน เอดีเอ ฯลฯ ส่ วนเอสคิวแอลซี
แอลไอ เป็ นมาตรฐานของหน่วยงานเอสเอจี (SAG : SQL Access Group) ที่กาํ หนดฟังก์ชนั่ ในการ
เรี ยกใช้ภาษาเอสคิวแอลได้โดยตรงจากโปรแกรมแอพพลิเคชัน่ จึงไม่มีการฝังตัว (Embedded) ส่ วน
ของภาษาเอสคิวแอลลงไปภาษาสื บค้นที่มีลกั ษณะเป็ นโครงสร้ าง (SQL : Structure Query
Language) ภาษาสื บค้นที่มีลกั ษณะเป็ นโครงสร้าง หรื อที่นิยมเรี ยกว่าเอสคิวแอล (SQL) หรื อ ซี
เควล เป็ นภาษาสําหรับดําเนิ นการกับฐานข้อมูลเชิ งสัมพันธ์ โดยที่ผใู้ ช้ไม่ตอ้ งระบุข้ นั ตอนการ
ทํางานให้กบั ระบบ เพียงแต่ระบุวา่ ต้องการข้อมูลอะไร ระบบจะดําเนินการค้นหาข้อมูลที่ตรงตาม
เงื่ อนไขที่ ผูใ้ ช้กาํ หนดเอสคิ วแอลได้ถูกกําหนดให้เป็ นมาตรฐานของระบบจัดการฐานข้อมูลเชิ ง
สัมพันธ์ โดยที่ เอเอ็นเอสไอ (ANSI : American National Standards Institute) ได้จดั ตั้ง
คณะกรรมการขึ้ น เพื่ อพัฒนามาตรฐานสํา หรั บ ภาษาเอสคิ วแอล และออกมาตรฐานมาในปี
12
พ.ศ.2530 การใช้ง านเอสคิ วแอลอาจจะอยู่ใ นรู ป ของการทํา งานสื บ ค้นข้อมู ล โดยโต้ตอบกับ

ฐานข้อมูลโดยตรง (Dynamic SQL) หรื อใช้เอสคิวแอลเป็ นส่ วนหนึ่งในโปรแกรมที่เขียนด้วยคําสั่ง
ฝังตัวเอสคิวแอล (Embedded SQL) เช่น ภาษาซี (C Language) ปาสคาล (Pascal) ฟอร์ แทรน
(Fortran) และโคบอล (Cobol) เมื่อพิจารณาชุดคําสั่งที่มีอยูใ่ นภาษาเอสคิวแอล สามารถจัดกลุ่มของ
คําสั่งตามลักษณะการทํางานได้เป็ น 2 กลุ่มหลักคือ คําสั่งที่ใช้ในการจัดการโครงสร้างข้อมูล (DD/D
: Data Dictionary/Directory) หรื อเมทาดาตาร์ (Meta-Data) เรี ยกว่าภาษานิยามข้อมูล (DDL :Data
Definition Language) เป็ นคําสั่งที่ใช้สําหรับการสร้าง แก้ไข ลบตารางข้อมูล ซึ่ งมีผลทําให้
โครงสร้ างข้อมูลในตารางเปลี่ ยนแปลงไป การทํางานจะเป็ นการแก้ไขข้อมูลในส่ วนของเมทาดา
ตาร์ นอกจากนั้นรวมถึงคําสั่งที่ใช้ในการสร้าง แก้ไข ลบ ทรรศนะ (View) ดัชนี (Index) คันสเทรน
(Constrain) ทริ กเกอร์ (Trigger) สทอร์ โพรซิ เดอร์ (Store Procedure) และคําสั่งที่ใช้ในการกําหนด
สิ ทธิ์ ให้ผใู ้ ช้งาน คําสั่งในกลุ่มนี้ได้แก่ คําสั่งสร้าง (Create) แก้ไข (Alter) ลบ (Drop) ต่างๆ เช่ น
สร้างตาราง (Create Table) สร้างดัชนี (Create Index) สร้างทริ กเกอร์ (Create Trigger) คําสั่งที่ใช้ใน
การกําหนดสิ ทธิ ได้แก่ กรานท รี โวค (Grant Revoke) คําสั่งที่ใช้ในการเรี ยกใช้เพิ่มข้อมูล แก้ไข
ข้อมูล ลบข้อมูลในตาราง เรี ยกว่า ภาษาจัดการข้อมูล (DML : Data Manipulation Language) เป็ น
คําสั่งที่ใช้ในการจัดการข้อมูลที่อยูใ่ นตารางเพื่อให้ขอ้ มูลในตารางปรับให้เป็ นปั จจุบนั (Updated)
ตรงกับความจริ ง คําสั่งในกลุ่มนี้ได้แก่ เลือก (Select), แทรก (Insert), ปรับให้เป็ นปั จจุบนั (Update)
และลบ (Delete) ตามลําดับ
2.4 กระบวนการจัดซื้อด้ วยระบบอิเล็กทรอนิกส์ (E-Procurement)

ทิพวรรณ (2549) สํานักงานมาตรฐานพัสดุภาครัฐ (2545) กระบวนการจัดซื้ อด้วยระบบ
อิเล็กทรอนิกส์ (2545) หมายถึง การทํางานในแต่ละขั้นตอนของระบบ ข้อมูลจะถูกจัดส่ งและจัดเก็บ
ในรู ปแบบของข้อมูลอิเล็กทรอนิ กส์ ซึ่ งข้อมูลเหล่านี้พร้อมที่จะถูกนําไปวิเคราะห์ต่อไป โดยข้อมูล
ครอบคลุมตั้งแต่การค้นหาและเลือกสิ นค้าจากแคตตาล็อกอิเล็กทรอนิกส์ การออกใบขอสั่งซื้ อ การ
รับและการอนุ มตั ิใบขอสั่งซื้ อ การออกใบสั่งซื้ อ การติดตามการสั่งซื้ อ การตรวจรับสิ นค้าและการ
ชําระเงิน ข้อมูลในแต่ละขั้นตอนจะถูกถ่ายทอดไปอย่างต่อเนื่องจนจบกระบวนการ โดยไม่ตอ้ งใช้
เอกสารเหมือนในอดีต ทําให้มีความรวดเร็ ว ถูกต้องแม่นยํา และเกิดความโปร่ งใส และที่สําคัญ
ข้อมูล จะถู ก ถ่า ยทอดไปยัง ส่ วนต่า งๆที่เกี่ ย วข้อง ส่ งผลให้เกิ ดการประสานงานอย่า งสอดคล้อง
ภายในองค์กรและระหว่างองค์กรกับผูข้ ายอีกด้วย
2.4.1 ขั้นตอนของกระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์
2.4.1.1 ค้นหาสิ นค้า/บริ การที่จะซื้อผ่านแคตตาล็อกระบบอิเล็กทรอนิกส์ (E-Catalog)
13
2.4.1.2 เลือกหมวดสิ นค้าที่ตอ้ งการจะซื้ อผ่านรายการซื้ อขายระบบอิเล็กทรอนิ กส์ (E-

Shopping List)
2.4.1.3 จัดประกาศเชิญชวนผ่านเว็ปไซต์
2.4.1.4 ผูข้ ายเสนอคุณสมบัติของสิ นค้าทางอิ นเทอร์ เน็ ต (Electronic Request for
Proposal : E-RFP)
2.4.1.5 ผูซ้ ้ื อตรวจสอบราคากลาง (Electronic Request for Quotation : E-RFQ) และ
รายการขาย (Track Record) ของผูข้ าย
2.4.1.6 ประมูลด้วยระบบอิเล็กทรอนิกส์ (E-Auction)
2.4.1.7 ประกาศผล ผูช้ นะและส่ งมอบ/ตรวจรับพัสดุ
2.4.1.8 จ่ายเงินตรงด้วยระบบอิเล็กทรอนิกส์ (E-Payment)
2.4.2 องค์ประกอบของกระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์
2.4.2.1 ระบบแคตตาล็อกอิเล็กทรอนิกส์ เป็ นมาตรฐานระบบแคตตาล็อก (Catalog) ที่
รวบรวมรายละเอียดของสิ นค้าและบริ การ ซึ่ งอํานวยความสะดวกให้ผคู้ า้ /ผูร้ ับจ้าง (Suppliers) ที่มี
คุณสมบัติในการทําธุ รกรรมสามารถเข้ามาทําการแจ้งและปรับปรุ งรายการสิ นค้า/บริ การของตนเอง
ได้
2.4.2.2 ระบบเสนอคุ ณสมบัติของสิ นค้าทางอิ นเทอร์ เน็ ตและระบบตรวจสอบราคา
กลาง เป็ นระบบที่อาํ นวยความสะดวกในขั้นตอนการจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ โดยวิธีสอบ
ราคาหรื อวิธีตกลงราคา
2.4.2.3 การประมูลด้วยระบบอิเล็กทรอนิกส์แบ่งได้เป็ น 2 ส่ วน ได้แก่
2.4.2.3.1 Reverse Auction เป็ นระบบที่ อาํ นวยความสะดวกในด้า นการ
ประมูลซื้ อให้ได้ราคาตํ่าสุ ด
2.4.2.3.2 Forward Auction เป็ นระบบที่อาํ นวยความสะดวกในด้านการ
ประมูลขาย ซึ่ งสามารถประยุกต์ใช้กบั การจําหน่ายพัสดุที่หมดความจําเป็ นของหน่วยงานภาครัฐ
โดยวิธีขายทอดตลาด ซึ่ งเป็ นการประมูลขายแบบผูช้ นะ คือ ผูท้ ี่เสนอราคาสู งสุ ด
2.4.3 ข้อดีของผูซ้ ้ื อ
2.4.3.1 กําหนดและสร้างพันธมิตรกับผูผ้ ลิตรายใหม่ได้ทวั่ โลก
2.4.3.2 ความสัมพันธ์กบั พันธมิตรเป็ นไปในทิศทางเดียวกัน ทําให้มีอาํ นาจและต่อรอง
ทางธุ รกิจมากขึ้น
2.4.3.3 ลดการกระจายสารสนเทศ
2.4.3.4 สามารถส่ งรู ปภาพไปให้ผผู ้ ลิตหลายๆ แห่งในเวลาเดียวกัน
14
2.4.3.5 ลดเวลาและค่าใช้จ่ายของกระบวนการ
2.4.3.6 ได้รับการประมูลจากผูผ้ ลิตหลายรายเร็ วขึ้น และทําให้การเจรจาต่อรองได้ผลดี
กว่า
2.4.4 ข้อดีของผูผ้ ลิต
2.4.4.1 เพิ่มปริ มาณการขาย
2.4.4.2 ขยายตลาด และได้รับลูกค้ากลุ่มใหม่
2.4.4.3 ดําเนินการบริ หารการขาย และกิจกรรมทางการตลาดในต้นทุนตํ่า
2.4.4.4 เวลาของกระบวนการสั้นลง
2.4.4.5 พัฒนาให้พนักงานมีประสิ ทธิ ภาพดีข้ ึน
2.4.4.6 กระบวนการประมูลเป็ นไปในทิศทางเดียวกัน
กระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิ กส์ จะช่วยให้องค์กรสามารถลดงานที่ไม่ก่อให้เกิ ด
คุณค่ากับองค์กรลง และทําให้ฝ่ายจัดซื้ อมีเวลาวางแผนในส่ วนของการจัดซื้ อเชิงกลยุทธ์ (Strategic
sourcing) ซึ่ งเป็ นหน้าที่ที่สําคัญมากขึ้น นอกจากนั้นการที่ขอ้ มูลการทําธุ รกรรมต่างๆอยูใ่ นรู ปแบบ
อิเล็กทรอนิกส์ทาํ ให้บริ ษทั สามารถนําข้อมูลไปเชื่อมโยงกับระบบอื่นๆ เพื่อการวางแผนที่ดีข้ ึน เช่น
เมื่อนําข้อมูลจากกระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์ เชื่อมกับระบบคลังสิ นค้า (Inventory)
เมื่อถึ งจุดสั่งซื้ อสามารถกําหนดให้ระบบสร้างใบสั่งซื้ อ (Purchase Order) และส่ งไปยังผูข้ ายโดย
อัตโนมัติได้ หรื อการนําไปเชื่ อมกับระบบชําระเงินด้วยอิเล็กทรอนิ กส์ เมื่อผูข้ อซื้ อได้รับสิ นค้าและ
ทําบันทึกรับในกระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิ กส์ แล้ว สามารถกําหนดให้ระบบจ่ายเงิน
ให้กบั ผูข้ ายโดยอัตโนมัติได้ เป็ นต้น
2.4.5 ประโยชน์จากการพัฒนาระบบจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ มีดงั นี้
2.4.5.1 สามารถเปิ ดเผยข้อมูล (Disclosure) แก่สาธารณะทั้งข้อมูลของโครงการต่างๆ
เอกสารการยื่นประกวดราคา คําชี้ แจงและคําอธิ บาย และข้อมูลการตัดสิ นใจ ผลการประกวดราคา
ของโครงการต่างๆ ที่ผา่ นการคัดเลือกไปแล้วมีความชัดเจนและครบถ้วนสมบูรณ์
2.4.5.2 การกระจายข้อมูลไปยังผูท้ ี่เกี่ยวข้องฝ่ ายต่างๆ โดยเฉพาะผูค้ า้ ที่จาํ หน่ายสิ นค้า
หรื อบริ การดังกล่าว ซึ่ งอาจใช้วิธีการต่างๆ เช่ น การส่ งเอกสารที่เกี่ ยวข้องไปยังผูค้ า้ โดยไปรษณี ย ์
อิเล็กทรอนิกส์ (Electronic Mail) ให้มีความรวดเร็ วทันเหตุการณ์
2.4.5.3 การยื่นประกวดราคาผ่านทางอิเล็กทรอนิ กส์ ซึ่ งต้องการมีการออกแบบตูร้ ับ
เอกสารอิเล็กทรอนิกส์ที่มีความปลอดภัยไม่สามารถเปิ ดได้ก่อนเวลาที่กาํ หนด อันเป็ นกระบวนการ
ที่โปร่ งใสและตรวจสอบได้ทุกขั้นตอน
15
2.4.5.4 การเพิ่มความสามารถของระบบให้สูงขึ้น เพื่อให้เกิ ดบริ การมูลค่าเพิ่มต่างๆ

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

สุ ทธิ ยาภัทร (2545) “การนําระบบการจัดซื้ อจัดจ้างภาครัฐด้วยอิเล็กทรอนิกส์มาใช้ในองค์การ
ภาครัฐ” กล่าวว่า การใช้กระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิ กส์ ในการจัดหาพัสดุพบว่ามีท้ งั
ข้อดี เช่ น เพิ่มความโปร่ งใส ทําให้สามารถตรวจสอบกระบวนการในการจัดหาพัสดุได้ เพิ่มความ
รวดเร็ ว สามารถสรุ ปผลการต่อรองราคาและเห็นราคาแบบทันที (Real Time) เพิ่มโอกาสได้พบผูค้ า้
รายใหม่ ประหยัดค่าใช้จ่าย และพัฒนาองค์ความรู ้ดา้ นเทคโนโลยีสารสนเทศ ข้อจํากัด ระเบียบและ
หลักเกณฑ์ในการจัดหาพัสดุโดยใช้การประมูลด้วยระบบอิเล็กทรอนิ กส์ ไม่ชดั เจนและรัดกุม ทําให้
เกิ ดปั ญหาต่างๆ เช่น การกําหนดระยะเวลาประมูลไม่ได้ การกําหนดคุณสมบัติและเงื่อนไขต่างๆ
ของสิ นค้าต้องรั ดกุมชัดเจน วงเงินการจัดหาควรมีมูลค่าสู งเพื่อให้ผคู้ า้ สนใจเข้าร่ วมประมูล การ
ขัดข้องของระบบคอมพิวเตอร์ ในระหว่างการดําเนินการประมูล อาจทําให้ตอ้ งขยายระยะเวลาการ
ประมูลหรื อยกเลิกการประมูลในครั้งนั้นไป เจ้าหน้าที่พสั ดุส่วนใหญ่มีทศั นคติที่ดีที่จะศึกษาและใช้
กระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์ แม้ยงั ไม่มนั่ ใจในประสิ ทธิ ภาพของระบบคอมพิวเตอร์
และสารสนเทศในการรับการนํากระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์มาใช้
สวลี (2546) “แนวทางการปรับปรุ งการจัดซื้ อจัดจ้างตามแผนปฏิรูปราชการภายใต้กระบวนการ
จัดซื้ อด้วยระบบอิเล็กทรอนิกส์ ศึกษากรณี กองจัดหาการสื่ อสารแห่ งประเทศไทย” กล่าวว่า การนํา
กระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิ กส์ มาใช้ในกองจัดหา พบว่ามีปัญหาและอุปสรรค เช่ น
เรื่ องการปรั บ ปรุ ง โครงสร้ า งขององค์ก ร การที่ ต้องเปลี่ ย นแปลงให้เหมาะสม การปรั บ เปลี่ ย น
เพิ่มเติมหน้าที่เจ้าหน้าที่กองจัดหาที่ตอ้ งเน้นการวางแผนจัดซื้ อจัดจ้าง เรื่ องการนําระบบเทคโนโลยี
สารสนเทศมาใช้โดยคํานึ งถึ งความปลอดภัยของข้อมูลทางราชการ รวมถึงต้องพัฒนาทัศนคติและ
ทักษะของเจ้าหน้าที่ การปรับเปลี่ ยนวิสัยทัศน์ของผูบ้ ริ หาร การจัดเจ้าหน้าที่ทีมีความสามารถทํา
หน้าที่ดา้ นกระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์อย่างเหมาะสม
16
พนิ ดา (2547) “การจัดซื้ อจัดจ้างด้วยระบบอิเล็กทรอนิ กส์ ” กล่าวว่าประโยชน์ที่ได้รับจากการ

ประมูลด้วยระบบอิเล็กทรอนิ กส์ พบว่าช่วยประหยัดงบประมาณและเป็ นเครื่ องมือต่อรองราคาที่มี
ประสิ ทธิ ภาพ รวดเร็ ว แลรู ้ผลได้ในระยะเวลาอันสั้น มีความยืดหยุน่ สามารถจัดการประมูลได้หลาย
รู ปแบบ รู ปแบบการประมูลมีความยุติธรรม เพราะผูค้ า้ จะไม่เห็ นราคาคู่แข่ง การที่มีผใู้ ห้บริ การ
ตลาดกลางอิเล็กทรอนิกส์สามารถทําให้ผซู้ ้ื อ มีผคู้ า้ ที่เข้าร่ วมประมูลงานมากขึ้นกว่าเดิม ปั ญหาและ
อุปสรรคในการนําระบบดังกล่าวมาใช้งานคือ หน่วยงานผูเ้ บิกจะกําหนดรายละเอียดคุ ณลักษณะ
เฉพาะและเงื่อนไขการจัดซื้ อทําให้เกิดการจํากัดรายละเอียดคุณสมบัติเฉพาะ และสร้างการสมยอม
ได้ การคัดเลือกผูค้ า้ ต้องผ่านคุณสมบัติทางเทคนิคก่อน ซึ่ งต้องมีจาํ นวนไม่นอ้ ยกว่า 3 ราย หากน้อย
กว่าจะต้องยกเลิกเรื่ องและดําเนิ นการประมูลใหม่ ทําให้เสี ยเวลาในการดําเนินงาน ผูป้ ระมูลอาจทิ้ง
งานไปเนื่องจากไม่สามารถส่ งมอบสิ่ งของได้ตามข้อตกลง เนื่ องจากได้ประมูลสิ นค้าสิ นค้าในราคา
ที่ต่าํ เพื่อที่ตอ้ งการชนะการประมูล ทําให้ประสบปั ญหากับภาวการณ์ขาดทุนและต้องทิ้งงานไปใน
ที่สุด
นภาพร (2549) “ปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ ” กล่าวว่า
ปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ สอดคล้องกับสมมติฐานเพียง 1
ข้อ และไม่สอดคล้องกับสมมติฐาน 5 ข้อ สมมติฐานที่ 1 เจ้าหน้าที่พสั ดุมีปัจจัยส่ วนบุคคลต่างกัน มี
ปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์แตกต่างกัน เนื่ องมาจากระบบ
จัดซื้ อจัดจ้างทางอิเล็กทรอนิ กส์ เป็ นเรื่ องใหม่ทีเจ้าหน้าที่พสั ดุทุกคนต้องปฏิบตั ิตามและจําเป็ นต้อง
ปรั บ เปลี่ ย นกระบวนทัศ น์ ใ นการทํา งานใหม่ ใ ห้ เ หมาะสม สอดคล้อ ง และทัน กระแสความ
เปลี่ยนแปลงทีเกิดขึ้นดังกล่าว โดยเริ่ มต้นเรี ยนรู้และรับการฝึ กอบรมการปฏิบตั ิงานใหม่ไปพร้อมๆ
กัน โดยไม่จาํ กัด เพศ อายุ ระดับการศึกษา ระดับตําแหน่ ง และประสบการณ์ ในการปฏิ บตั ิงาน
สมมติ ฐ านที่ 2 ความรู ้ เ กี่ ย วกับ ระบบและหลัก เกณฑ์ก ารจัดซื้ อจัด จ้า งทางอิ เล็ ก ทรอนิ ก ส์ ไ ม่ มี
ความสัมพันธ์กบั ปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ สมมติฐานที่ 3
ความพร้ อมของหน่ วยงานไม่มีความสัมพันธ์กบั ปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัดจ้าง
ทางอิเล็กทรอนิ กส์ สมมติฐานที่ 3.1 ความต้องการบุคลากร ไม่มีความสัมพันธ์ปัญหาและอุปสรรค
ในกระบวนการจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ สมมติฐานที่ 3.2 ความพร้อมด้านระบบสารสนเทศ
มีความสัมพันธ์กบั ปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ สมมติฐานที่
3.3 ความพร้อมด้านงบประมาณ ไม่มีความสัมพันธ์กบั ปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัด
จ้างทางอิเล็กทรอนิ กส์ ผลการศึกษาสรุ ปได้ว่า ปั ญหาและอุปสรรคในการะบวนการจัดซื้ อจัดจ้าง
ทางอิเล็กทรอนิ กส์ อยู่ในระดับปานกลาง และผลการสมมติฐาน ไม่พบความแตกต่างในตัวแปร
อิสระทั้งหมด และไม่มีความสัมพันธ์ระหว่างความรู้เกี่ยวกับระบบและหลักเกณฑ์การจัดซื้ อจัดจ้าง
17
ทางอิเล็กทรอนิกส์ และความพร้อมของหน่วยงานกับปั ญหาและอุปสรรคในกระบวนการจัดซื้ อจัด

จ้างทางอิเล็กทรอนิกส์
วัน ทนี ย ์ (2550) “การศึ ก ษาปั ญ หาและอุ ป สรรคในการนํ า นโยบายจัด ซื้ อจัด จ้ า งทาง
อิเล็กทรอนิ กส์ ไปปฏิ บตั ิโดยศึกษาเฉพาะกรณี หน่วยงานของกรุ งเทพมหานคร” กล่าวว่า เจ้าหน้าที่
พัสดุของกรุ งเทพมหานครให้การยอมรับการจัดหาพัสดุดว้ ยวิธีการอิเล็กทรอนิกส์ และทําให้ทราบ
ข้อดีเรื่ องความโปร่ งใสตรวจสอบได้ ลดปั ญหาข้อร้องเรี ยนและช่วยประหยัดงบประมาณ ข้อจัดการ
ที่ พบคือ เจ้า หน้าที่ผูป้ ฏิ บ ตั ิขาดความรู้ ความเข้าใจและไม่ได้รับการอบรมอย่างทัว่ ถึ ง การนําเอา
เทคโนโลยีมาใช้ยงั ไม่ได้ช่วยให้งานเอกสารลดปริ มาณลงแต่อย่างใด ไม่สามารถป้ องกันการฮั้ว
ประมูลได้ร้อยเปอร์ เซ็ นต์ และถึงแม้ผบู้ ริ หารจะให้การสนับสนุ นการนําระบบการจัดหาพัสดุทาง
อิเล็กทรอนิ ก ส์ ม าใช้เป็ นอย่างดี ก็ตาม แต่ย งั คงมี ปัญหาและอุ ปสรรคทางด้านบุค ลากร ด้านการ
จัดการ ด้านงบประมาณ และด้านวัสดุอุปกรณ์ ผูศ้ ึกษาได้มีขอ้ เสนอแนะให้ดาํ เนินการใน 4 ด้าน คือ
ด้า นบุ ค ลากร เห็ น ควรให้ มี ก ารฝึ กอบรวมให้ ค วามรู้ แ ก่ เ จ้า หน้า ที่ ที่ ผู้ป ฏิ บ ัติ อ ย่า งทั่ว ถึ ง ด้า น
งบประมาณเห็นควรให้มีการจัดสรรงบประมาณเรื่ องการจัดการคอมพิวเตอร์ และระบบอุปกรณ์ ที่
ทันสมัยให้ใช้งานได้อย่างทัว่ ถึง ด้านวัสดุอุปกรณ์ ควรจัดให้มีคอมพิวเตอร์ ที่มีประสิ ทธิ ภาพสู งไว้
ใช้งานในหน่ วยงานที่ตอ้ งบริ การประชนชน เช่ น สํานักงานเขตต่างๆ และด้านการบริ หารจัดการ
ควรดําเนินการออกกฎหมาย ระเบียบ หลักเกณฑ์ ให้เอื้อต่อการดําเนินการจัดหาพัสดุดว้ ยวิธีการทาง
อิเล็กทรอนิกส์ โดยลดขั้นตอนเพื่อความรวดเร็ ว
บทที่ 3
ขั้นตอนและการดําเนินงาน
3.1 เครื่องมือทีใ่ ช้ ในการวิจัย

เครื่ องคอมพิวเตอร์ ส่วนบุคคล ความเร็ วในการประมวลผล 5 กิกกะเฮิรตซ์ หน่วยความจํา 4
กิกกะไบต์ ฮาร์ ดดิสก์ 250 กิ กกะไบต์ การ์ ดจอแสดงผลหน่วยความจํา 512 เมกะไบต์ ความเร็ วใน
การโอนถ่ายรับส่ งข้อมูล 1/100 เมาส์ แป้ นพิมพ์ จอภาพ 19 นิ้ว (ความละเอียด 1024 X 768 พิกเซล)
ระบบปฏิบตั ิการวินโดว์เอ็กซ์พี (Window XP) โปรแกรมคอมพิวเตอร์ วิชวล สตูดิโอ 2010 (Visual
Studio 2010) โปรแกรมฐานข้อมูลเอสคิวแอลเซิฟเวอร์ 2008 (SQL Sever 2008)
3.2 ขั้นตอนการศึกษาระบบจัดซื้อเครื่องมือแพทย์
กระบวนการจัดซื้ อของระบบจัดซื้ อเริ่ มต้นขึ้นเมื่อผูต้ อ้ งการจัดซื้ อต้องการซื้ อเครื่ องมือแพทย์
และส่ งคําร้องและข้อมูลไปที่เจ้าหน้าที่จดั ซื้ อ เมื่อเจ้าหน้าที่จดั ซื้ อได้รับคําร้องและข้อมูลแล้วจะทํา
การตรวจสอบความถูกต้องและความเหมาะสมของข้อมูล หลังจากนั้นเจ้าหน้าที่จดั ซื้ อจะทําการส่ ง
คําร้ องขอราคาให้กบั ผูข้ ายรายต่างๆ และรอจนผูข้ ายส่ งราคากลับมาแล้วทําการส่ ง ข้อมูล ให้ผูม้ ี
อํานาจตัดสิ นใจเพื่อให้อนุ มตั ิการสั่งซื้ อและออกใบสั่งซื้ อให้กบั ผูข้ ายรายที่ได้รับพิจารณา ตามภาพ
ที่ 3-1
ภาพที่ 3-1 โครงสร้างและกระแสข้อมูลของระบบจัดซื้ อเครื่ องมือแพทย์

19
3.3 ขั้นตอนการศึกษาปัญหาและความต้ องการจากระบบจัดซื้อเครื่องมือแพทย์

จากการศึกษาระบบงานเดิมทําให้สามารถวิเคราะห์ปัญหาได้ดงั นี้
3.3.1 เกิดปั ญหาความล่าช้าในการจัดซื้ อ ความล่าช้าดังกล่าวอาจเกิดได้จากหลายองค์ประกอบ
ดังนี้
3.3.1.1 ข้อมูลที่ได้จากผูต้ อ้ งการจัดซื้ อเป็ นข้อมูลที่ไม่ตรงตามความต้องการจริ ง หรื อมี
การให้ขอ้ มูลที่มีความซับซ้อนเกินความต้องการ ซึ่ งอาจทําให้เจ้าหน้าที่จดั ซื้ อเกิดความเข้าใจผิดเกิด
ความยุง่ ยาก ทําให้การจัดซื้ อล่าช้า
3.3.1.2 การรับส่ งข้อมูลและเสนอราคาระหว่างผูข้ ายและเจ้าหน้าที่จดั ซื้ อ การรับส่ ง
ข้อมูลนั้นอาจมีความผิดพลาดเนื่องจากมีผขู ้ ายมากกว่าหนึ่ งรายจึงอาจเกิดการผิดพลาด รวมถึงผูข้ าย
บางรายล่าช้าในการเสนอราคาทําให้กระบวนการในการจัดซื้ อใช้เวลาเพิ่มขึ้นด้วย
3.3.1.3 การรออนุ มตั ิสั่งซื้ อ เนื่ องจากผูม้ ีอาํ นาจตัดสิ นใจอาจต้องตรวจดูเอกสารเพื่อ
ตัดสิ นใจ รวมถึงหากไม่สามารถเข้ามาตรวจดูเอกสารเนื่ องจากติดภารกิ จภายนอกจึงทําให้ใช้เวลา
ในการจัดซื้ อมากขึ้น
3.3.2 มีตน้ ทุ นสิ้ นเปลื องเนื่ องจากกระบวนการจัดซื้ อสู ง การจัดซื้ อในปั จจุบนั นั้นยังต้องใช้
เอกสารจํานวนมากจึงจําเป็ นต้องใช้กระดาษ เครื่ องพิมพ์ เครื่ องสําเนาเอกสาร และรวมไปถึงต้องใช้
ทรัพยากรในการจัดเก็บเอกสารอีกด้วย
3.3.3 เอกสารยากต่อการสื บค้นและจัดเก็บ เอกสารจากกระบวนการจัดซื้ อค่อนข้างมีจาํ นวน
มากจึงทําให้เกิดความยุง่ ยากในการจัดเก็บและหากจัดเก็บอกสารไม่เป็ นระเบียบแล้วจะส่ งผลให้เกิด
ความยุง่ ยากในการสื บค้นอีกด้วย
3.4 การวิเคราะห์ และออกแบบโปรแกรมจัดซื้อเครื่องมือแพทย์

หลังจากที่ได้ศึกษาระบบการจัดซื้ อเครื่ องมื อแพทย์ พร้ อมทั้งวิเคราะห์กระบวนการต่างๆ
ตลอดจนศึกษาสภาพปั ญหาและอุปสรรคภายใต้สิ่งแวดล้อมของระบบจัดซื้ อเครื่ องมือแพทย์แล้ว
นั้น ได้ทาํ การออกแบบและพัฒนาโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์ ข้ ึนมา
เพื่อพัฒนาและเพิ่มศักยภาพของแผนกจัดซื้ อที่มีอยู่ให้มากขึ้น การออกแบบการพัฒนาโปรแกรม
จัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์มีข้นั ตอนในการออกแบบดังต่อไปนี้
3.4.1 แผนภาพกระแสข้อมูล (Data Flow Diagram : DFD)
แผนภาพกระแสข้อมู ล เป็ นเครื่ องมื อในการเขี ย นภาพที่ แสดงการเคลื่ อนไหวของข้อมู ล
ภายในโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิ กส์ ซึ่ งจากแผนภาพกระแสข้อมูลที่
ออกแบบ ได้นาํ ความต้องการและวิถีทางความเป็ นไปได้มาสู่ แนวทางการปฏิบตั ิ โดยอาศัยแผนภาพ
20
ดังกล่ าวเป็ นกลไกสําคัญในการจัดการสําหรั บสร้ า งข้อมูลที่ จาํ เป็ นต้องใช้ภายในระบบเพื่อการ

ประมวลผลโดยมีระดับของข้อมูลตามภาพที่ 3-2 และสามารถแบ่งออกเป็ นขั้นตอนด้านล่าง
0 Level 0
1.0 2.0 Level 1
1.1 1.2 Level 2
1.1.1 1.1.2 Level 3
ภาพที่ 3-2 ตัวอย่างแผนภาพแสดงกระแสข้อมูลโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบ

อิเล็กทรอนิกส์โดยแบ่งเป็ นระดับ
3.4.1.1 ขั้นตอนที่ 1 แผนภาพกระแสข้อมูลระดับสู งสุ ด (Context Diagram) Level - 0

จะแสดงขอบเขตของโปรแกรมจัดซื้ อเครื่ องมือแพทย์ด้วยระบบอิเล็กทรอนิ กส์ ซ่ ึ งได้จาก
การศึกษาและวิเคราะห์ระบบดังภาพที่ 3-3 ซึ่ งประกอบด้วยผูใ้ ช้งานและผูเ้ กี่ยวข้องของระบบทั้ง 5
ส่ วน คือ ผูข้ อซื้ อหรื อผูใ้ ช้ เจ้าหน้าที่จดั ซื้ อ ผูม้ ีอาํ นาจอนุมตั ิ ผูข้ าย และผูด้ ูแลระบบ โดยมีระบบทํา
หน้าที่เป็ นตัวกลางหรื อเครื่ องมือเพื่อใช้ในการรับส่ ง เปรี ยบเทียบ และจัดเก็บข้อมูลที่ใช้ในการ
จัดซื้ อเครื่ องมือแพทย์
Procurement
E-medequip Procurement
ภาพที่ 3-3 แผนภาพกระแสข้อมูลระดับสู งสุ ดโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบ

อิเล็กทรอนิกส์
21
3.4.1.2 ขั้นตอนที่ 2 แผนภาพกระแสข้อมูลระดับที่ 1 (Data Flow Diagram Level - 1)

แสดงถึงรายละเอียดของความสัมพันธ์ระหว่างการทํางานหลักทั้งหมดของระบบ เขียนเป็ น
แผนภาพกระแสข้อมูลระดับที่ 1 ได้ดงั ภาพที่ 3-4 แผนภาพกระแสข้อมูลระดับที่ 1
Verify PR
(Verified)
PR (Verified)
Procurement
ภาพที่ 3-4 แผนภาพกระแสข้อมูลระดับที่ 1 (Data Flow Diagram Level - 1)
คําอธิ บายการประมวลผลของแผนภาพกระแสข้อมูลระดับที่ 1 สามารถทําได้ดงั ต่อไปนี้

0
3.4.1.2.1 ผูใ้ ช้งาน (User)

ก) สามารถสร้างคําร้องขอซื้อ (Purchase Requisition : PR) ได้
3.4.1.2.2 ผูอ้ นุมตั ิ (Authorized Person)
ก) ตรวจสอบรายละเอียดต่างๆ ของคําร้องขอซื้ อได้
ข) สามารถส่ ง คํา ร้ อ งขอซื้ อกลั บ ไปยัง ผู้ใ ช้ ง านได้ ในกรณี ที่
รายละเอียดในคําร้องขอซื้ อไม่เหมาะสม
ค) สามารถส่ ง คํา ร้ อ งขอซื้ อต่ อ ไปยัง ฝ่ ายจั ด ซื้ อได้ ในกรณี ที่
รายละเอียดในคําร้องขอซื้ อครบถ้วนสมบูรณ์แล้ว
ง) ส่ งคําร้องขอซื้ อไปยังผูข้ าย (Vendor) ได้
22
จ) ส่ งใบสั่งซื้อไปยังผูข้ ายได้
3.4.1.2.3 เจ้าหน้าที่จดั ซื้อ (Procurement)
ข) สามารถส่ ง คํา ร้ อ งขอซื้ อกลั บ ไปยัง ผู้ใ ช้ ง านได้ ในกรณี ที่
รายละเอียดในคําร้องขอซื้อไม่เหมาะสม
ค) เลือกผูข้ ายที่เหมาะสมสําหรับคําร้องขอซื้ อนั้นๆ แล้วส่ งกลับไป
ให้ผอู ้ นุมตั ิพิจารณา
ง) ดูรายการใบเสนอราคา (Quotation) จากผูข้ ายได้
3.4.1.2.4 ผูข้ าย (Vendor)
ข) กรอกรายละเอียดใบเสนอราคา
3.4.1.2.5 ผูด้ ูแลระบบ (Administrator)
ก) จัดการข้อมูลผูใ้ ช้งาน
ข) จัดการข้อมูลผูอ้ นุมตั ิ
ค) จัดการข้อมูลเจ้าหน้าที่จดั ซื้อ
ง) จัดการข้อมูลผูข้ าย
จ) จัดการข้อมูลยีห่ อ้ แนะนํา (Brand Prefer)
3.4.1.3 ขั้นตอนที่ 3 แผนภาพกระแสข้อมูลระดับที่ 2 (Data Flow Diagram Level – 2)
แสดงถึ ง รายละเอี ย ดของความสัม พันธ์ ก ารทํา งานส่ วนของระบบการสร้ า งคํา ร้ องขอซื้ อ
(Purchase Requisition) เขียนเป็ นแผนภาพกระแสข้อมูลระดับที่ 2 กระบวนการทํางานที่ 1 (Data
Flow Diagram Level – 2 Process 1) ได้ดงั ภาพที่ 3-5 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของ
กระบวนการที่ 1
23
Procurement
ภาพที่ 3-5 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 1 การสร้างคําร้องขอซื้อ
จากภาพที่ 3-5 เป็ นกระบวนการที่เกี่ ย วกับ การสร้างใบคําร้องขอซื้ อ โดยจะนํารายละเอียด

คํา ร้ อ งขอซื้ อ ที่ ผู้ใ ช้ ง านระบบกรอกบัน ทึ ก ลงสู่ ฐ านข้อ มู ล ไม่ ว่ า จะเป็ นการเพิ่ ม และแก้ ไ ข
รายละเอียดของคําร้องขอซื้ อ โดยแสดงรายละเอียดตามตารางที่ 3-1
ตารางที่ 3-1 ตารางรายละเอียดกระบวนการของการสร้างคําร้องขอซื้ อ
System : โปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์ (Emedequip)
DFD Number : 1
Process Name : สร้างใบคําร้องขอซื้ อ
Input data flows รายละเอียดคําร้องขอซื้อ
Output data flows -
Data stored used ข้อมูลคําร้องขอซื้ อ
Description เป็ นกระบวนการที ่ เ กี ่ ย วกับ การสร้ า งใบคํา ร้ อ งขอซื้ อ โดยจะนํา
รายละเอียดคําร้ องขอซื้ อ ที่ผใู้ ช้งานระบบกรอกบันทึกลงสู่ ฐานข้อมูล
ไม่วา่ จะเป็ นการเพิ่ม และ แก้ไขรายละเอียดของคําร้องขอซื้ อ
24
จากการออกแบบแผนภาพกระแสข้อมูลระดับที่ 2 กระบวนการที่ 1 จะเห็นได้วา่ ประกอบไป

ด้ว ยส่ ว นของการเก็ บ ข้อ มู ล ในใบร้ องขอซื้ อ (1.1) และการอ่ า นข้อมู ล คํา ร้ อ งขอซื้ อ (1.2) โดย
รายละเอียดของความสัมพันธ์การทํางานส่ วนของขั้นตอนการสร้างคําร้องขอซื้ อ เขียนเป็ นแผนภาพ
กระแสข้อมูลระดับที่ 3 กระบวนการทํางานที่ 1.1 (Data Flow Diagram Level – 3 Process 1.1) ได้
ดังภาพที่ 3-6 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของกระบวนการที่ 1.1 ขั้นตอนการสร้างคํา
ร้องขอซื้ อ
Procurement
ภาพที่ 3-6 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของกระบวนการที่ 1.1 ขั้นตอนการสร้างคําร้อง

ขอซื้อ
จากภาพที่ 3-6 เป็ นการแสดงการสร้างคําร้องขอซื้ อเพื่อจัดเก็บข้อมูลใบคําร้องขอซื้ อ โดย

รายละเอี ย ดต่ า งๆ ที่ ใ ช้ใ นการกรอกข้อ มู ล ประกอบด้ว ย การสร้ า ง/แก้ไ ขคํา ร้ อ งขอ (Request)
สามารถสร้าง/แก้ไขชื่ อคําร้องขอซื้ อ, ผูข้ าย, คุณสมบัติหลัก, ยี่ห้อแนะนํา, รายละเอียดคําร้องขอซื้ อ
(Purchase Requisition Detail) และทําการเก็บ/ปรับปรุ ง ข้อมูลใน ฐานข้อมูล โดยแสดงตามตารางที่
3-2
25
ตารางที่ 3-2 ตารางรายละเอียดกระบวนการของขั้นตอนการสร้างคําร้องขอซื้ อ

System : โปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์
DFD Number : 1.1
Process Name : ขั้นตอนการสร้างคําร้องขอซื้ อ
Input data flows ข้อมูลรายละเอียดคําร้องขอซื้ อ, ยี่ห้อแนะนํา, ผูข้ าย, ชื่ อคําร้ องขอซื้ อ
(Purchase Requisition Title), คุณสมบัติหลัก (Main specification)
Output data flows -
Data stored used ชื่อคําร้องขอซื้ อ, ผูข้ าย, คุณสมบัติหลัก, ยีห่ อ้ แนะนํา
Description - การสร้าง/แก้ไขคําร้องขอ (Request) สามารถสร้าง/แก้ไขชื่อคําร้องขอ
ซื้ อ, ผูข้ าย, คุ ณสมบัติหลัก, ยี่ห้อแนะนํา, รายละเอียดคําร้องขอซื้ อ
(Purchase Requisition Detail) และทําการเก็บ/ปรับปรุ ง ข้อมูลใน
ฐานข้อมูล
จากความสั ม พัน ธ์ ก ารทํา งานส่ ว นของโปรแกรมจัด ซื้ อเครื่ องมื อ แพทย์ ด้ ว ยระบบ
อิเล็กทรอนิ กส์ เขียนเป็ นแผนภาพกระแสข้อมูลระดับที่ 3 กระบวนการทํางานที่ 1.2 (Data Flow
Diagram Level – 3 Process 1.2) ได้ดงั ภาพที่ 3-7 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของ
กระบวนการที่ 1.2 การอ่านข้อมูลคําร้องขอซื้อ
26
Procurement
ภาพที่ 3-7 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของกระบวนการที่ 1.2 การอ่านข้อมูลคําร้องขอ

ซื้ อ
จากภาพที่ 3-7 เป็ นการแสดงการอ่านคําร้องขอซื้ อเพื่อจัดเก็บข้อมูลใบคําร้องขอซื้ อ โดยการ

นําข้อมูลคํา ร้ องขอซื้ อทั้งหมดมาแสดงเพื่อการดู รายละเอี ยด และตัดสิ นใจว่าคําร้ องขอซื้ อนั้นๆ มี
องค์ประกอบถูกต้องครบถ้วนสมบูรณ์หรื อไม่ โดยรายละเอียดตามตาราง 3-3
ตารางที่ 3-3 ตารางรายละเอียดกระบวนการของการยืนยันการอ่านข้อมูลคําร้องขอซื้ อ
DFD Number : 1.2
Process Name : การอ่านข้อมูลคําร้องขอซื้ อ
Input data flows -
Output data flows ข้อมูลคําร้องขอซื้ อ (Purchase Requisition Data)
Data stored used คําร้องขอซื้ อ, ชื่อคําร้องขอซื้ อ, ผูข้ าย, ยีห่ อ้ แนะนํา
Description นําข้อมูลคําร้องขอซื้ อทั้งหมดมาแสดงเพื่อการดูรายละเอียด และตัดสิ นใจ
ว่าคําร้องขอซื้ อนั้นๆ มีองค์ประกอบถูกต้อง ครบถ้วนสมบูรณ์หรื อไม่
27
จากรายละเอียดของแผนภาพกระแสข้อมูลกระบวนการทํางานที่ 1 สามารถเขียนรายละเอียด
ความสั ม พันธ์ ก ารทํา งานส่ วนของการแก้ไขคํา ร้ องขอซื้ อเป็ นแผนภาพกระแสข้อมู ลระดับ ที่ 2
กระบวนการทํางานที่ 2 (Data Flow Diagram Level – 2 Process 2) ได้ดงั ภาพที่ 3-8 ซึ่ งแสดง
แผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 2 การแก้ไขคําร้องขอซื้ อ
(Verified)
ภาพที่ 3-8 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 2 แก้ไขคําร้องขอซื้ อ
จากภาพที่ 3-8 เป็ นการออกแบบการส่ วนของการแก้ไขคําร้องขอซื้ อโดยออกแบบให้มีหน้าที่

ตรวจสอบองค์ประกอบ ของคําร้องขอซื้ อนั้นๆ เพื่อทําการแก้ไข ตามรายละเอียดตาราง 3-4
ตารางที่ 3-4 ตารางรายละเอียดกระบวนการของการตรวจสอบและแก้ไขคําร้องขอซื้ อ
DFD Number : 2
Process Name : ตรวจสอบและแก้ไขคําร้องขอซื้ อ (Verify Purchase Requisition)
Input data flows ข้อมูลคําร้องขอซื้ อ
Output data flows ข้อมูลคําร้องขอซื้ อ
Data stored used ข้อมูลคําร้องขอซื้ อ, คุณสมบัติหลัก, ยีห่ อ้ แนะนํา
Description ตรวจสอบองค์ประกอบ ของคําร้องขอซื้ อนั้นๆ เพื่อทําการแก้ไข
ลําดับต่อมาเป็ นการออกแบการแสดงถึงรายละเอียดของความสัมพันธ์การทํางานส่ วนของ

การแสดงใบเสนอราคาเป็ นแผนภาพกระแสข้อมูลระดับที่ 2 กระบวนการทํางานที่ 3 (Data Flow
Diagram Level – 2 Process 3) ได้ดงั ภาพที่ 3-9 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของ
กระบวนการที่ 3 การแสดงใบเสนอราคา
28
Procurement
ภาพที่ 3-9 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 3 การแสดงใบเสนอราคา
จากภาพที่ 3-9 เป็ นส่ ว นที่ อ อกแบบการแสดงรายการใบเสนอราคาตามคํา ร้ อ งขอซื้ อ

(Purchase Requisition Offer) จากผูข้ ายต่างๆ รวมถึงสร้างรู ปแบบการเปรี ยบเทียบรวมไปถึงการ
เลือกผูข้ ายและออกใบสั่งซื้อให้กบั ผูข้ ายรายที่ได้รับเลือก ตามรายละเอียดตารางที่ 3-5
ตารางที่ 3-5 ตารางรายละเอียดกระบวนการของการแสดงใบเสนอราคา
DFD Number : 3
Process Name : การแสดงใบเสนอราคา
Input data flows เลขที่คาํ ร้องขอซื้อ (Purchase Requisition Identity)
Output data flows ใบเสนอราคา
Data stored used คําร้องขอซื้ อ, ใบเสนอราคาตามคําร้องขอซื้ อ
Description แสดงรายการใบเสนอราคาตามคํา ร้ องขอซื้ อ (Purchase Requisition
Offer) จากผูข้ ายต่างๆ
จากการออกแบบแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 3 ทําระบบต้องทําการ

ส่ งข้อมูลให้กบั ผูข้ ายจึงออกแบบส่ วนถัดมาซึ่ งจากภาพแสดงถึงรายละเอียดของความสัมพันธ์การ
ทํา งานส่ ว นของการส่ ง ใบคํา ร้ อ งขอซื้ อไปยัง ผู้ข าย เป็ นแผนภาพกระแสข้อ มู ล ระดับ ที่ 2
29
กระบวนการทํางานที่ 4 (Data Flow Diagram Level – 2 Process 4) ได้ดงั ภาพที่ 3-10 แสดง
แผนภาพกระแสข้อ มู ล ระดับ ที่ 2 ของกระบวนการที่ 4 การส่ ง ใบคํา ร้ อ งขอซื้ อ ไปยัง ผูข้ าย
รายละเอียดแสดงดังตาราง 3-6
Procurement
ภาพที่ 3-10 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 4 การส่ งใบคําร้องขอซื้ อ

ไปยังผูข้ าย
ตารางที่ 3-6 ตารางรายละเอียดกระบวนการการส่ งใบคําร้องขอซื้ อไปยังผูข้ าย

DFD Number : 4
Process Name : ส่ งใบคําร้องขอซื้อไปยังผูข้ าย
Input data flows เลขที่คาํ ร้องขอซื้อ
Output data flows -
Data stored used ข้อมูลคําร้องขอซื้ อ, ผูข้ าย
Description อ่านข้อมูลคําร้องขอซื้ อและส่ งไปหาผูข้ าย
เมื่อระบบทําการส่ งข้อมูลให้กบั ผูข้ ายแล้ว ผูข้ ายจําเป็ นต้องกรอกข้อมูลส่ งกลับเข้าสู่ ระบบ จึง
ได้ออกแบบส่ วนของการรับข้อมูลจากผูข้ าย โดยรายละเอียดของความสัมพันธ์การทํางานส่ วนของ
การส่ งใบเสนอราคาของผูข้ าย เป็ นแผนภาพกระแสข้อมูลระดับที่ 2 กระบวนการทํางานที่ 5 (Data
Flow Diagram Level – 2 Process 5) ได้ดงั ภาพที่ 3-11 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของ
กระบวนการที่ 5 การส่ งใบเสนอราคาของผูข้ าย
30
ภาพที่ 3-11 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 5 การส่ งใบเสนอราคา

ของผูข้ าย
จากภาพที่ 3-11 สามารถแสดงรายละเอียดกระบวนการเก็บข้อมูลเพื่อส่ งใบเสนอราคาได้ตาม

ตารางที่ 3-7
ตารางที่ 3-7 ตารางรายละเอียดกระบวนการการส่ งใบเสนอราคาของผูข้ าย
DFD Number : 5
Process Name : ส่ งใบเสนอราคาของผูข้ าย
Input data flows เลขที่คาํ ร้องขอซื้อ, เลขที่ผขู ้ าย (Vendor Identity)
Output data flows -
Data stored used (Offer)
Description ส่ งใบเสนอราคา
จากการออกแบบสามารถแสดงขั้นตอนการทํางานของโปรแกรมจัดซื้ อเครื่ องมือแพทย์ได้

ตามภาพที่ 3-12
31
1
1 1
1
1
ภาพที่ 3-12 โครงสร้างการทํางานของโปรแกรมจัดซื้ อเครื่ องมือแพทย์
จากภาพที่ 3-12 การออกแบบส่ วนต่างๆ ของโปรแกรมสามารถนํามารวมเป็ นโปรแกรม

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

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

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

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

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

จัดซื้ อ โดยประกอบไปด้วย
4.1.1 ชื่ อรายการคําขอซื้ อ (Title) เป็ นชื่ อประเภทของกลุ่มอุปกรณ์ที่เราต้องการจัดซื้ อทําให้
เกิดความสะดวกหากต้องการสื บค้นข้อมูลภายหลัง
4.1.2 ชื่ อ รายการอุ ป กรณ์ ที่ ข อซื้ อ แบบเฉพาะเจาะจง (Subtitle) เป็ นชื่ อของเครื่ อ งมื อหรื อ
อุปกรณ์ที่ผขู ้ อซื้ อต้องการซื้อโดยอาจเป็ นชื่อที่มีความจําเพาะเจาะจงหรื อเป็ นชื่อสากลก็ได้
4.1.3 รายละเอียดเพิ่มเติม (Description) เป็ นส่ วนของการใส่ รายละเอียดเพิ่มเติมเพื่ออธิ บาย
เครื่ องมือที่ตอ้ งการจัดซื้ อ
35
4.1.4 วันหมดอายุใบคําร้องขอซื้ อ (Expire Date) เป็ นส่ วนของการกําหนดวันหมดอายุของใบ

คําร้องขอซื้ อนั้นๆ
4.1.5 รายละเอี ยดอุ ปกรณ์ เพิ่มเติมสําหรับการซื้ อ (Optional Specification) เป็ นรายละเอียด
อุปกรณ์ประกอบการใช้งานหรื ออุปกรณ์เพิม่ เติมสําหรับเครื่ องมือที่ตอ้ งการซื้อ
4.1.6 คุ ณ สมบัติ แ ละรายละเอี ย ดหลัก (Main Specification) เป็ นส่ ว นของการกํา หนด
คุณสมบัติและรายละเอียดคุณสมบัติของเครื่ องมือที่ตอ้ งการจัดซื้ อ
4.1.7 ยีห่ ้อแนะนํา (Brand Prefer) เป็ นส่ วนของการแนะนํายี่ห้อที่น่าสนใจหรื อที่ผตู้ อ้ งการขอ
ซื้ อสนใจอยู่
4.2 ส่ วนการแจ้ งรายละเอียดและขอเสนอราคาสั่ งซื้อ

ในส่ วนนี้ เจ้าหน้าที่จดั ซื้ อจะเข้ามาตรวจสอบรายละเอียดและแก้ไขรายละเอียดจากคําขอซื้ อ
ให้ถูกต้องเหมาะสมตามระเบียบของโรงพยาบาล ลักษณะภายในจะคล้ายกับหน้าจอส่ วนการขอซื้ อ
แต่จะพิมพ์ขอ้ มูลมาแล้วและเพิ่มในส่ วนของการเลื อกผูข้ ายขึ้นมา ดังภาพที่ 4-3 ในส่ วนนี้ จะมี
ลักษณะเหมือนกับส่ วนของการขอซื้ อแต่จะแตกต่างกันตรงที่จะมีส่วนเพิ่มมาเป็ นส่ วนของการเลือก
ผูข้ าย (Select Vendors) เพิ่มขึ้นมา เมื่อเลือกผูข้ ายแล้วระบบจะทําการส่ งจดหมายอิเล็กทรอนิกส์ (E-
Mail) ให้กบั ผูข้ าย
36
ภาพที่ 4-3 ตัวอย่างหน้าจอสําหรับตรวจสอบรายละเอียด คัดเลือกผูข้ ายและแจ้งเสนอราคาให้กบั

ผูข้ าย
4.3 ส่ วนของการเสนอราคาโดยผู้ขาย
เมื่อโปรแกรมทําการส่ งการขอเสนอราคามายังผูข้ าย ผูข้ ายจะได้รับจดหมายอิเล็กทรอนิ กส์
แจ้งและจะมีลิงค์ (Link) ให้กรอกข้อมูลรายละเอียดและเสนอราคาตามภาพที่ 4-4 และภาพที่ 4-5
37
ภาพที่ 4-4 ตัวอย่างจดหมายอิเล็กทรอนิกส์ที่ผขู ้ ายจะได้รับจากระบบ
ภาพที่ 4-5 ตัวอย่างหน้าจอสําหรับให้ผขู ้ ายกรอกข้อมูลและเสนอราคา

38
เมื่อระบบทําการส่ งจดหมายอิเล็กทรอนิกส์ให้กบั ผูข้ ายแล้วหากผูข้ ายต้องการเสนอราคาโดย

การเลือกที่ “Enter Your Quotation” ตามภาพที่ 4-4 ระบบจะให้ผขู ้ ายกรอกข้อมูลโดยจะมีขอ้ มูลที่
เป็ นรายละเอี ยดจากผูข้ อซื้ อต้องการ และจะมีช่องสํา หรับกรอกข้อมูลสําหรับผูข้ ายโดยข้อมูล ที่
ต้องการนั้นเป็ นข้อมูลเหมือนกับใบขอซื้อ แต่จะมีรายละเอียดเพิม่ เติมดังนี้
4.3.1 ภาพของเครื่ องมือที่เสนอ (Product Image) เป็ นส่ วนสําหรับแนบภาพประกอบ
4.3.2 ราคา (Price) เป็ นส่ วนสําหรับการใส่ ราคาที่ตอ้ งการเสนอสามารถใส่ ได้ 3 ราคา ขึ้นอยู่
กับข้อเสนอของผูข้ าย
4.3.3 ระยะรับประกัน (Warranty) เป็ นส่ วนของการรับประกันสิ นค้าที่ผขู ้ ายรับประกัน
4.3.4 เอกสารแนบประกอบการเสนอราคา (File Attachment) เป็ นส่ วนของการแนบเอกสาร
เสนอราคาจากทางผูข้ ายเพื่อยืนยัน
4.3.5 เพิ่มเติม (Note) เป็ นส่ วนเพิ่มเติมของผูข้ ายเช่น การลดราคาพิเศษ เป็ นต้น
4.4 ส่ วนแสดงตารางเปรียบรายละเอียดและราคาจากผู้ขาย
เมื่อผูข้ ายทําการเสนอรายละเอียดและราคาเครื่ องมือมาแล้วระบบจะทําการนําข้อมูลที่ได้มา
เปรี ยบเทียบเพื่อให้ผมู ้ ีอาํ นาจตัดสิ นใจดูขอ้ มูลรายละเอียดและราคาที่ผขู้ ายทั้งหมดเสนอมาและทํา
การเลือกผูข้ าย ระบบจะทําการส่ งใบสัง่ ซื้อให้ผขู ้ ายอัตโนมัติ ดังภาพที่ 4-6 และ ภาพที่ 4-7
39
ภาพที่ 4-6 หน้าจอแสดงการเปรี ยบเทียบข้อมูลต่างๆ เพื่อเลือกซื้ อเครื่ องมือ
จากภาพที่ 4-6 เป็ นการเปรี ย บเที ยบข้อมูลผูข้ ายทุ กรายที่ เสนอราคาเครื่ องมือกลับ มาโดย
โปรแกรมจะทําหน้าที่เปรี ยบเทียบให้แบบอัตโนมัติ ในส่ วนนี้ สามารถผูข้ ายที่ตอ้ งการซื้ อได้ เมื่อได้
ทําการเลือกผูข้ ายแล้วระบบจะทําการออกใบสัง่ ซื้ อให้กบั ผูข้ ายรายนั้นแบบอัตโนมัติ (ภาพที่ 4-7)
40
ภาพที่ 4-7 ตัวอย่างใบสั่งซื้ อที่ระบบทําการส่ งให้กบั ผูข้ าย
4.5 ส่ วนของการบันทึกข้ อมูลเข้ าสู่ ระบบ

ในส่ วนนี้เป็ นส่ วนของการบันทึกข้อมูลเข้าสู่ ระบบและจะเก็บข้อมูลไว้ตามภาพที่ 4-8 โดย
การเก็บข้อมูลของระบบนั้น ระบบจะทําการจัดเก็บข้อมูลต่างๆ ดังต่อไปนี้
41
ภาพที่ 4-8 ตัวอย่างส่ วนของการบันทึกข้อมูลเข้าสู่ ระบบ
4.5.1 การบันทึกค่าประเภทผูใ้ ช้งาน (Username/Password) เป็ นการตั้งค่าผูใ้ ช้งานตั้งแต่สร้าง

กําหนดประเภทของผูใ้ ช้ แก้ไขข้อมูล และลบข้อมูลผูใ้ ช้ออกจากระบบตามภาพที่ 4-9 โดยจากภาพ
ข้อมูลที่ใช้ในการเก็บเข้าสู่ ระบบ
42
ภาพที่ 4-9 ตัวอย่างการบันทึกค่าประเภทผูใ้ ช้งาน
4.5.2 การบันทึกข้อมูลชื่ อรายการคําขอซื้ อ (Title) เป็ นการตั้งค่าการสร้างกลุ่มของประเภท

เครื่ องมื อที่ตอ้ งการจัดซื้ อ เพื่อสะดวกต่อการเรี ยกดูขอ้ มูลการจัดซื้ อในอนาคต โดยสามารถสร้าง
แก้ไข และลบข้อมูลต่างๆ ที่อยูใ่ นระบบได้ตามภาพที่ 4-10
43
ภาพที่ 4-10 ตัวอย่างการบันทึกข้อมูลชื่อรายการคําขอซื้ อ
4.5.3 การบันทึกข้อมูลยี่ห้อแนะนํา (Brand Prefer) เป็ นการตั้งค่ายี่ห้อของเครื่ องมือที่แนะนํา

การตั้งค่านั้นสามารถสร้าง แก้ไข และลบข้อมูลของยีห่ อ้ แนะนํา โดยข้อมูลที่ใช้ในการเก็บข้อมูลคือ
ชื่อยีห่ อ้ แนะนํา ตามภาพที่ 4-11
44
ภาพที่ 4-11 ตัวอย่างการบันทึกข้อมูลยีห่ อ้ แนะนํา
4.5.4 การบันทึกข้อมูลผูข้ าย (Vendor) เป็ นการตั้งค่าผูซ้ ้ือคล้ายกับการตั้งค่าส่ วนอื่นๆ คือสร้าง

แก้ไข และลบข้อมูลของผูข้ าย โดยข้อมูลที่สําคัญคือข้อมูลจดหมายทางอิเล็กทรอนิ กส์ โดยส่ วนที่
ระบบต้องการข้อมูลคือ ชื่อผูข้ าย ข้อมูลจดหมายทางอิเล็กทรอนิกส์ ตามภาพที่ 4-12
45
ภาพที่ 4-12 ตัวอย่างการบันทึกข้อมูลผูข้ าย
4.6 การทดสอบระบบการทํางานของโปรแกรมจัดซื้อเครื่องมือแพทย์
การทดสอบระบบการทํางานของโปรแกรมจัดซื้ อเครื่ องมือแพทย์ จากผลการประเมินจาก
ผูท้ ดลองใช้งานได้แก่ แผนกกายภาพบําบัด แผนกจัดซื้ อ แผนกเทคโนโลยีสารสนเทศ จากเครื อ
โรงพยาบาลกรุ งเทพ โรงพยาบาลบีแคร์ โรงพยาบาลหัวเฉี ย ว บริ ษทั เอส ซี จี จํากัด และผูข้ าย
จํานวนรวม 14 ตัวอย่าง โดยมีค่าระดับความพึงพอใจเฉลี่ย 4.52 จากคะแนนเต็ม 5 (แสดงแบบ
สํารวจดังภาพที่ 4-13) รายละเอียดจากแบบสํารวจแบ่งเป็ นดังนี้
4.6.1 ความถูกต้องของโปรแกรมเปรี ยบเทียบกับงานจัดซื้ อ
4.6.2 ความครบถ้วนของโปรแกรมในงานจัดซื้ อ
4.6.3 ความถูกต้องในส่ วนของการรับส่ งข้อมูลของโปรแกรม
4.6.4 ความถูกต้องส่ วนบันทึกข้อมูล
4.6.5 ความถูกต้องของส่ วนรายงานผล
4.6.6 ความสะดวกและง่ายต่อการใช้งาน
4.6.7 ความเสถียรของโปรแกรม
4.6.8 ความสวยงามของโปรแกรม
46
4.6.9 ลักษณะของฐานข้อมูลและโปรแกรมง่ายต่อการพัฒนาเพิ่มเติมในอนาคต
โดยหลักเกณฑ์การพิจารณาคิดคะแนนมาจาก
ดีมาก คิดเป็ น 5 คะแนน
ดี คิดเป็ น 4 คะแนน
ปานกลาง คิดเป็ น 3 คะแนน
น้อย คิดเป็ น 2 คะแนน
ต้องปรับปรุ ง คิดเป็ น 1 คะแนน
ดีมาก ดี ปานกลาง น้อย ต้อง

ปรับปรุ ง
ภาพที่ 4-13 แบบสํารวจความพึงพอใจในการใช้โปรแกรมจัดซื้ อเครื่ องมือแพทย์

47
จากตัวอย่า งจํา นวน 14 ตัวอย่าง สามารถประเมินความพึงพอใจแบบบุค คลได้ตามข้อมู ล

ด้านล่าง (ตัวเลขแสดงจํานวนคน)
หัวข้ อการประเมิน ดี ดี ปาน น้ อย ต้ อง ค่ า SD

มาก กลาง ปรับปรุ ง
1. ความถูกต้องของโปรแกรมเปรี ยบเทียบกับ 8 6 0.507895
งานจัดซื้ อ
2. ความครบถ้วนของโปรแกรมในงานจัดซื้ อ 8 6 0.507895
3. ความถูกต้องในส่ วนของการรับส่ งข้อมูลของ 7 6 1 0.680882
โปรแกรม
4. ความถูกต้องส่ วนบันทึกข้อมูล 7 7 0.500000
5. ความถูกต้องของส่ วนรายงานผล 7 7 0.500000
6. ความสะดวกและง่ายต่อการใช้งาน 7 7 0.500000
7. ความเสถียรของโปรแกรม 4 8 2 0.657137
8. ความสวยงามของโปรแกรม 9 5 0.506077
9. ลักษณะของฐานข้อมูลและโปรแกรมง่ายต่อ 11 3 0.356831
การพัฒนาเพิ่มเติมในอนาคต
ความคิดเห็นเพิ่มเติมที่ 1 เหมาะสําหรับการใช้ในองค์กรขนาดเล็ก เนื่องจากมีความสะดวกใน

การจัดซื้ อและง่ายต่อการใช้งานในองค์กรที่ยงั ไม่ยอมพัฒนาระบบให้มีการสอดคล้องในการทํางาน
ของโปรแกรม
ความคิดเห็นเพิม่ เติมที่ 2 ควรมีคู่มือการใช้งานเป็ นภาษาไทย
ความคิดเห็นเพิ่มเติมที่ 3 ควรเพิ่ม Security ระหว่างทํารายการ
ความคิดเห็นเพิ่มเติมที่ 4 รายงานผลควรสามารถแบ่งเป็ นรายวัน รายเดือน รายปี
ความคิ ดเห็ นเพิ่มเติ มที่ 5 โดยรวมโปรแกรมที่ส ร้ างขึ้นมานี้ อาํ นวยความสะดวกมากขึ้ น
กว่าเดิมมากแต่เชื่อว่ายังสามารถพัฒนาต่อไปได้อีก
จากแบบสํ า รวจสามารถแยกแต่ ล ะส่ วนเพื่อประเมิ นความพึ ง พอใจในแต่ ล ะด้า นเพื่อใช้
สําหรับเป็ นข้อมูลเพื่อทําการพัฒนาได้ในอนาคต โดยในแต่ละส่ วนได้ระดับของความพึงพอใจดังนี้
ความถูกต้องของโปรแกรมเปรี ยบเทียบกับงานจัดซื้ อ ได้คะแนนเฉลี่ย 4.57 (จากคะแนนเต็ม 5)
ความครบถ้วนของโปรแกรมในงานจัดซื้ อ ได้คะแนนเฉลี่ย 4.57 (จากคะแนนเต็ม 5)
48
ความถูกต้องในส่ วนของการรับส่ งข้อมูลของโปรแกรม ได้คะแนนเฉลี่ย 4.42 (จากคะแนนเต็ม 5)

แสดงให้เห็นว่าระดับความพึงพอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดี
ความถูกต้องส่ วนบันทึกข้อมูล ได้คะแนนเฉลี่ย 4.50 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับ
ความพึงพอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดี
ความถูกต้องของส่ วนรายงานผล ได้คะแนนเฉลี่ย 4.50 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับ
ความสะดวกและง่ายต่อการใช้งาน ได้คะแนนเฉลี่ย 4.50 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับ
ความเสถียรของโปรแกรม ได้คะแนนเฉลี่ย 4.14 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับความพึง
พอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดี
ความสวยงามของโปรแกรม ได้คะแนนเฉลี่ย 4.64 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับความ
พึงพอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดีมาก
ลักษณะของฐานข้อมูลและโปรแกรมง่ายต่อการพัฒนาเพิ่มเติมในอนาคต ได้คะแนนเฉลี่ ย 4.79
(จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับความพึงพอใจของหัวข้อนี้ อยูใ่ นเกณฑ์ดีมาก
บทที่ 5
สรุ ปผลและข้ อเสนอแนะ
5.1 สรุ ปผลการวิจัย

จากการทดสอบการใช้งานโปรแกรมจัดซื้ อเครื่ องมื อแพทย์ด้วยระบบอิเล็กทรอนิ กส์ เมื่อ
นํามาเปรี ยบเทียบกับระบบเดิมที่มีการใช้งานระบบจะเข้ามาช่วยในกระบวนการจัดซื้ อซึ่ งแยกออก
ได้ในแต่ละส่ วนงานดังนี้
5.1.1 ส่ วนของผูต้ อ้ งการจัดซื้ อ (User)
เป็ นส่ ว นของผูร้ ้ อ งขอหรื อแสดงความต้องการการขอซื้ อ โดยข้อมู ล การขอสั่ ง ซื้ อใน
โปรแกรมนั้น รายละเอี ยดของการกรอกข้อมูลเป็ นส่ วนที่มีผลทําให้กระบวนการจัดซื้ อมีความ
รวดเร็ วและถูกต้องมากยิ่งขึ้ นเมื่อเปรี ยบเทียบกับการจัดซื้ อระบบเดิม เนื่ องจากผูข้ อซื้ อเครื่ องมือ
แพทย์สามารถขอซื้ อและแก้ไขข้อมูลการขอซื้ อจากที่ใ ดก็ได้ถ้าผูข้ อมีอุปกรณ์ อิเล็กทรอนิ ก ส์ ที่
สามารถเชื่ อมต่ออิ นเทอร์ เน็ ตได้ และระบบยัง มีระบบเก็บข้อมูลการจัดซื้ อทําให้สามารถเรี ยกดู
ข้อมูลการจัดซื้ อที่ผา่ นมาเพื่อศึกษารายละเอียดของเครื่ องมือแพทย์ที่ตอ้ งการจัดซื้ ออีกด้วย
5.1.2 ส่ วนของเจ้าหน้าที่จดั ซื้ อ (Procurement)
เป็ นส่ วนที่ทาํ หน้าที่ตรวจสอบและทําความเข้าใจความต้องการของผูข้ อซื้ อ รวมถึงคัดเลือก
และประเมิ น ผู ้ข ายที่ มี คุ ณ สมบัติ ต รงตามความต้อ งการของผู้ข อซื้ อ และระเบี ย บปฏิ บ ัติ ข อง
โรงพยาบาล โดยระบบจะมีระบบการบันทึกข้อมูลของผูข้ ายทําให้สามารถส่ งข้อมูลให้ผขู้ ายได้
อย่างรวดเร็ วและถูกต้องมากกว่าเมื่อเทียบกับระบบเดิม เมื่อผูข้ ายส่ งข้อมูลกลับมาระบบจะทําหน้าที่
เปรี ยบเทียบให้อตั โนมัติเพื่อช่วยสนับสนุ นหรื อช่วยให้ผมู้ ีอาํ นาจตัดสิ นใจสามารถตัดสิ นใจได้ง่าย
ขึ้น
5.1.3 ส่ วนของผูม้ ีอาํ นาจตัดสิ นใจ (Authorized Person)
เป็ นผูต้ ดั สิ นใจในการเลื อกซื้ อกับผูข้ ายรายใดรายหนึ่ ง โดยใช้ขอ้ มูลที่ได้รับจากเจ้าหน้าที่
จัดซื้ อและผูข้ าย ซึ่ งหากข้อมูลที่ได้รับมาเอื้อต่อการตัดสิ นใจจะทําให้สามารถสั่งซื้ อสิ นค้าได้รวดเร็ ว
ขึ้น ซึ่งนอกจากการที่ระบบทําการเปรี ยบเทียบข้อมูลให้แล้วผูม้ ีอาํ นาจตัดสิ นใจสามารถตกลงสั่งซื้ อ
สิ นค้าได้ทนั ที โดยระบบจะทําการส่ งใบสั่งซื้ อให้ผขู้ ายแบบอัตโนมัติ ทําให้ประหยัดและรวดเร็ ว
กว่าเมื่อเปรี ยบเทียบกับการจัดซื้ อระบบเดิม
50
5.1.4 ส่ วนของผูข้ าย (Customer)

เป็ นผูเ้ สนอราคาเครื่ องมือแพทย์ตามความต้องการของเจ้าหน้าที่จดั ซื้ อ ซึ่ งข้อมูลที่ได้หากมี
รายละเอียดที่ครบถ้วนจะทําให้เสนอราคาได้อย่างถูกต้องและตรงตามความต้องการของผูซ้ ้ื อมาก
ที่สุด
5.1.5 ส่ วนของเจ้าหน้าที่ดูแลระบบ (Administrator)
เป็ นส่ ว นผูด้ ู แ ลระบบและทํา หน้า ที่ ก ํา หนดขอบเขตการเข้า ถึ ง ด้า นการใช้ง านของผูใ้ ช้
โปรแกรม รวมถึ งเพิ่มเติมข้อมูลรายระเอียดต่างๆ ในกระบวนการจัดซื้ อประกอบด้วย ผูใ้ ช้งาน,
รายชื่อผูข้ าย, ยีห่ อ้ เครื่ องมือแพทย์ และประเภทของเครื่ องมือแพทย์ ซึ่ งส่ วนนี้อาจดูเหมือนเป็ นส่ วน
ที่ตอ้ งเพิม่ บุคลากรเข้ามา แต่ถา้ วิเคราะห์ให้ดีแล้วส่ วนงานดังกล่าวสามารถใช้เจ้าหน้าที่ที่ดูแลระบบ
สารสนเทศของโรงพยาบาลที่มีอยูไ่ ด้ และยังสามารถลดงานและต้นทุนได้เมื่อเปรี ยบเทียบจากการ
จัดซื้ อแบบเดิ ม เพราะจะลดค่าใช้จ่ายจากอุปกรณ์เพิ่มเติมบางอย่าง เช่ น เครื่ องพิมพ์ เครื่ องสําเนา
เอกสาร หรื อแฟกซ์ เป็ นต้น
โปรแกรมจัดซื้ อเครื่ องมือทางการแพทย์ดว้ ยระบบอิเล็กทรอนิ กส์ สามารถทําการตอบสนอง
กระบวนการการจัดซื้ อได้ตามกระบวนการคือ การขอสั่งซื้ อ การกําหนดคุณสมบัติ การคัดเลือก
ผูข้ าย การเสนอราคา การพิ จารณาเลื อกซื้ อ การออกใบสั่ง ซื้ อ และเก็ บ ข้อมูล การจัดซื้ อ โดย
กระบวนการทั้งหมดเป็ นระบบอิเล็กทรอนิกส์และทํางานผ่านระบบอินเทอร์ เน็ต ซึ่ งกระบวนการที่
กล่าวมาเมื่อเปรี ยบเทียบกับระบบจัดซื้ อแบบเดิมจะเห็นว่าโปรแกรมจัดซื้ อเครื่ องมือแพทย์ช่วยงาน
ของกระบวนการจัดซื้ อในทุกส่ วนงาน โดยรวมแล้วโปรแกรมช่วยเพิ่มศักยภาพกระบวนการจัดซื้ อ
ทั้งด้านความสะดวก ความรวดเร็ ว และลดต้นทุนให้กบั โรงพยาบาล และจากผลการประเมินจาก
ผูท้ ดลองใช้งาน ได้แก่ แผนกกายภาพบําบัด แผนกจัดซื้ อ แผนกเทคโนโลยีสารสนเทศ ผูข้ าย โดยมี
ค่าระดับความพึงพอใจเฉลี่ย 4.52 (คะแนนเต็ม 5) ผลที่ได้จากการทดลองได้แสดงให้เห็นว่าระดับ
ความพึงพอใจของผูท้ ดลองใช้งานที่มีต่อโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์
อยูใ่ นเกณฑ์ดี ซึ่ งถ้าหากแยกดูระดับความพึงพอใจตามหัวข้อเพื่อประเมินผล ได้ดงั นี้
ความถู กต้องของโปรแกรมเปรี ยบเทียบกับงานจัดซื้ อ ได้คะแนนเฉลี่ ย 4.57 (จากคะแนนเต็ม 5)
แสดงให้เห็นว่าระดับความพึงพอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดีมาก
ความครบถ้วนของโปรแกรมในงานจัดซื้ อ ได้คะแนนเฉลี่ย 4.57 (จากคะแนนเต็ม 5) แสดงให้เห็น
ว่าระดับความพึงพอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดีมาก
ความถูกต้องในส่ วนของการรับส่ งข้อมูลของโปรแกรม ได้คะแนนเฉลี่ย 4.42 (จากคะแนนเต็ม 5)
แสดงให้เห็นว่าระดับความพึงพอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดี
51
ความถูกต้องส่ วนบันทึกข้อมูล ได้คะแนนเฉลี่ย 4.50 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับ

ความถูกต้องของส่ วนรายงานผล ได้คะแนนเฉลี่ย 4.50 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับ
ความสะดวกและง่ายต่อการใช้งาน ได้คะแนนเฉลี่ย 4.50 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับ
ความเสถียรของโปรแกรม ได้คะแนนเฉลี่ย 4.14 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับความพึง
พอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดี
ความสวยงามของโปรแกรม ได้คะแนนเฉลี่ย 4.64 (จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับความ
พึงพอใจของหัวข้อนี้อยูใ่ นเกณฑ์ดีมาก
ลักษณะของฐานข้อมูลและโปรแกรมง่ายต่อการพัฒนาเพิ่มเติ มในอนาคต ได้คะแนนเฉลี่ ย 4.79
(จากคะแนนเต็ม 5) แสดงให้เห็นว่าระดับความพึงพอใจของหัวข้อนี้ อยูใ่ นเกณฑ์ดีมาก
5.2 ข้ อเสนอแนะ
จากผลการทดลองจะเห็นว่ายังมีหวั ข้อที่ใช้ในการประเมินบางหัวข้อยังมีระดับความพึงพอใจ
ที่ยงั ไม่ดีเท่าที่ควรคือความเสถียรของโปรแกรม ซึ่ งปัญหาที่ข้ ึนระหว่างทดลองใช้งานคือระหว่างใช้
งานหากการเชื่ อมต่ออิ นเทอร์ เน็ ตเกิ ดการผิดปกติ ระบบจะไม่สามารถทํางานได้และเมื่อแก้ใ ห้
อินเทอร์ เน็ตสามารถใช้งานได้ตามปกติแล้ว ระบบก็ยงั ไม่สามารถทํางานต่อเนื่องได้จาํ เป็ นต้องปิ ด
โปรแกรมและทําการเข้าสู่ ระบบอีกครั้งและเริ่ มบันทึกค่าต่างๆ ใหม่อีกครั้ง
นอกจากนี้ โปรแกรมยังสามารถพัฒนาเพิ่มรายละเอียดข้อมูล รวมถึงระบบแจ้งเตือนให้กบั
ผูใ้ ช้ง านและยังสามารถเพิ่ม ขี ดความสามารถโดยเพิ่ม ระบบจัดการทางบัญชี และระบบการเงิ น
เพื่อให้ครอบคลุมระบบการจัดซื้ อเครื่ องมือแพทย์ให้มีศกั ยภาพยิง่ ขึ้น
บรรณานุกรม
ภาษาไทย
กระบวนการจัดซื้ อด้วยระบบอิเล็กทรอนิกส์. [ออนไลน์]. 2545. [สื บค้นวันที่ 18 สิ งหาคม 2555]
จาก http://www.guru-ict.com
กรี วธุ อัศวคุปตานนท์. ASP.net & SQL Server by C# เรี ยนรู้สุดยอดเทคโนโลยีล่าสุ ดในการ
พัฒนา Web ขั้นสู ง. พิมพ์ครั้งที่ 1. กรุ งเทพฯ : บริ ษทั เน็ตดีไซน์ พับลิชชิ่ง จํากัด, 2555.
กิตติ ภักดีวฒั นะกุล. Visual Basic 6 ฉบับฐานข้อมูล. กรุ งเทพฯ : KTP Comp and Consult,
2546.
ทิพวรรณ หล่อสุ วรรณรัตน์. e-Government รัฐบาลอิเล็กทรอนิกส์. พิมพ์ครั้งที่ 2. กรุ งเทพฯ :
รัตนไตร, 2549.
พนิดา ทรัพย์อุดม. การจัดซื้ อจัดจ้างด้วยระบบจัดซื้ อจัดจ้างทางอิเล็กทรอนิกส์ ฝ่ ายการพัสดุการ
ท่าเรื อแห่งประเทศไทย. ปั ญหาพิเศษการศึกษามหาบัณฑิต สาขาวิชาการบริ หารทัว่ ไป
วิทยาลัยการบริ หารรัฐกิจ มหาวิทยาลัยบูรพา, 2547.
พันจันทร์ ธรวัฒนเสถียร. SQL Server 2000 ฉบับสมบูรณ์. กรุ งเทพฯ : Success Media, 2548.
วันทนีย ์ วิวรรธนาภาสกร. การศึกษาปั ญหาและอุปสรรคในการนํานโยบายจัดซื้ อจัดจ้างทาง
อิเล็กทรอนิกส์ไปปฏิบตั ิ : ศึกษาเฉพาะหน่วยงานกรุ งเทพมหานคร. วิทยานิพนธ์
รัฐศาสตรมหาบัณฑิต คณะรัฐศาสตร์ มหาวิทยาลัยธรรมศาสตร์ , 2550.
สวลี เจริ ญสถาพร. แนวทางการปรับปรุ งการจัดซื้ อจัดจ้างตามแผนปฏิรูปราชการภายใต้ระบบ
e-Procurement : ศึกษากรณี กองจัดหาการสื่ อสารแห่งประเทศไทย. วิทยานิพนธ์
รัฐศาสตรมหาบัณฑิต คณะรัฐศาสตร์ จุฬาลงกรณ์มหาวิทยาลัย, 2546.
สํานักงานมาตรฐานพัสดุภาครัฐ, กรมบัญชีกลาง, กระทรวงการคลัง. คู่มือการดําเนิ นการจัดหา
พัสดุโดยวิธีประมูลด้วยระบบอิเล็กทรอนิกส์ (e-Procurement). กรุ งเทพมหานคร, 2545.
สิ ทธิศกั ดิ์ พฤกษ์ปิติกุล. Hospital Accreditation. กรุ งเทพฯ : สมาคมส่ งเสริ มเทคโนโลยี (ไทย-
ญี่ปุ่น), 2543.
สุ ทธิยา ภัทรโภคิน. การนําระบบจัดซื้ อจัดจ้างภาครัฐด้วยอิเล็กทรอนิกส์มาใช้ในองค์กรภาครัฐ :
ศึกษากรณี บริ ษทั วิทยุการบินแห่งประเทศไทย จํากัด. วิทยานิพนธ์รัฐศาสตรมหาบัณฑิต
คณะรัฐศาสตร์ จุฬาลงกรณ์มหาวิทยาลัย, 2545.
ภาคผนวก ก
รายละเอียดของโปรแกรม
54
using System;
using System.Collections.Generic;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using DevExpress.Web.ASPxGridView;
using CrystalDecisions.CrystalReports.Engine;
using CrystalDecisions.Shared;
using System.Windows.Forms;
using System.Net.Mail;
namespace emedequip
{ public partial class Compare : System.Web.UI.Page
{ private emedequipdbEntities conn = new emedequipdbEntities();
protected void Page_Load(object sender, EventArgs e)
{ int oid = Request.QueryString["oid"] != null ?

Convert.ToInt32(Request.QueryString["oid"]) : 0;
GetReqSpec(oid);
55
if(Session["weight"].ToString() == "3"){ Label4.Visible = false;
orderwith.Visible = false;
ASPxButton1.Visible = false; } }
public void GetReqSpec(int oid)
{ var required = (from i in conn.Orders where i.id == oid && i.deleted == false select
i).FirstOrDefault();
if (required != null)
{ title.Text = required.Title.name;
subtitle.Text = required.subtitle;
reqDesc.Text = required.description;
helperClass.MainspecDirectManage mainspec = new
//Mail message
string fromTitle = "Emedequip.net";
string mailSubject = "Purchase Request from Emedequip.net";
string mailBody = "HI {0} ";
mailBody += "this is Email to send Purchase Request From Emedequip.net ";
mailBody += "Please follow this below link to add your qoutation into Emedequip.net
system. ";
56
mailBody += "<a
href=\"http://www.emedequip.net/Quotation.aspx?oid={1}&sid={2}\">Enter Your
Quotation</a> ";
mailBody += "Best Regard Emedequip staff.";
client.Send(mailBody); }
protected void addVendorBtn_Load(object sender, EventArgs e)
{ ((ASPxButton)sender).Visible = !this.vendorGrid.IsEditing; }
protected void returnBtn_Click(object sender, EventArgs e)
{ if(Request.QueryString["oid"] != null)
{ int oid = Convert.ToInt32(Request.QueryString["oid"]);
var order = (from i in conn.Orders where i.id == oid select i).FirstOrDefault();
order.owner = 1;
conn.Orders.ApplyCurrentValues(order);
conn.SaveChanges(); }
Response.Redirect("home.aspx"); }
protected void refuseBtn_Click(object sender, EventArgs e)
{ if (Request.QueryString["oid"] != null)
{ int oid = Convert.ToInt32(Request.QueryString["oid"]);
var order = (from i in conn.Orders where i.id == oid select i).FirstOrDefault();

57
order.refuse = true;
conn.Orders.ApplyCurrentValues(order);
conn.SaveChanges(); }
Response.Redirect("home.aspx"); } } }
using System;
using System.Linq;
using System.Web;
namespace emedequip
{ public partial class purchasedReport : System.Web.UI.Page
{ private emedequipdbEntities conn = new emedequipdbEntities();
{ int oid = Request.QueryString["oid"] != null ?

GetReqSpec(oid); }
private void GetReqSpec(int oid)

58
{ var required = (from i in conn.Orders where i.id == oid && i.deleted == false select
if (required != null)
{ title.Text = required.Title.name;
subtitle.Text = required.subtitle;
reqDesc.Text = required.description;
reqOpt.Text = required.optionalspec; } }
protected void mainspecListView_ItemCreated(object sender, ListViewItemEventArgs e)
{ if (!Page.IsCallback && !Page.IsPostBack)
{ Offer offer = (Offer)e.Item.DataItem;
helperClass.offerMainSpecDirectManage offmng = new

helperClass.offerMainSpecDirectManage();
GridView grid = (GridView)e.Item.FindControl("mainSpecGridView");
if (grid != null)
{ grid.DataSource = offmng.getMainSpecCompare(offer.id);
grid.DataBind(); } } }
protected void vendorNameListView_ItemDataBound(object sender,

ListViewItemEventArgs e)
{ if (e.Item.ItemType == ListViewItemType.DataItem)
{ ListViewDataItem dataitem = (ListViewDataItem)e.Item;

59
int id = (int)DataBinder.Eval(dataitem.DataItem, "id"); } }
protected void imgListView_ItemDataBound(object sender, ListViewItemEventArgs e)
int id = (int)DataBinder.Eval(dataitem.DataItem, "id");
if (id == Convert.ToInt32(Request.QueryString["ofid"]))
{ System.Web.UI.HtmlControls.HtmlTableCell cell =
(System.Web.UI.HtmlControls.HtmlTableCell)e.Item.FindControl("imgTd3");
cell.Style.Add("background-color", "#FF8E8E"); } } }
protected void descListView_ItemDataBound(object sender, ListViewItemEventArgs e)
protected void mainspecListView_ItemDataBound(object sender, ListViewItemEventArgs

e)
protected void OptListView_ItemDataBound(object sender, ListViewItemEventArgs e)

60
int id = (int)DataBinder.Eval(dataitem.DataItem, "id");
if (id == Convert.ToInt32(Request.QueryString["ofid"]))
{ System.Web.UI.HtmlControls.HtmlTableCell cell =
(System.Web.UI.HtmlControls.HtmlTableCell)e.Item.FindControl("optTd7");
cell.Style.Add("background-color", "#FF8E8E"); } } }
protected void Price1ListView_ItemDataBound(object sender, ListViewItemEventArgs e)
protected void price2ListView_ItemDataBound(object sender, ListViewItemEventArgs e)
protected void price3ListView_ItemDataBound(object sender, ListViewItemEventArgs e)

61
protected void warantyListView_ItemDataBound(object sender, ListViewItemEventArgs e)
protected void attachFileListView_ItemDataBound(object sender, ListViewItemEventArgs e)
protected void noteListView_ItemDataBound(object sender, ListViewItemEventArgs e)
protected void submitListView_ItemDataBound(object sender, ListViewItemEventArgs e)
int id = (int)DataBinder.Eval(dataitem.DataItem, "id"); } } } }
using System;
using System.Linq;
62
using System.Web;
using DevExpress.Web.ASPxEditors;
using DevExpress.Web.ASPxGridView;
using emedequip.helperClass;
namespace emedequip
{ public partial class Quotation : System.Web.UI.Page
{ emedequipdbEntities conn = new emedequipdbEntities();
{ if (!IsPostBack && !IsCallback)
{ Session["_mainspec"] = null;
Session["_mainSpecId"] = -1; //Dummy Id for ListView when empty order mainspec
int oid = (Request.QueryString["oid"] != null) ?

Orders order = (from i in conn.Orders where i.id == oid select i).FirstOrDefault();
if (order != null)
{ subtitleLbl.Text = order.subtitle;
reqDesc.Text = order.description;
63
reqOpt.Text = order.optionalspec;
expire.Value = order.expiredate; }
int sid = (Request.QueryString["sid"] != null) ?

Convert.ToInt32(Request.QueryString["sid"]) : 0;
Offer offer = (from i in conn.Offer where i.oid == oid && i.sid == sid select
if (offer != null)
{ yourDesc.Text = offer.description;
yourOpt.Text = offer.optionalSpec;
yourPrice1.Text = offer.price1.ToString();
waranty.Value = offer.waranty;
yourNote.Text = offer.note; } } }
protected void addMainSpecBtn_Load(object sender, EventArgs e)
{ ((ASPxButton)sender).Visible = !this.yourMainSpec.IsEditing; }
protected void saveBtn_Click(object sender, EventArgs e)
{ try
{ int oid = (Request.QueryString["oid"] != null) ?

64
int sid = (Request.QueryString["sid"] != null) ?

Convert.ToInt32(Request.QueryString["sid"]) : 0;
Offer offer = (from i in conn.Offer where i.oid == oid && i.sid == sid select
if (offer == null)
{ offer = new Offer(); }
offer.description = yourDesc.Text;
offer.optionalSpec = yourOpt.Text;
if (yourPrice1.Text != "") offer.price1 = Convert.ToDecimal(yourPrice1.Text); else

offer.price1 = null;


offer.submitdate = DateTime.Now;
offer.note = yourNote.Text;
offer.waranty = Convert.ToInt16(waranty.Value);
offer.deleted = false;
offer.oid = oid;
offer.sid = sid;
65
if (offer.id == 0)
conn.Offer.AddObject(offer);
else
conn.Offer.ApplyCurrentValues(offer);
conn.SaveChanges();
Response.Redirect("Quotation.aspx?oid=" + oid + "&sid=" + sid); }
catch (Exception)
{ throw; } } } }
using System;
using System.Linq;
using System.Web;
namespace emedequip
{ public partial class ReadyOrderList : System.Web.UI.Page
{ protected void Page_Load(object sender, EventArgs e); } }
using System;
66
using System.Linq;
using System.Web;
namespace emedequip
{ public partial class register : System.Web.UI.Page
using System;
using System.Linq;
using System.Web;
namespace emedequip
{ public partial class report : System.Web.UI.Page
using System;
using System.Linq;
67
using System.Web;
using System.Web.Security;
namespace emedequip
{ public partial class Site1 : System.Web.UI.MasterPage
{ protected void Page_Load(object sender, EventArgs e)
{ if (Page.User.Identity.IsAuthenticated)
{ userLabel.Text = Page.User.Identity.Name + '(' + Session["RoleName"] + ')'; }
else
{ HomeLink.Visible = false;
userLabel.Visible = false;
PRlink.Visible = false;
OrderListLink.Visible = false;
CompareLink.Visible = false;
//PurchaseLink.Visible = false;
ReportLink.Visible = false;
SetupLink.Visible = false;
signout.Visible = false; }
68
int w = Convert.ToInt32(Session["weight"]);
switch(w)
{ case 1:
OrderListLink.Visible = false;
CompareLink.Visible = false;
break;
case 2:
break;
break; } }
protected void signout_Click(object sender, EventArgs e)
{ Session.Abandon();
FormsAuthentication.SignOut();
Response.Redirect("default.aspx"); } } }
ภาคผนวก ข
ความสัมพันธ์ระหว่างข้อมูลและพจนานุกรมข้อมูล
ความสั มพันธ์ ระหว่างข้ อมูล (Entity-Relationship Diagram) 70
ภาพที่ ข-1 ความสัมพันธ์ระหว่างข้อมูล

71
พจนานุกรมข้ อมูล (Data Dictionary)
ตารางที่ ข-1 ตารางแสดงบทบาท (Roles)

ชื่อเขตข้อมูล คําอธิ บาย ชนิดของข้อมูล คีย ์ อ้างอิง
Id รหัสรหัสตําแหน่ง int PK
Weight ระดับของตําแหน่ง int
Name ชื่อตําแหน่ง int
Nickname ชื่อเล่น nvarchar(50)
ตารางที่ ข-2 ตารางแสดงผูใ้ ช้งาน (Users)

ชนิดของ
ชื่อเขตข้อมูล คําอธิ บาย คีย ์ อ้างอิง
ข้อมูล
Id รหัส int PK
Code รหัสพนักงาน int
Login ชื่อผูใ้ ช้ nvarchar(50)
Pwd รหัสผ่าน nvarchar(20)
Name ชื่อ nvarchar(50)
Address ที่อยู่ Text
Email อีเมล์ nvarchar(50)
Tel เบอร์ โทรศัพท์ nvarchar(20)
role_id รหัสตําแหน่ง nvarchar(20) FK Roles
Remark หมายเหตุ nvarchar(50)
Active เปิ ดใช้งาน bit
Deleted ลบแล้ว bit
ตารางที่ ข-3 ตารางแสดงผูข้ าย (Vendor)

Id รหัสอ้างอิง int PK
Name ชื่อ int
72
ตารางที่ ข-3 (ต่ อ)

Address ที่อยู่ Text
Email ปี nvarchar(50)
Tel เบอร์ โทร nvarchar(50)
description คําอธิ บาย Text
Active เปิ ดใช้ bit
ตารางที่ ข-4 ตารางแสดงผูข้ ายที่ได้รับการคัดเลือกให้เสนอราคา (Order Vendors)

Oid รหัสคําขอ int FK Orders
cid รหัสผูจ้ าํ หน่าย int FK Vendor
ตารางที่ ข-5 ตารางแสดงรายละเอียดคุณสมบัติหลัก (Order Main Specification)

Oid รหัสคําขอ int FK Orders
Spec เสป็ กหลัก nvarchar(100)
description รายละเอียด nvarchar(100)
ตารางที่ ข-6 ตารางแสดงรายการสั่งซื้ อ (Orders)

ข้อมูล
titleID รหัสหัวข้อ int FK Title
73

ข้อมูล
Subtitle หัวข้อรอง nvarchar(50)
description รายละเอียด Text
optionalspec เสป็ กรอง Text
createdate วันที่สร้าง date
createby สร้างโดย int FK users
Owner เจ้าของ int FK users
expiredate วันหมดอายุ date
purchasedate วันที่ซ้ือ date
purchaseoffer ซื้ อจาก int FK offer
ตารางที่ ข-7 ตารางแสดงรายละเอียดจากการเสนอราคา (Offer)

ข้อมูล
Oid รหัสคําขอ int
Sid รหัสผูผ้ ลิต int
description คําอธิ บาย text
optionalspec สเป็ กรอง text
Price1 ราคา 1 double
Warranty จํานวนปี รับประกัน int
Note หมายเหตุ text
submitdate วันที่บนั ทึก date
Img รู ปภาพ nvarchar(255)
74
ตารางที่ ข-8 ตารางแสดงรายละเอียดจากการเสนอราคาเฉพาะคุณสมบัติหลัก (Offer Main

Specification)
Fid รหัสใบเสนอราคา int FK Offer
Spec รายละเอียดหลัก nvarchar(200)
ตารางที่ ข-9 ตารางแสดงชื่อ (Title)

Name ชื่อ nvarchar(100)
ตารางที่ ข-10 ตารางแสดงยี่หอ้ แนะนําที่จดั เก็บในระบบ (Brand Prefer)

Brand ยีห่ อ้ nvarchar(100)
ตารางที่ ข-11 ตารางแสดงยี่หอ้ ที่ผขู ้ อซื้ อแนะนํา (Order Brand Prefer)

Oid รหัสคําขอ int FK Order
75

Bid รหัสยีห่ อ้ int FK Brand Prefer
ภาคผนวก ค
ดัชนีขอ้ มูล
77
D1 = Purchase Requisition Data
D2 = User Data
D3 = Vendor Data
D4 = Brand Prefer Data
D5 = Order Title Data
D6 = Require Specification
D7 = Selected Brand Prefer
D8 = Selected Vendor
D9 = Title
D10 = Brand Prefer
D11 = Vendor
D12 = Selected Vendor
D13 = Selected Title
D14 = Selected Brand Prefer
D15 = Purchase Requisition Offer

78
ประวัติผ้วู จิ ัย
ชื่อ : นายก้องเกียรติ มีใหญ่

ชื่อวิทยานิพนธ์ : การออกแบบและพัฒนาโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบ
อิเล็กทรอนิกส์
สาขาวิชา : อุปกรณ์การแพทย์
ประวัติ
ประวัติส่วนตัว เกิดเมื่อวันที่ 19 สิ งหาคม พ.ศ. 2527 ที่จงั หวัดกรุ งเทพฯ
ประวัติการศึกษา ในเดือนเมษายน พ.ศ. 2548 จบปริ ญญาตรี สาขา อุปกรณ์ชีวการแพทย์
ภาควิชาฟิ สิ กส์ จากคณะวิทยาศาสตร์ ที่มหาวิทยาลัยรังสิ ต และได้ศึกษาต่อที่สาขาวิชาอุปกรณ์
การแพทย์ ภาควิช าฟิ สิ ก ส์ อุตสาหกรรมและอุ ป กรณ์ ก ารแพทย์ คณะวิท ยาศาสตร์ ป ระยุก ต์ที่
มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนือ ในเดือนมิถุนายน พ.ศ. 2551
สถานที่ติดต่อ 622/303 ถนนอโศก-ดินแดง แขวงดินแดง เขตดินแดง จังหวัดกรุ งเทพฯ

Final 12

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final 12

Uploaded by

Copyright:

Available Formats

การออกแบบและพัฒนาระบบจัดซื้ ออิเล็กทรอนิกส์สาํ หรับเครื่ องมือแพทย์

วิทยานิพนธ์น้ ีเป็ นส่ วนหนึ่งของการศึกษาตามหลักสู ตร

คําสําคัญ : โปรแกรมจัดซื้ อ จัดซื้ อเครื่ องมือแพทย์ จัดซื้ อระบบอิเล็กทรอนิกส์

Keywords : Procurement Application; Medical Equipment Procurement; Electronic

1.1 ความเป็ นมาและความสํ าคัญของปัญหา

1.2 วัตถุประสงค์ การศึกษาวิจัย

1.3.2 ออกแบบและสร้างโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบอิเล็กทรอนิกส์ และพัฒนา

1.4 ประโยชน์ ทคี่ าดว่ าจะได้ รับจากการศึกษาวิจัย

2.1 การประกันคุณภาพโรงพยาบาล (Hospital Accreditation , HA) (สิ ทธิศกั ดิ์, 2543)

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

2.2 เทคโนโลยีในการพัฒนาเว็ปไซต์ (Technology for Website Development) (กรี วธุ , 2555)

2.2.1 เอเอสพีดอทเน็ท (ASP.NET)

2.3 ระบบฐานข้ อมูล (Database)

สิ นค้า พนักงานขาย ลูกค้า

ภาพที่ 2-1 แสดงฐานข้อมูลการขายสิ นค้า

ตัวอย่างดังภาพที่ 2-1 แสดงฐานข้อมูลการขายสิ นค้า ซึ่ งประกอบไปด้วยตารางใบกํากับ

ภาพที่ 2-2 แสดงองค์ประกอบของระบบฐานข้อมูล

สําหรับ DBMS นับว่าเป็ นส่ วนสําคัญในระบบฐานข้อมูลเป็ นอย่างยิ่ง เปรี ยบเสมือนผูจ้ ดั การ

ชื่อฟิ ล์ด Customer ID Title Name Last name Telephone

ภาพที่ 2-3 แสดงตารางบันทึกข้อมูลลูกค้า

2.3.3 Structured Query Language (SQL)

ฐานข้อมูลจะต้องมีฟิลด์เพื่อเชื่ อมความสัมพันธ์ระหว่างตาราง และเรี ยกฟิ ลด์น้ ี วา่ Foreign Key

ภาพที่ 2-4 แสดงความสัมพันธ์แบบ 1-1

2.3.9.2.2 ความสัมพันธ์แบบ 1:M เป็ นความสัมพันธ์ที่ในหนึ่ งเรคอร์ ดของ

ภาพที่ 2-5 แสดงความสัมพันธ์แบบ 1-M

2.3.9.2.3 ความสัมพันธ์แบบ M:N เป็ นความสัมพันธ์ที่ขอ้ มูลหนึ่ งหรื อหลายเร

ภาพที่ 2-6 แสดงความสัมพันธ์แบบ M-N

2.3.10 โปรแกรมต่อประสานการประยุกต์เอสคิวแอล (SQL Application Program Interfaces)

พ.ศ.2530 การใช้ง านเอสคิ วแอลอาจจะอยู่ใ นรู ป ของการทํา งานสื บ ค้นข้อมู ล โดยโต้ตอบกับ

2.4 กระบวนการจัดซื้อด้ วยระบบอิเล็กทรอนิกส์ (E-Procurement)

2.4.1.2 เลือกหมวดสิ นค้าที่ตอ้ งการจะซื้ อผ่านรายการซื้ อขายระบบอิเล็กทรอนิ กส์ (E-

2.4.5.4 การเพิ่มความสามารถของระบบให้สูงขึ้น เพื่อให้เกิ ดบริ การมูลค่าเพิ่มต่างๆ

2.5 ผลการศึกษางานวิจัยทีเ่ กีย่ วข้ อง

พนิ ดา (2547) “การจัดซื้ อจัดจ้างด้วยระบบอิเล็กทรอนิ กส์ ” กล่าวว่าประโยชน์ที่ได้รับจากการ

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

3.1 เครื่องมือทีใ่ ช้ ในการวิจัย

ภาพที่ 3-1 โครงสร้างและกระแสข้อมูลของระบบจัดซื้ อเครื่ องมือแพทย์

3.3 ขั้นตอนการศึกษาปัญหาและความต้ องการจากระบบจัดซื้อเครื่องมือแพทย์

3.4 การวิเคราะห์ และออกแบบโปรแกรมจัดซื้อเครื่องมือแพทย์

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

1.0 2.0 Level 1

1.1 1.2 Level 2

1.1.1 1.1.2 Level 3

ภาพที่ 3-2 ตัวอย่างแผนภาพแสดงกระแสข้อมูลโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบ

3.4.1.1 ขั้นตอนที่ 1 แผนภาพกระแสข้อมูลระดับสู งสุ ด (Context Diagram) Level - 0

ภาพที่ 3-3 แผนภาพกระแสข้อมูลระดับสู งสุ ดโปรแกรมจัดซื้ อเครื่ องมือแพทย์ดว้ ยระบบ

3.4.1.2 ขั้นตอนที่ 2 แผนภาพกระแสข้อมูลระดับที่ 1 (Data Flow Diagram Level - 1)

ภาพที่ 3-4 แผนภาพกระแสข้อมูลระดับที่ 1 (Data Flow Diagram Level - 1)

คําอธิ บายการประมวลผลของแผนภาพกระแสข้อมูลระดับที่ 1 สามารถทําได้ดงั ต่อไปนี้

3.4.1.2.1 ผูใ้ ช้งาน (User)

ภาพที่ 3-5 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 1 การสร้างคําร้องขอซื้อ

จากภาพที่ 3-5 เป็ นกระบวนการที่เกี่ ย วกับ การสร้างใบคําร้องขอซื้ อ โดยจะนํารายละเอียด

จากการออกแบบแผนภาพกระแสข้อมูลระดับที่ 2 กระบวนการที่ 1 จะเห็นได้วา่ ประกอบไป

ภาพที่ 3-6 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของกระบวนการที่ 1.1 ขั้นตอนการสร้างคําร้อง

จากภาพที่ 3-6 เป็ นการแสดงการสร้างคําร้องขอซื้ อเพื่อจัดเก็บข้อมูลใบคําร้องขอซื้ อ โดย

ตารางที่ 3-2 ตารางรายละเอียดกระบวนการของขั้นตอนการสร้างคําร้องขอซื้ อ

ภาพที่ 3-7 แสดงแผนภาพกระแสข้อมูลระดับที่ 3 ของกระบวนการที่ 1.2 การอ่านข้อมูลคําร้องขอ

จากภาพที่ 3-7 เป็ นการแสดงการอ่านคําร้องขอซื้ อเพื่อจัดเก็บข้อมูลใบคําร้องขอซื้ อ โดยการ

ภาพที่ 3-8 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 2 แก้ไขคําร้องขอซื้ อ

จากภาพที่ 3-8 เป็ นการออกแบบการส่ วนของการแก้ไขคําร้องขอซื้ อโดยออกแบบให้มีหน้าที่

ลําดับต่อมาเป็ นการออกแบการแสดงถึงรายละเอียดของความสัมพันธ์การทํางานส่ วนของ

ภาพที่ 3-9 แสดงแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 3 การแสดงใบเสนอราคา

จากภาพที่ 3-9 เป็ นส่ ว นที่ อ อกแบบการแสดงรายการใบเสนอราคาตามคํา ร้ อ งขอซื้ อ

จากการออกแบบแผนภาพกระแสข้อมูลระดับที่ 2 ของกระบวนการที่ 3 ทําระบบต้องทําการ