รายงานวิจัย เรื่อง4.1 ผลการทดสอบกิจกรรมจากผ ู ร วมทดสอบท ั้ง 5 คน 32 4.2 ผลการทดสอบความคิดเห็นของผ

รายงานวิจัย

เร่ือง

การทดสอบความสามารถการใชงานในการตรวจสอบภายใน: กรณีศึกษาการทดสอบโปรแกรมระบบบริหารโครงการ

Usability Testing in Internal Auditing: Case Study of Project Management Software

โดย

รองศาสตราจารย อุษณา ภัทรมนตรี และ ดร. วรพรรณ เรืองผกา ภาควิชาบัญชี คณะบริหารธุรกิจ มหาวิทยาลัยเกษตรศาสตร

ไดรับทุนสนับสนุนการวิจัยจาก

คณะบริหารธุรกิจ มหาวิทยาลัยเกษตรศาสตร

พ.ศ. 2551

2

สารบัญ

หนา

สารบัญตาราง ....................................................................................................................... 4

สารบัญภาพ .......................................................................................................................... 4

บทที่ 1 ................................................................................................................................... 5

บทนํา .................................................................................................................................... 5

ความเป นมาของเรื่องที่วิจัย .............................................................................................................. 5

ความสําคัญของป ญหา ..................................................................................................................... 6

วัตถุประสงคของงานวิจัย ................................................................................................................. 7

ส่ิงที่คาดวาจะไดรับ ........................................................................................................................... 7

ขอบเขตของการวิจัย ........................................................................................................................ 8

บทที่ 2 ................................................................................................................................... 9

การตรวจเอกสาร .................................................................................................................. 9

ภูมิหลังและความเขาใจเบื้องตนเก่ียวกับองคกรกรณีศึกษา ............................................................ 9

แนวคิด ทฤษฏี และ งานวิจัยเก่ียวของ ........................................................................................... 10 ทฤษฎีการยอมรับและการใชเทคโนโลยี ......................................................................................... 10 ความสําคัญของการประเมินความสามารถในการใชงานของระบบ ................................................... 18 การทดสอบความสามารถการใชงาน .............................................................................................. 19 การตรวจสอบการควบคุมระบบสารสนเทศ ..................................................................................... 21

บทที่ 3 ................................................................................................................................. 24

วิธีการวิจัย .......................................................................................................................... 24

วิธีการศึกษา ................................................................................................................................... 24

รายละเอียดวิธีการตรวจสอบ ......................................................................................................... 24

ข้ันตอนในการตรวจสอบ ................................................................................................................ 27

วิธีการเก็บขอมูล ............................................................................................................................. 28

วิธีการวิเคราะหขอมูล ..................................................................................................................... 29

3

บทที่ 4 ผลและวิจารณ ........................................................................................................ 30

ผลการศึกษา ....................................................................................................................... 30 ขอมูลเบ้ืองตนของผูรวมทดสอบ .................................................................................................... 30 ผลการทดสอบความสามารถของระบบงานในเชิงปริมาณ ................................................................ 30 ผลการทดสอบความคิดเห็นเชิงคุณภาพ ......................................................................................... 33

บทที่ 5 ................................................................................................................................. 54

บทสรุปและขอเสนอแนะ .................................................................................................... 54

บทสรุป ............................................................................................................................................ 54

ขอเสนอแนะ ................................................................................................................................... 55

เอกสารและสิ่งอางอิง ......................................................................................................... 56

ภาคผนวก – แบบแบบฟอรมที่ใชในการเก็บขอมูล (Protocol for FMS) ............................ 58

ประวัติการศึกษาและการทํางาน ....................................................................................... 75

4

สารบัญตาราง

ตารางท่ี หนา

2.1 โครงสรางและแหลงที่มาของแบบสอบถามในทฤษฎี UTAUT 11 2.2 สรุปผลการศึกษาของ Venkatesh et al. (2003) 17 4.1 ผลและเวลาทีใ่ช (นาที) ในการทาํกิจกรรม 31 4.2 ตารางความคิดเห็นของผูทดสอบระบบที่มีตอโปรแกรม FMS 35 4.3 ความคิดเห็นของผูใชโปรแกรมระบบบริหารโครงการ 37 4.4 ผลการตรวจในรายละเอียดของปจจัยเชิงคุณภาพ 39

สารบัญภาพ

ภาพที่ หนา

2.1 The Unified Theory of Acceptance and Use of Technology Model 16 2.2 ความสามารถในการใชงานตามหลักการออกแบบทางวศิวกร 18 3.1 จํานวนผูรวมทดสอบกับอัตราการพบปญหา 25 4.1 ผลการทดสอบกิจกรรมจากผูรวมทดสอบทั้ง 5 คน 32 4.2 ผลการทดสอบความคิดเห็นของผูใชใน 6 ดาน 34

5

บทที่ 1 บทนํา

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

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

ในปจจุบันการประเมินผลคุณภาพระบบสารสนเทศขององคกรธุรกิจ เปนหัวขอหน่ึงที่ใช

ประเมินคุณภาพการจัดการของฝายบริหาร แนวคิดในการบริหารดังกลาวเริ่มจากในตางประเทศ เชน การใหรางวัลมัลคอมบริดจในประเทศสหรัฐอเมริกา ใชเกณฑการประเมินผลระบบสารสนเทศเปนเกณฑหน่ึงในการประเมินคุณภาพการจัดการขององคกรธุรกิจ เปนตน และประเทศไทยไดเริ่มนําแนวคิดการประเมินผลระบบสารสนเทศมาเปนเกณฑหน่ึงในการประเมินผลของฝายบริหารทั้งในภาคเอกชน สวนราชการ และรัฐวิสาหกิจ เชน การประเมินผลรางวลัคุณภาพแหงชาติ การประเมินผลการบริหารจัดการในหนวยงานภาครัฐ เปนตน

นอกจากนี้จากกรณีบรรษัทเอนรอน เวิลดคอม ฯลฯ ที่มีการตกแตงงบการเงิน และเกิด

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

6

ความสําคัญของปญหา

ปญหาความยุงยากในการใชเทคนิคการตรวจสอบโดยใชคอมพิวเตอรชวย (Computer Assisted Audit Techniques: CAATs) เปนปญหาและขอจาํกัดของแวดวงวิชาการและวิชาชีพการบัญชีในเกือบทุกประเทศทั่วโลก เน่ืองจากเปนปญหาขาดแคลนทั้งดานตัวบุคคลที่มีความรูและทักษะ ดานเทคนิคคอมพิวเตอรที่จะนํามาใช(Hunton et al, 2004) รวมท้ังการขาดแคลนงานศึกษาวิจัยเพ่ือสรางองคความรูใหม หัวของานวิจัยที่เกี่ยวกับการตรวจสอบระบบสารสนเทศจึงเปนหัวขอที่ไดรับความสนใจในดานวิชาการและวิชาชีพการตรวจสอบระบบสารสนเทศระดับสากล

สรุปความสาํคญัของปญหาการวจิัยในครั้งน้ีไดดังน้ี

1. โดยท่ัวไปความถูกตองของระบบสารสนเทศขององคกร ประกอบดวยการมีตัวเครื่องและอุปกรณ(Hardware) โปรแกรมระบบงาน (Software) ผูบริหารและผูใช (Peopleware) แตในปจจุบัน ความสนใจในการประเมินผลการควบคุมภายในของระบบสารสนเทศจะเนนไปที่ตัวเคร่ือง อุปกรณ เปนสวนใหญ รองลงมาคือ โปรแกรมระบบงาน และแทบจะละเลยความสําคัญของผูใชในขณะใชงานโปรแกรมระบบงาน ซ่ึงอาจเปนความเสี่ยงสําคัญที่ผูใชอาจไมยอมรับและตอตานการใชเทคโนโลยี (Nelson and Cheney, 1987) เน่ืองจากความยุงยากในการเปล่ียนแปลงระบบงาน การขาดการฝกอบรม การขาดผูชวยเหลือทางเทคนิคเมื่อตองการ และกลายเปนความลมเหลวในการใชและปรับปรุงการทํางานอยางมีประสิทธิภาพและประสิทธิผล (Fischer, 1996)

2. ตามมาตรฐานการตรวจสอบภายในที่ปรบัปรุงใหม ผูตรวจสอบจําเปนตองมีความรูในการนําเทคนิคการตรวจสอบโดยใชคอมพิวเตอรชวยมาใช เชน ในมาตรฐานของสมาคมผูตรวจสอบภายในที่ปรับปรุงและจะประกาศใชในป 2009 ขอ 1220-A2 กําหนดวาผูตรวจสอบภายในตองมีความรูอยางเพียงพอเกี่ยวกับความเสี่ยงและการควบคุมดานระบบสารสนเทศ รวมทัง้ตองนําเทคนิคการตรวจสอบที่ใชเทคโนโลยีชวยมาใชในการปฏิบัตงิานตรวจสอบ ขอกําหนดดังกลาวเปนปญหาท่ีสําคัญเพราะแมแตผูตรวจสอบและผูสอบบญัชีในตางประเทศ ยังขาดความรูและทักษะในดานดังกลาว และใช เทคนิคการตรวจสอบโดยใชคอมพิวเตอรชวยยังต่ํากวาท่ีควร (Curtis and Payne, 2008)

7

การทดสอบความสามารถการใชงาน (Usability Testing) จะชวยสอบทานการบริหารจัดการดานการใชงานระบบของผูใช (User Test) น้ัน เพ่ือที่จะปด ชองโหวของระบบงานที่ไมเคยไดรับการตรวจสอบ น่ันคือ อุปสรรคหรือความผิดพลาดที่เกิดจากในการใชงานของผูใชบนหนาจอระบบงาน เพ่ือท่ีจะสามารถสอบทานหรือคนพบขอผิดพลาด โดยเฉพาะดานไมความถูกตองขอมูล (Inaccuracy) และความไมครบถวนของขอมูล (Incompleteness) ซ่ึงเกิดจากการใชงานหนาจอระบบงานของผูใชในการนําเขาขอมูล น่ันเอง

วัตถุประสงคของงานวิจัย การศึกษาวิจัยในครั้งน้ี เพ่ือนําแนวคิดดานการทดสอบความสามารถการใชงาน มาประยุกต

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

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

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

การปรับปรุง • เพ่ือประเมินความพึงพอใจและการสอบทานการยอมรบัระบบของผูใชระบบงาน

ส่ิงที่คาดวาจะไดรับ

1. เปนนวัตกรรมใหมในการประยุกตเทคนิคการทดสอบความสามารถการใชงาน มาใชในการตรวจสอบระบบสารสนเทศ และวิชาชีพบัญชี

2. เปนประโยชนตอการศึกษาความรูดานการตรวจสอบภายใน และระบบสารสนเทศที่ประสบปญหาขาดแคลนผูมีความรูในปจจบุัน

3. เผยแพรชื่อเสียงของคณะบริหารธุรกิจ มหาวิทยาลัยเกษตรศาสตรในระดับประเทศและสากล

8

ขอบเขตของการวิจัย

งานวิจัยน้ีจะทดสอบโปรแกรมที่หนวยงานกรณีศึกษาพัฒนาเอง และทดสอบในฐานะที่ผูวิจัยรับผิดชอบในการตรวจสอบภายในของหนวยงานกรณีศึกษา โดยดําเนินการภาคสนามในระหวางปพ.ศ. 2550

9

บทที่ 2

การตรวจเอกสาร

ในบทที่ 2 จะกลาวถึง ภูมิหลังและความเขาใจเบื้องตนเกี่ยวกับการบริหารงานและระบบเทคโนโลยีสารสนเทศขององคกรกรณีศึกษา ความสําคญัของการประเมินความสามารถในการใชงานของระบบ รวมท้ังแนวคิด ทฤษฎี และผลการศึกษาและวจิัยที่เกี่ยวของ

ภูมิหลังและความเขาใจเบื้องตนเกี่ยวกับองคกรกรณีศึกษา องคกรกรณีศึกษาเปนองคกรอิสระ ใชปรัชญาการจัดโครงสรางใหเปนองคการขนาดเล็ก

แตมีประสิทธิภาพและประสิทธิผลสูงในการขับเคลื่อนและดําเนินงานตามนโยบายและแผนงานหลักดานตางๆ ตามที่คณะกรรมการองคกรวางไว

ในแตละแผนงานจะมีคณะกรรมการบริหารแผน ทําหนาที่อํานวยการและพัฒนาแผน

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

องคกรกรณีศึกษาไดพัฒนาแผนงานเทคโนโลยีสารสนเทศ ซ่ึงแผนงานและโปรแกรม

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

10

ผูศึกษาในฐานะผูเช่ียวชาญภายนอกไดตรวจสอบและประเมินผลแผนงานเทคโนโลยีสารสนเทศ ในรายงานนี้จะเนนการนําเทคนิคการทดสอบการใชงานของโปรแกรมระบบงานหลัก ซ่ึงตอไปจะเรียกวา ระบบบริหารโครงการ (Financial Management System: FMS) เปนระบบสารสนเทศหลัก และเช่ือมโยงกับระบบสนับสนุนภายในสํานักงาน (Back Office) ซ่ึงเปนระบบที่เกี่ยวกับการจายเงินและการบัญชี

FMS เปนโปรแกรมระบบบริหารโครงการ ที่องคกรกรณีศึกษาพัฒนาขึ้นเอง เพ่ือการ

บันทึกและจัดเก็บฐานขอมูลสําหรับการบริหารโครงการตางๆ ที่ใชในการบริหารจัดการโครงการ และเพื่อออกรายงานเพื่อการบริหาร แตกอนจะนําFMS มาใชงานจริงองคกรไมไดจัดทําการตรวจสอบประเมินผลและทดสอบการยอมรับของผูใช สวนการฝกอบรมใชการอบรมที่ใชระยะเวลาสั้นหรือเปนการอบรมแบบ On the Job Training ถึงแมวา FMS จะมีประโยชนในแงตางๆมาก เม่ือเทียบกับการจัดเก็บขอมูลโดยประมวลสารสนเทศดวยมือ แตก็ยังมีขอถกเถียงกันอยูมากสําหรับการนําระบบบริหารโครงการมาใชในองคกรกรณีศึกษา จากการสํารวจในเบื้องตนผูศึกษาไดสัมภาษณแบบรายบุคคล และการประชุมแบบเจาะจงกับทีมผูบริหารและพนักงานในองคกร (Focus group ) พบวามีทั้งเสียงตอบรับที่พอใจกับการใช FMS แตก็ยังมีผูบริหารหลายๆทานและพนักงานหลายๆคนที่ไดรับประสบการณที่ไมนาพึงพอใจจากการใช FMS เทาใดนัก

แนวคิด ทฤษฏี และ งานวิจัยเกี่ยวของ

ทฤษฎีการยอมรับและการใชเทคโนโลยี ในป ค.ศ.2003 Venkatesh, Davis, and Morris ไดเสนอทฤษฎีที่สรางขึ้นจากงานวิจัยตางๆ ที่ผานมาเกี่ยวกับการยอมรับเทคโนโลยี ซ่ึงทฤษฎีการยอมรับและการใชเทคโนโลยี (Unified Theory of Acceptance and Use of Technology: UTAUT) ไดอธิบายถึงการยอมรับเทคโนโลยีและการใชเทคโนโลยีของผูใชงาน โดยเปนทฤษฎีที่พัฒนามาจากทฤษฎีดานพฤติกรรมจํานวนทั้งส้ิน 8 ทฤษฎี คือ 1) ทฤษฎีที่ใชสําหรับการเชื่อมโยงระหวางความเชื่อและทัศนคติที่มีตอพฤติกรรม (Theory of Reasoned Action: TRA) 2) ทฤษฎีการยอมรับเทคโนโลยีของผูใชงาน เปนตัววัดความสําเร็จของการพัฒนาการใชเทคโนโลยี (Technology Acceptance Model: TAM)

11

3) ทฤษฎีที่ใชสําหรับการวิจยัในเร่ืองเกี่ยวกับจิตวิทยา เพ่ือใชสนับสนุนแรงจูงใจทีใ่ชอธิบายถึงการแสดงพฤติกรรม (Motivational Model: MM) 4) ทฤษฎีที่ศึกษาทางดานพฤติกรรม ซ่ึงไดรับการพัฒนาและขยายมาจากทฤษฎี TRA (Theory of Planned Behavior: TPB) 5) ทฤษฎีที่ผสมผสานกันระหวาง TAM กับ TPB เพ่ือใชสําหรับทดสอบการวิจัยที่เกี่ยวของกับปจจัยประสบการณการใชระบบ วามีอิทธิพลตอการปรับปรุงและการใชระบบเทคโนโลยีสารสนเทศหรือไม 6) ทฤษฎีที่ใชวัดการใชงานจริงในเทคโนโลยีและใชทํานายเกี่ยวกับการยอมรับและการใชเทคโนโลยีของแตละบุคคล (Model of PC Utilization: MPCU) 7) ทฤษฎีพ้ืนฐานทางสังคมทีใ่ชศึกษาเก่ียวกับความหลากหลายของปจจัยที่ใชอธิบายถึงนวัตกรรมและใชเปนเคร่ืองมือที่เกี่ยวของกับนวัตกรรมในองคกร (Innovation Diffusion Theory: IDT) และ 8) ทฤษฎีดานพฤติกรรมมนุษย ท่ีพบวา การเปลี่ยนแปลงพฤติกรรมของมนุษยน้ันเกิดจากอิทธิพลจากสิ่งแวดลอม ปจจัยสวนบุคคลและ คุณสมบัติดานพฤติกรรมสวนตัว (Social Cognitive Theory: SCT) Venkatesh et al. (2003) ไดศึกษาบริษัทและองคกร4 แหงที่กําลังประยุกตใชเทคโนโลยีใหม โดยเปนองคกรที่มีความแตกตางทางเทคโนโลยี ลักษณะองคกร ประเภทอุตสาหกรรม หนาที่องคกร และ ลักษณะการใชงาน เก็บรวบรวมขอมูลจากกลุมตัวอยางผูใชงานระบบ จํานวนทั้งส้ิน 654 ราย ทดสอบหาความเชื่อม่ันและความตรงดวยวิธีทางสถิติ Cronbach’ s Alpha ไดคาเทากับ 0 .70 และวิเคราะหขอมูลดวยวิธีทางสถิติ Partial Least Squares (PLS) โดยมีโครงสรางและแหลงท่ีมาของแบบสอบถามที่ใชในการทดสอบปจจัยตางๆ ดังแสดงในตารางที่ 2.1 ตารางที่ 2.1 โครงสรางและแหลงที่มาของแบบสอบถามในทฤษฎี UTAUT ความคาดหวังตอการปฏิบัติงาน (Performance Expectancy ) 1 TAM Theory ขาพเจาพบวาระบบ มีประโยชนตองานของขาพเจา 2 IDT Theory การใชงานระบบ ทําใหขาพเจาทาํงานไดสําเร็จรวดเร็วขึน้ 3 IDT Theory การใชงานระบบ ชวยใหขาพเจาไดงานท่ีมีประสิทธิภาพมากขึ้นในเวลาเทา

เดิม

12

ตารางที่ 2.1-ตอ ความคาดหวังเร่ืองความพยายามของผูใชงานระบบ (Effort Expectancy) 1 TAM Theory ขาพเจาคิดวา การใชงานเมนูในระบบน้ันเขาใจงายและชัดเจน 2 TAM Theory ขาพเจาจะกลายเปนผูมีความชํานาญในการใชระบบ เปนอยางดี ได

โดยงาย 3 TAM Theory ขาพเจาเห็นวาระบบ งายตอการใชงาน 4 IDT Theory ขาพเจาสามารถเรียนรูที่จะปฏิบัติงานบนระบบ ไดโดยงาย

ทัศนคติตอการใชงานระบบAttitude Toward Using Technology 1 TRA Theory ขาพเจาเห็นวาการใชงานระบบ เปนความคิดที่มีทั้งดีและไมดี 2 MPCU Theory ระบบ ทําใหการทํางานนาสนใจมากขึ้น 3 MPCU Theory ขาพเจารูสึกสนุกสนานไปกับการทํางานบนระบบ 4 SCT Theory ขาพเจาชอบทีจ่ะทาํงานบนระบบ

อิทธิพลจากสังคม (Social Influence) 1 TRA Theory บุคคลที่มีอิทธิพลตอขาพเจาคิดวาขาพเจาควรใชระบบ 2 TRA Theory บุคคลที่มีความสําคัญตอขาพเจาคิดวาขาพเจาควรใชระบบ 3 MPCU Theory ผูบริหารอาวุโสขององคกรไดใหความชวยเหลือเรื่องการใชระบบ

เสมอมา 4 MPCU Theory โดยทั่วไป องคกรไดใหการสนับสนุนเรื่องการใชงานระบบเสมอมา

สภาพของสิ่งอํานวยความสะดวกในระบบ (Facilitating Condition) 1 TPB Theory ขาพเจามีทรัพยากรตางๆ ( เชน การฝกอบรม คูมือการใชงาน

เจาหนาที่ดานไอที/ที่ปรึกษายามเกิดปญหา หรือ อ่ืนๆ) ที่จําเปนสําหรับการใชงานระบบ

2 TPB Theory ขาพเจามีความรูที่จําเปนสําหรับการใชงานระบบ 3 TPB Theory ระบบไมสามารถเขากันไดกับระบบอื่นๆ ที่ขาพเจาใชงาน 4 IDT Theory บุคคลหรือกลุมบุคคลที่มีความชาํนาญเปนพิเศษสามารถใหความ

ชวยเหลือไดตลอดเวลา เมื่อระบบเกิดปญหา

13

ตารางที่ 2.1-ตอ ความเชื่อม่ันของผูใชงานระบบ (Self-Efficacy: ขาพเจาสามารถใชระบบ ทํางานใหเสร็จสมบูรณได) 1 SCT Theory ขาพเจาสามารถใชระบบ ทํางานใหเสร็จสมบูรณได ดวยตัวของขาพเจาเอง

(โดยไมตองมีคนคอยชวยเหลือ) 2 SCT Theory ขาพเจาสามารถใชระบบ ทํางานใหเสร็จสมบูรณได ถามีคนคอยชวยเหลือ

เมื่อเกิดปญหา 3 SCT Theory ขาพเจาสามารถใชระบบทาํงานใหเสร็จสมบูรณได ถาขาพเจามีเวลามากพอ 4 SCT Theory ขาพเจาสามารถใชระบบ ทํางานใหเสร็จสมบูรณได ถามีเมนูชวยเหลือ (เชน

Help, Troubleshooting

ความกังวลใจของผูใชงานระบบ (Anxiety) 1 SCT Theory ขาพเจารูสึกหวาดกลัวไปลวงหนาถึงการใชงานระบบ 2 SCT Theory ขาพเจาเกิดความกังวลวาถาขาพเจากดผิดปุม หรือ คลิก (Click) ผิดที่ บน

หนาจอของระบบ จะทําใหขอมูลหลายๆอยางหายไป 3 SCT Theory ขาพเจาลังเลที่จะใชระบบ เพราะเกรงวาจะเกิดความผิดพลาดที่ขาพเจาจะไม

สามารถแกไขใหถูกตองดวยตนเองได 4 SCT Theory ระบบคอนขางที่จะทาํใหขาพเจารูสึกทอถอย

พฤติกรรมความตั้งใจที่จะใชงานระบบ (Behavioral Intention to Use the System) 1 Venkatesh,

2003 ขาพเจาตั้งใจทีจ่ะใชระบบ ภายในเดือนหนาหรือเดือนถัดๆไป

2 Venkatesh, 2003

ขาพเจาคาดไววาจะใชระบบ ภายในเดือนหนาหรือเดือนถัดๆไป

3 Venkatesh, 2003

ขาพเจาวางแผนที่จะใชระบบ ภายในเดือนหนาหรือเดือนถัดๆไป

ที่มา: Venkatesh et al. (2003)

14

ผลจากการเก็บรวบรวมและวิเคราะหขอมูลที่ไดจากตารางขางตน พบวามี 4 ปจจัยหลักที่มีอิทธิพลโดยตรงตอพฤติกรรมความตั้งใจทีจ่ะใชงานระบบ (Behavioral Intention) และการใชงานระบบ (Use Behavior) คือ

1. ความคาดหวังตอการปฏิบัตงิาน (Performance Expectancy ) คือ ระดับความเชือ่ของบุคคล วา การใชระบบจะทาํใหประสบผลสําเร็จในการปฏิบัติงาน ประกอบดวยปจจัยท่ีไดจากการพัฒนาและรวมทฤษฎีตางๆ 5 ปจจัย ดังน้ี 1.1 Perceived Usefulness คือ ระดับความเชื่อดานประโยชนของผูใชวา การใช

ระบบจะชวยเพ่ิมใหผลของการปฏิบัติงานดีขึ้น (TAM Model) 1.2 Extrinsic Motivation คือ ผูที่สามารถใชระบบ ในการปฏิบัติงานได จะนําไปสู

ผลงานที่มีคา และทาํใหไดรับในสิ่งที่ดีกวาผูอื่น เชน มีการปรับปรุงการปฏิบัติงาน ไดรับการขึ้นเงินเดือน หรือไดรับการเล่ือนตําแหนง (MM Model)

1.3 Job-fit คือ ความสามารถของระบบจะชวยเพ่ิมประสิทธิภาพในการปฏิบัติงานของแตละบุคคลได (MPCU Model)

1.4 Relative Advantage คือ ระดับของการใชระบบท่ีทาํใหเขาใจวาเปนส่ิงที่ดีกวาส่ิงท่ีผานมา (IDT Model)

1.5 Outcome Expectations คือ ความคาดหวังถึงผลลัพธที่เก่ียวของกับพฤติกรรม ซ่ึงสามารถแบงออกเปนความคาดหวังจากการปฏิบัติงานและความคาดหวังสวนบุคคล (SCT Model)

2. ความคาดหวังดานความพยายามของผูใชงานระบบ (Effort Expectancy) คือ ระดับความงายในการมีสวนรวมในการใชระบบ ประกอบดวย 3 ปจจัยหลัก ดังน้ี 2.1 Perceived Ease of Use คือ ระดับความเชื่อของบุคคลวา การใชระบบเทคโนโลยีไมตองใชความพยายามสูงในการใชงานมากนัก (TAM Model) 2.2 Complexity คือ ระดับของการเขาใจถึงความยากที่จะเขาใจและการใชระบบ (MPCU Model) 2.3 Ease of Use คือ ระดับของการใชระบบที่ทาํใหเขาใจวายากตอการใชงาน (IDT Model)

15

3. อิทธิพลจากสังคม (Social Influence) คือ ระดับการเขาใจของแตละบคุคลถึงความสําคัญทีจ่ะเชื่อวาควรใชระบบใหมๆ ในการปฏิบัติงาน ไดกําหนดปจจัยทางพฤติกรรม 3 ปจจัย ดังน้ี 3.1 Subjective Norm คือ ความเขาใจของบคุคลกับพฤติกรรมการแสดงออกของผู

มีอิทธิพลที่มีตอตนเอง (TRA Model) 3.2 Social Factors คือ สัมพันธภาพระหวางบุคคลที่แสดงออกถึงวัฒนธรรมและ

ขอตกลงระหวางบุคคลที่มีอยูในสถานการณสังคมนั้นๆ (MPCU Model) 3.3 Image คือ ระดับของการใชนวัตกรรม(ระบบ) ที่ทําใหเขาใจวาชวยเพ่ิม

ภาพลักษณหรือสถานะภาพทางสังคม (IDT Model) 4. สภาพของสิ่งอํานวยความสะดวกในระบบ (Facilitating Condition) คือ ระดับความ

เช่ือของบุคคลวา องคกรและสิ่งอํานวยความสะดวก/อุปกรณทางเทคโนโลยีที่มีอยู มีสวนชวยสนับสนุนตอการใชระบบ ประกอบดวย 3 ปจจยัท่ีกําหนดไว ดังน้ี 4.1 Perceived Behavioral Control คือ ความเขาใจถึงการรับรูอํานาจในการควบคมุระบบทั้งภายในและภายนอก (ภายใน คือผูใชระบบ เชน ความรูความสามารถของผูใชระบบ และภายนอก คือส่ิงอํานวยความสะดวกจากองคกร เชน คูมือปฏิบัติงาน เจาหนาที่ดาน IT) (TPB Model) 4.2 Facilitating Conditions คือ ปจจัยที่เก่ียวกับวัตถุประสงคดานสภาพแวดลอม เพ่ือสรางความงายในการปฏิบัติงาน รวมถึงการจัดเตรียมระบบการสนับสนุนดานอุปกรณคอมพิวเตอร (MPCU Model) 4.3 Compatibility คือ ระดับของการเขาใจระบบงานวา มีความถูกตอง เปนส่ิงจําเปน และเปนการปรับปรุงที่มีศักยภาพ (IDT Model)

นอกจากนี้ พบ 3 ปจจัยที่ไมมีอิทธิพลโดยตรงตอพฤติกรรมความตั้งใจที่จะใชงานระบบ คือ

1. ทัศนคติตอการใชงานระบบ (Attitude toward the Technology) คือ ปฏิกิริยาตอบสนองของผูใชที่มีตอการใชระบบ ประกอบดวยโครงสรางทีใ่ชในการพัฒนา คอื 1) Attitude toward behavior คือ ทัศนคติท่ีมีตอพฤติกรรม (TRA Model) , 2) Intrinsic motivation คือ การจูงใจจากภายใน (MM Model) , 3 ) Affect toward use คือ ผลกระทบจากการใชงาน (MPCU Model) และ 4) Affect คือ ผลที่เกิดขึ้น (SCT Model)

16

2. ความเช่ือมั่นของผูใชงานระบบ (Self-Efficacy) คือ การพิจารณาถึงความสามารถของบุคคลใดบุคคลหน่ึงในการใชเทคโนโลยีเพ่ือความสําเร็จของงาน โดยมีโครงสรางท่ีไดรับการพัฒนามาจาก SCT Model

3. ความกังวลใจของผูใชงานระบบ (Anxiety) คือ การพิจารณาถึงอารมณความรูสึกของผูใชงานระบบที่ตอบสนองเมื่อมีการใชงาน มีโครงสรางที่ไดรับการพัฒนามาจาก SCT Model เชนเดียวกับ Self-Efficacy นอกจากนั้นยังพบวา พฤติกรรมความตั้งใจท่ีจะใชงานระบบ (Behavioral Intention to

Use the System) มีอิทธิพลโดยตรงตอพฤติกรรมการใชระบบ (Use Behavior) ซ่ึง พฤติกรรมความตั้งใจทีจ่ะใชงานระบบ ไดรับการพัฒนามาจากทฤษฎี TAM (Davis, 1989) ไดใหคํานิยามไววา คือแผนสําหรับการใชงาน และ พฤติกรรมการใชระบบ หรืออีกนัยหน่ึงเรียกวา”การใชงานจริง (Actual Use)” น้ัน หมายถึง การวัดการกระทาํหรือการปฏิบัติของรายละเอียดการใชงานระบบ

งานวิจัยท่ีผานมาของ Venkatesh et al. (2003)พบวา ปจจัยที่เกี่ยวของกับโครงสราง

ทางดานทัศนคติที่มีอิทธิพลตอพฤติกรรมความตั้งใจทีจ่ะใชงานระบบนั้น สวนใหญจะพบอยูใน TRA Model, TPB Model และ MM Model และปจจัยที่ไมมีอิทธิพลตอพฤติกรรมความตั้งใจที่จะใชงานระบบ จะพบอยูใน MPCU Model, C-TAM-TPB Model และ SCT Model และจากผลการวิจัยทั้งหมด Venkatesh et al. (2003) ไดสรุปเปนแบบจําลอง (Model) ไวดังภาพที่ 2.1

ภาพที่ 2.1 The Unified Theory of Acceptance and Use of Technology (UTAUT) Model ที่มา: Venkatesh et al. (2003)

17

จากการวิเคราะหขอมูลเพ่ือการทดสอบสมมติฐานงานวจิัยของ Venkatesh et al. (2003) ไดผลสรุปของการศึกษาดังตารางที่ 2.2

ตารางที่ 2.2 สรุปผลการศึกษาของ Venkatesh et al. (2003)

ตัวแปรตาม (Dependent Variables)

ตัวแปรตน (Independent

Variables)

ตัวผันแปร (Moderators)

ผลอธิบาย (Explanation)

พฤติกรรมความตั้งใจในระบบ

ความคาดหวังตอการปฏิบัติงาน

เพศ อายุ มีอิทธิพลกับเพศชายและอายุนอย


ความคาดหวังเรื่องความพยายามของผูใชงานระบบ

เพศ อายุ ประสบการณในระบบ

มีอิทธิพลกับเพศหญิง อายุมาก และมีประสบการณในระบบนอย


อิทธิพลจากสังคม เพศ อายุ การสมัครใจ ประสบการณในระบบ

มีอิทธิพลกับเพศหญิง อายุมาก ซ่ึงการใชระบบอยูภายใตคําส่ัง และมีประสบการณในระบบนอย


สภาพของสิ่งอํานวยความสะดวกในระบบ

- ไมมีนัยสําคัญ

การใชงานระบบ สภาพของสิ่งอํานวยความสะดวกในระบบ

อายุ ประสบการณในระบบ

มีอิทธิพลกับผูมีอายุมากและเพิ่มขึ้นตามประสบการณ


ความเชื่อมั่นของผูใชงานระบบ



ความกังวลใจของผูใชงานระบบ



ทัศนคติตอการใชงานระบบ


การใชงานระบบ พฤติกรรมความตั้งใจในระบบ

- มีนัยสําคัญ

ที่มา: Venkatesh et al. (2003)

18

ความสําคัญของการประเมินความสามารถในการใชงานของระบบ

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

ภาพที่ 2.2 ความสามารถในการใชงานตามหลักการออกแบบทางวิศวกร ที่มา www.intelliware.ca/services/usability.jsp

จากภาพที่ 2.2 จะเห็นไดวาความสามารถในการใชงานเปนปจจัยหน่ึงที่มีสําคัญมาก ที่จะชวยใหผูใช ยอมนาํเอาโปรแกรมซอฟตแวรหรือระบบตางๆ ไปใชงานอยางเต็มใจ เชน ถาขอความ เมนูหรือส่ิงตางๆทีป่รากฏอยูบนหนาจอ (Screen) หรือที่เรียกวา สวนตอประสานกับผูใช (User Interface) ชัดเจน สามารถสื่อสารกับผูใชไดอยางดี มคีวามเสมอตนเสมอปลาย (Consistent) และเช่ือมโยงติดเปนเรื่องเดียวกัน (Coherent) จะทาํใหผูใช สามารถรวมความตัง้ใจมุงไปที่งานที่จะตองทาํใหลุลวงตามกาํหนด (Task) โดยที่จะไมตองมาเสียเวลาและเสียพลังงานไปกับการพยายามใชระบบ (Trying to Make the Application Work) เชน หาเมนู หรือปุม ที่ตองการ

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

19

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

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

การทดสอบความสามารถการใชงาน (Usability Testing) เปนเทคนิคทีใ่ชในการประเมนิผลิตภัณฑตางๆที่มนุษยสรางขึ้น เชน รีโมทคอนโทรล รถยนต โปรแกรมระบบงาน หนาจอโปรแกรมคอมพิวเตอร หนาจอเวปไซต เปนตน (Nielsen, 2000a ; Norden, et al. 2006; Redish, 2007) โดยทดสอบกับผูใช หรือ เก็บขอมลูใหไดวาคนเราใชเทคโนโลยน้ัีนๆอยางไร (Nielsen,

1993; Nielsen, 1994) งานวิจัยที่เกี่ยวของกับการทดสอบนี้ มีจุดเร่ิมตนมาจากงานวจิัยเกี่ยวกับการออกแบบเว็บไซต ผลงานวจิัยเหลาน้ันไดกลาวถึงคุณลักษณะที่ดีของเวปไซตที่ควรจะเปน กลาวถึงวิธีการสรางเวปไซตใหงายตอการใชงานมากขึ้นสําหรับผูใชงาน และวธีิการลดขอผิดพลาด ที่เกิดจากผูใชใหเหลือนอยที่สุด งานวิจัยตางๆใชทฤษฏทีางดาน Human-Computer Interaction รวมถึงทฤษฏีทางดาน Cognitive และ Minimal Cognitive Processing ดวย (Manomuth, 2006) การทดสอบความสามารถการใชงาน จะเนนไปที่การวัดความสามารถของผลิตภัณฑที่ถูกสรางขึ้นวาผลิตภัณฑน้ันไดถูกสรางมาไดตรงกับวัตถุประสงคที่ต้ังใจไวหรือไม นอกจากนั้นยังเนนไปท่ีการวดัที่ความงายตอการใชงาน

20

วัตถุประสงคของการทดสอบความสามารถการใชงาน คือ การสังเกตพฤติกรรมของผูใชวาใชผลิตภัณฑหรือระบบนั้นอยางไร เพ่ือทีจ่ะคนหาวาขอผิดพลาดอะไรทีค่วรไดรับการแกไขหรือปรับปรุง โดยการเฝาสังเกตดู (Watch) ขณะที่ผูใชกําลังพยายามทีจ่ะใชระบบเพื่อทาํตามวัตถุประสงคทีไ่ดต้ังใจไววาจะทาํ (Nielsen, 2000a) เชน การเฝาสังเกตดูขณะที่ผูใชพยายามที่จะใช เวปไซตในระบบอีคอมเมิซเพ่ือหาขอมูลสินคาที่ตองการ หรือในขณะที่ผูใชพยายามที่จะใช MSN เพ่ือสงรูปภาพใหเพ่ือน ส่ิงที่ไดรับจากการเฝาดูพฤติกรรมของผูใชงานจริง ทาํใหไดรับขอมูลทางตรงวา ผูใชงานระบบหรอืผลิตภัณฑน้ันกันอยางไร และคนพบวาไดเกิดขอผิดพลาดอะไรบางระหวางที่ผูใชงานบนหนาจอของระบบ (Nielsen, 1994)

โดยปกติแลวในการทดสอบความสามารถการใชงานจะเก็บขอมูล 3 สวน สวนแรกจะเก็บ

ขอมูลเชิงปริมาณดานผลงาน (Performance) ของผูเขารวมทดสอบระบบ (Participants) สวนที่สองจะเก็บขอมูลเกี่ยวกับความพึงพอใจของผูใช (Participants’ Satisfaction with the Product) และสวนที่สามจะเก็บขอมูลเกี่ยวกับปญหาเรื่องความสามารถในการใชงานของระบบ (Usability Problems) ที่เกิดขึ้นระหวางท่ีทดลองใชงานระบบ (Nielsen, 2000a ) ปญหาดังกลาวมักจะเกิดขึ้น เม่ือ ผูใชคิดวาระบบนาจะทํางานอยางนี้ แตระบบทาํงานอีกอยางหน่ึง (Van Dune et al. ,2003) เชน ผูใชคิดวาในการจายเงิน เพ่ือจะซ้ือสินคาบนระบบอคีอมเมิซ ผูใชก็แคกดปุม Add to Shopping Card อยางเดียว แตจริงๆแลว ระบบตองการใหลูกคาทาํหลายข้ันตอนมากกวาน้ัน เชน ระบบตองการใหลูกคา กดปุม Add to Shopping Card ตองการใหลูกคากดปุม Next ไปเรื่อยๆ จนกระทั่ง กดปุม Submit Order เพ่ือยืนยันการจายเงินเพ่ือซ้ือของบนระบบอีคอมเมซิ เปนตน

Jakob Nielsen (2003) ผูซ่ึงไดรับการยอมรับวาเปนกูรูทางดานความสามารถในการใช

งานระบบ (King of Usability) ไดกลาวไววา ความสามารถในการใชงานของระบบ (Usability) ประกอบดวย การออกแบบสวนตอประสานของระบบตางๆกับผูใช (User Interface Design) จะตองประกอบไปดวยปจจัยเชิงคุณภาพดังน้ี

1. ความงายตอการเรียนรูการใชระบบ (Learnability) ถาเปนในกรณีที่ผูใชงานระบบ เพ่ิงเคยลองใชระบบเปนคร้ังแรก(Novice User) ผูใชรูสึกวางายหรือยากอยางไรที่จะสามารถทํางานตางๆ ซ่ึงเปนฟงคชันพ้ืนฐานของระบบนั้น ไดประสพผลสําเร็จ

21

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

3. ความสามารถในการจดจําการใชระบบ (Memorability) ถาเปนในกรณีที่ผูใชงานไดเคยใชระบบ เมื่อผูใชกลับมาใชงานระบบฯหลังจากที่ไมไดใชระบบไปในชวงเวลาหนึ่ง ยังสามารถใชงานระบบไดคลองแคลวเพียงใด

4. ความสามารถในการจัดการขอผิดพลาดดวยตัวเอง (Errors Handling) ผูใชงานระบบ ไดทําขอผิดพลาดในขณะการใชระบบทั้งส้ินก่ีครั้ง ขอผิดพลาดในแตละครั้งมีความรนุแรงมากนอยเทาใด และผูใชสามารถแกใขขอผิดพลาดดวยตนเองไดอยางงายดายหรือยากเพียงใด

5. ความพึงพอใจของผูใชระบบ (Satisfaction) ผูใชงานระบบมีความพึงพอใจในการใชระบบในระดับใด

กลาวโดยสรุปจากการศึกษาปจจัยเชิงคุณภาพของระบบ จะทาํใหสามารถประเมินไดวา ระบบฯมีประสิทธิภาพในการใชงานมากนอยเพียงใด (Efficiency) ระบบฯนั้นใชงานไดยากหรืองายเพียงใด (Ease of Use) ระบบฯไดถูกออกแบบมาใหสวนตอประสานของผูใช (User Interface Design) สามารถสื่อใหผูใชระบบไดเขาใจวาระบบนั้นตองใชงานอยางไร (Memorability) ระบบฯสามารถอํานวยใหผูใชสามารถแกไขขอผิดพลาดขณะใชระบบไดดีเพียงใด (Error Handling) และผูใชงานมีความพึงพอใจตอการใชระบบฯมากนอยเพียงใด (Satisfaction) การตรวจสอบการควบคุมระบบสารสนเทศ

การตรวจสอบการตรวจสอบระบบสารสนเทศ หมายถึง กระบวนการการรวบรวมหลักฐานและประเมินหลักฐาน โดยผูตรวจสอบอิสระและปฏิบัติตามมาตรฐานการตรวจสอบที่เกี่ยวของ เพ่ือแสดงความเห็นเกี่ยวกับ ความถูกตองเช่ือถือได การรักษาความปลอดภยั การปฏิบัติงานไดอยางมีประสิทธิภาพและมีประสิทธิผลตามวัตถุประสงคที่กําหนด เพ่ือสรางความเช่ือมั่นอยางมีเหตุผลตอฝายบริหารในการจัดการและการรักษาประสทิธิภาพประสิทธิผลของระบบการควบคุมที่ใช ซ่ึงผูตรวจสอบจะแสดงความเห็นและรายงานจุดออนของการควบคุมที่มีสาระสาํคัญ รวมท้ังการใหขอเสนอแนะในการปรับปรุงแกไข (อุษณา, 2551)

22

ความกาวหนาของเทคโนโลยี ทาํใหกระบวนการตรวจสอบและรวบรวมหลักฐานของกิจการที่ประมวลผลดวยคอมพิวเตอร ตองเปล่ียนแปลงไปจากการตรวจสอบในระบบการประมวลผลดวยมือ เพราะหลักฐานในระบบสารสนเทศมักจะเก็บในรูปส่ือคอมพิวเตอร ไมมีหลักฐานและรองรอยการตรวจสอบที่จัดทําดวยกระดาษและสมุดบัญชีอีกตอไป และมีผลกระทบใหมาตรฐานการตรวจสอบที่เกี่ยวของกับสารสนเทศทั้งวิชาชีพบัญชีและการตรวจสอบภายในที่ปรับปรุงใหม ตัวอยาง เชน มาตรฐานการตรวจสอบภายใน ขอ1220.A2 และ SAS No.94 กําหนดให ผูตรวจสอบตองมีความรูดานความเสี่ยงและการควบคุมในระบบสารสนเทศ รวมทั้งตองใชเทคนิคการตรวจสอบที่ใชคอมพิวเตอรชวยในการปฏิบัติงานตรวจสอบ

เทคนิคการตรวจสอบโดยใชคอมพิวเตอรชวย (Computer Assisted Audit Techniques:

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

การใชเทคนิคการตรวจสอบโดยใชคอมพิวเตอรชวย มีปจจัยและความซับซอนที่ผู

ตรวจสอบตองพิจารณากอนการนํามาใช และสมาคมผูตรวจสอบระบบสารสนเทศ (ISACA) ไดกําหนดแนวทางการปฏิบัติงาน (ISACA Guideline 3, 2008) โดยระบุปจจัยพิจารณาการใชเทคนิคการตรวจสอบที่ใชคอมพิวเตอรชวยไว 6 ประการ คือ

1) ความรู ความเชี่ยวชาญ และประสบการณของผูตรวจสอบ 2) ความเปนไปไดของเทคนิคที่จะใชกับอุปกรณคอมพิวเตอร 3) ประสิทธิภาพและประสิทธิผลของเทคนิคที่ใช 4) ขอจาํกัดดานเวลาและการประสานงานกับหนวยงานที่จะตรวจ 5) ความเช่ือถือไดของระบบและสภาพแวดลอมของระบบสารสนเทศทีจ่ะตรวจ 6) ระดับของความเสี่ยงในการตรวจสอบ

23

อุษณา(2551) กลาววาในปจจุบันเทคนิคการตรวจสอบโดยใชคอมพิวเตอรชวย (CAATs) มีหลายประเภท ที่สําคัญและเปนที่นิยมใช ไดแก การทําขอมูลทดสอบ (Test Data) และการใช โปรแกรมตรวจสอบสําเร็จรูป (Generalized Audit Software: GAS) เน่ืองจากเปนเทคนิคที่ใชความรู ความเชี่ยวชาญ มีขอจาํกัดในการใชนอยกวา และไมจําเปนตองไดรับอนุญาตจากผูบริหารหนวยงานรับตรวจกอนการใช เทคนิคอื่นๆที่จะใชคอมพิวเตอรชวย เชน เทคนิคการทําขอมูลทดสอบแบบบูรณาการ เทคนิคการทาํขอมูลทดสอบแบบประเมินระบบพ้ืนฐาน หรือ เทคนิคการฝงคําส่ังตรวจสอบลงในระบบงาน การทาํขอมูลทดสอบ นิยมใชในการทดสอบการควบคุมโปรแกรมระบบงานโดยเฉพาะในระหวางการพัฒนาโปรแกรมระบบงานนั้น สวนการใช โปรแกรมตรวจสอบสําเร็จรปู นิยมใชในการตรวจสอบความถูกตองครบถวนของเน้ือหาสาระสาํคัญของแฟมและฐานขอมูล และการใช โปรแกรมตรวจสอบสําเร็จรูปผูตรวจสอบจําเปนตองมีความรูดานเทคโนโลยีมากกวาการทาํขอมูลทดสอบ

ถึงแมวาสถาบนัวิชาชีพ เชน AICPA (2001) กลาววา เทคนิคการตรวจสอบโดยใช

คอมพิวเตอรชวย สามารถชวยในการปฏิบตัิงานตรวจสอบหลายดานที่เดิมตองจัดทําดวยมือ ซ่ึงสามารถลดเวลาในการตรวจสอบ และสามารถตรวจสอบประชากรไดทั้งหมดแทนการตรวจสอบแบบสุมตัวอยาง อยางไรก็ตามผลงานวิจัยดานการตรวจสอบระบบสารสนเทศหลายผลงาน พบวา จากความยุงยากและความจาํเปนตองมีความรูดานเทคโนโลยีสารสนเทศ ทําใหทั้งผูสอบบัญชีและผูตรวจสอบภายในใชเทคนิคการตรวจสอบโดยใชคอมพิวเตอรชวยต่ํากวาที่ควรจะเปน (Curtis and Payne, 2008; Celluro, 2003; IIA, 2002; AICPA, 1998)

จากการทบทวนผลงานวิจัยทีเ่กี่ยวกับการตรวจสอบดานผูใชและความสัมพันธระหวางผูใช

กับเทคโนโลยีพบวามีนอยมาก อยางไรก็ตามเริ่มมีแนวโนมที่จะนาํการทดสอบความสามารถการใชงาน (Usability Testing) มาใชในดานการควบคุมและวเิคราะหขอมูล (Genov, 2005; Nielsen, 2000a) และทฤษฎีเกี่ยวกับการยอมรับของผูใชดานเทคโนโลยี (Technology Acceptance) และโมเดลที่เกี่ยวของนิยมนํามาใชอางอิงในการศึกษามากขึ้น (Curtis and Payne, 2008).

ผูศึกษาจึงคาดหวังวาผลงานวจิัยน้ี จะมีประโยชนในการตรวจสอบระบบสารสนเทศทั้งดาน

วิชาการและวิชาชีพทั้งในและตางประเทศ

24

บทที่ 3

วิธีการวิจัย

บทที่ 3 จะกลาวถึงวิธีการศึกษา รายละเอียดวิธีการตรวจสอบ ข้ันตอนในการตรวจสอบ

ระดับของผลการตรวจสอบซึ่งใชในการศึกษาวจิัยคร้ังน้ี

วิธีการศึกษา ใชวิธีการศึกษาวิจัยแบบผสม (Combined Approach) โดยนําวิธีการศึกษาเชิงคุณภาพและเชิงปริมาณ

1. การศึกษาเชิงคณุภาพ โดยการทดสอบการปฏิบัติงานของผูใช (User Testing) ในหองปฏิบัติการทางคอมพิวเตอร การสังเกตการณแบบปด (Closed Observation) การจดบันทึกพฤติกรรมและการแสดงความคิดเห็นของผูทดสอบแบบคิดและพูดดังออกมา (Think Aloud) รวมทั้งการบันทึกภาพถายดวยกลองวีดิโอเทปในการทดสอบ การทดสอบแบบรายบุคคลโดยใชผูทดลอง (Experimenter) ผูสังเกตการณ (Observer) และผูชวย (Assistant) ในการทดสอบ

2. การศึกษาเชิงปริมาณ โดยการทําแบบสอบถามหลังการทดสอบ (Post-test Questionnaire)

รายละเอียดวิธีการตรวจสอบ

การทดสอบกับผูใช (User Test) ในการวิจัยคร้ังน้ี เพ่ือประเมินความสามารถของตัวโปรแกรมระบบบริหารโครงการ ซ่ึงตามหลักมาตรฐานสากลเรื่องการทดสอบกับผูใช การเลือกผูที่จะเขามาทาํการทดสอบระบบนั้น จะตองเลือกผูที่มีความรูพ้ืนฐานเกี่ยวกับระบบ (Knowledge Domain) แตตองเปนผูที่ไมมีความคุนเคยกับระบบที่อยูบนคอมพิวเตอรที่ตองการจะประเมินผลเลย ซ่ึงหมายความวาผูที่รวมทดสอบระบบ จะตองมีพ้ืนความรูที่เก่ียวของกับการบริหารโครงการ แตตองไมเคยใชระบบบริหารโครงการที่อยูบนคอมพิวเตอร (FMS) เลย และตองไมเคยไดรับการฝกอบรมเรื่องการใชระบบบริหารโครงการที่อยูบนคอมพิวเตอรดวย

25

ภาพที่ 3.1 จํานวนผูรวมทดสอบกับอัตราการพบปญหา ที่มา http://www.useit.com/alertbox/20000319.html

ดังน้ันผูประเมินไดตั้งเกณฑสําหรับผูที่จะมารวมทดสอบระบบ (Participant) ตามหลักมาตรฐานสากลดังน้ี

• เปนพนักงานขององคกรที่มีความเขาใจเกี่ยวกับเร่ืองบริหารโครงการพอสมควร • เปนผูที่ไมเคยไดรับการอบรมเรื่องการใชระบบบริหารโครงการ • เปนผูที่ไมเคยใชระบบบริหารโครงการ สําหรับการทดสอบในครั้งน้ี มีขอจํากัดเก่ียวกับผูที่จะทดสอบระบบ เน่ืองจากพนักงาน

ขององคกรสวนใหญมีความเขาใจเกี่ยวกับเรื่องบริหารโครงการและเคยมีประสบการณเร่ืองการใชระบบบริหารโครงการมาแลว และเนื่องดวยขอจํากัดทางดานเวลา จึงใชการทดสอบผูใชจํานวน 5 คน โดยอางอิงจาก Nielsen (2000b) ที่กลาวไวในงานวิจัยวา การทดสอบผูใชระบบเพียง 5 คน ก็เพียงพอที่จะทําใหสามารถพบปญหาเร่ืองความสามารถในการใชงานระบบไดถึง 85 % (ภาพที่ 3.1) ซ่ึงเปนระดับที่ยอมรับได

กอนที่จะดําเนินการทดสอบ ผูศึกษาไดออกแบบแบบฟอรมที่จะใชในการเก็บขอมูล

(Protocol) รายละเอียดดูในภาคผนวก ซ่ึงในแบบทดสอบจะประกอบดวย 1. บทนํา เปนขอความสื่อใหผูรวมทดสอบเขาใจถึงที่มาของการทดสอบในครั้งน้ี และใหเขาใจ

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

2. วิธีการดําเนินการในการทดสอบ (Instruction for evaluating the FMS)

26

3. แบบสอบถามขอมูลท่ัวไป เพ่ือใหทราบวา ผูรวมทดสอบเคยมีประสบการณเกี่ยวกับการใชหรืออบรม FMS มากนอยเพียงใด

4. แบบเก็บขอมูลเพื่อประเมินโปรแกรม “ระบบบริหารโครงการ” ประกอบไปดวยกิจกรรมทั้งส้ิน 10 กิจกรรม ท่ีผูวิจัยกําหนดใหผูรวมทดสอบจะตองทําใหลุลวงตามเวลาที่กําหนด ซ่ึงในแบบเก็บขอมูลน้ีไดเก็บรวบรวมขอมูลเก่ียวกับ เวลาที่ใชในการทําแตละกิจกรรม และความสําเร็จหรือลมเหลวในการทําแตละกิจกรรม โดยมีรายละเอียดของกิจกรรมดังน้ี • กิจกรรมที่ 1 – บันทึกรายละเอียดโครงการและออกรหัสโครงการ • กิจกรรมที่ 2 – บันทึกเพ่ิมขอมูลองคกร • กิจกรรมที่ 3 – การทําหนังสือสงใหผูทบทวนโครงการ (Reviewer) • กิจกรรมที่ 4 – การเพิ่มเติมขอมูลโครงการ—ขอมูลงบประมาณที่ องคกรอนุมัติ • กิจกรรมที่ 5 – บันทึกขอมูลการแบงงวดงาน หรือ งวดเงิน • กิจกรรมที่ 6 – อนุมัติโครงการ • กิจกรรมที่ 7– บันทึกขอมูลโครงการ—เพ่ือทํารายงานสรุปประกอบการขออนุมัติ

โครงการ • กิจกรรมที่ 8 – บันทึกขอมูลเพ่ือจัดทําสัญญาและออกรหัสสัญญา • กิจกรรมที่ 9 – พิมพสัญญา • กิจกรรมที่ 10 – ปดโครงการ

5. แบบสอบถามความคิดเห็น เพ่ือสอบถามความคิดเห็นของผูรวมทดสอบ 6 ดาน โดยไดนําตัวอยางแบบสอบถามของ Viswanath Venkatesh และคณะ (พ.ศ. 2546) มาปรับใช คอื 1) ความคาดหวังในเรื่องสมรรถนะของโปรแกรมฯ (Performance Expectancy) 2) ความคาดหวังเร่ืองการใชความพยายามของผูใชงาน (Effort Expectancy) 3) ทัศนคติตอการใชงานโปรแกรมฯ (Attitude Toward Using Technology) 4) สภาพของสิ่งที่จะชวยอาํนวยใหเกิดการดําเนินงาน (Facilitating Conditions) 5) ความรูสึกเช่ือมั่นของผูใช (Computer Self-Efficacy) และ6) ความตั้งใจที่จะใชโปรแกรมฯ (Behavioral Intention) และการแบงระดับความคิดเห็นใช Likert Scale แบบ 7 ระดับดงัน้ี (1 -ไมเห็นดวยอยางมาก, 2 –ไมเห็นดวย, 3 – ไมเห็นดวยเพียงเล็กนอย, 4 –ไมแนใจหรือไมใชอันใดอันหน่ึง (อยูระหวางไมเห็นดวยกับเห็นดวย), 5 – เห็นดวยเพียงเล็กนอย, 6 – เห็นดวย, และ 7 – เห็นดวยอยางมาก)

27

ส่ิงที่ผูรวมทดสอบระบบจะตองทําคือ การเขาไปใชโปรแกรม “ระบบบริหารโครงการ” (FMS) เพ่ือบันทึกขอมูลในกิจกรรมตางๆเกี่ยวกับโครงการ ที่ผูวิจัยไดจัดเตรียมขอมูลไวแลว หนาถัดไปของแบบฟอรมที่จะใชในการเก็บขอมูล จะมีคําส่ังตางๆ ใหผูรวมทดสอบระบบทาํตามเพ่ือที่จะไดสามารถเขาระบบเพ่ือทําการกรอกหรือบันทึกขอมูลได [ทั้งน้ีจะใหผูรวมทดสอบระบบ (Participants) คิดอยูในใจวาเวลาของผูรวมทดสอบระบบนั้นมีคามาก]

การเก็บขอมูลเกี่ยวกับปญหาในการใชระบบ จะเก็บจากการทีใ่หผูรวมทดสอบ พูดดังๆ

ตามที่ตวัเองคดิในขณะที่กําลังใชระบบฯ (“Think aloud”) วิธีน้ีเปนเทคนิคที่จะทาํใหไดขอมูลยอนกลับ (Feedback) จากผูรวมทดสอบ นอกจากนั้นผูวิจัยไดเก็บขอมูลที่เกี่ยวกับพฤติกรรมการใชระบบของผูรวมทดสอบ โดยการบันทึกภาพถายวีดีโอเพ่ือจะบันทึกในสิ่งที่ผูรวมทดสอบทาํและพูดในระหวางทดสอบระบบฯ

ภายหลังจากทีท่ดสอบระบบเสร็จส้ิน ผูวิจยัไดถามผูรวมทดสอบ 2 คําถาม ไดแก “อะไรคือ

อุปสรรคที่เกิดขึ้นในระหวางที่คุณกําลังทาํกิจกรรมบาง” และ “คุณคิดวาระบบนาจะปรับปรุงในจุดไหนบางเพื่อจะลดอุปสรรคที่คุณไดเผชิญในการใชระบบฯ”

ขั้นตอนในการตรวจสอบ

ขั้นตอนทั้งหมดใชเวลาทั้งส้ินประมาณ 1 ชั่วโมง 30 นาที ส่ิงที่ผูรวมทดสอบระบบทํามี 6 ขั้นตอน คือ

1. กรอกแบบสอบถามขอมูลทั่วไป 2. คลิกเปดโปรแกรม“ระบบบริหารโครงการ” (FMS) กรอกชื่อผูใช และรหัสผาน

ที่กําหนดให 3. ใหผูรวมทดสอบระบบหาทางทาํงานดวยตนเองในการทํากิจกรรมที่ไดถูกกําหนด

ไวใหเปนขอๆ (Specified Tasks)ใหไดผลสําเร็จ (เชน เลือกวาจะคลิกปุมไหน คลิกหนาจอไหน) และ ใหผูรวมทดสอบระบบพูดและวิจารณ (Think aloud) เพ่ือแสดงความคิดเห็น ในระหวางการทาํกิจกรรมที่ไดถูกกําหนดไวให

4. สําหรับการบันทึกขอมูลลงในระบบฯ ใหผูรวมทดสอบระบบใชขอมูลที่ไดถูกจัดเตรียมไวให

28

5. กอนที่จะเริ่มทํากิจกรรมแตละขอใหแจงตอผูวิจัย เพ่ือที่ผูวิจัยจะลงบันทึกเวลาเริ่มตน 6. ถาผูรวมทดสอบระบบคิดวาไดทํากิจกรรมที่ไดถูกกําหนดไว ใหเปนขอๆ สําเร็จ

แลว ใหผูรวมทดสอบระบบแจงตอผูควบคมุการทดสอบระบบฯ • ถาผูรวมทดสอบระบบทําถกูตอง ผูวิจัยจะลงบันทึกวา “สําเร็จ” และลงบันทึกเวลา

ส้ินสุด • ถาผูรวมทดสอบระบบทําไมถูกตอง ผูวิจัยจะแจงวา “ทําไมถูกตอง” และลง

บันทึกเวลาสิ้นสุด • ถาผูรวมทดสอบระบบจะหยุดทํากิจกรรมขอน้ัน ใหแจงกับผูวิจัยดวย เพ่ือจะได

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

วิธีการเก็บขอมูล

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

• ถาผูรวมทดสอบระบบทําถกูตองจริง ผูวิจัยจะลงบันทึกวา “สําเร็จ” (Successful: S) • ถาผูรวมทดสอบระบบทําไมถูกตอง ผูวิจัยจะลงบันทึกวา “ไมสําเร็จหรือลมเหลว” หรือ “คําตอบผิด” (Wrong Answer: W) • ถาผูรวมทดสอบระบบขอหยุดทํากิจกรรมขอน้ัน ผูวิจัยจะลงบันทึกวา “ยอมแพ” (Give Up: G)

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

เวลาตอกิจกรรม = เวลาการเริ่มตนของแตละกิจกรรม - เวลาการสิ้นสุดของแตละกิจกรรม

29

วิธีการวิเคราะหขอมูล การวิเคราะหเชิงพรรณนา สถิติพ้ืนฐานที่ใชไดแก คาความถี่ และคารอยละ ประกอบกับการวิเคราะหขอมูลจากผลการทดสอบที่ไดเปรียบเทียบกับทฤษฏ ี การประเมินประสิทธิภาพของโปรแกรมระบบงานเชิงปริมาณ จะวิเคราะหจาก เวลาเฉล่ียที่ผูรวมทดสอบใชในการทํากิจกรรมทั้ง 10 เทียบกับเวลาเฉลี่ยที่ควรใชซ่ึงกําหนดไว 40 นาท ี การประเมินประสิทธิผลของโปรแกรมระบบงาน จะวิเคราะหจากจาํนวนกิจกรรมที่ผูรวมทดสอบทําสําเร็จ (Success: S) ในแบบสอบถามความคิดเห็นไดใชระดับเสกล 7 ระดับ แตในการวิเคราะหระดับความเส่ียงจะปรับเปน 5 ระดับ เพ่ือใหตรงกับระดับความเสีย่งที่นิยมใชในการตรวจสอบภายใน (อุษณา , 2550) โดย

• ระดับ 5 หมายถึงความเสี่ยงสูงมาก มีผลกระทบตอความอยูรอดขององคกร นิยมใชสีแดง แสดงถึงความเรงดวนในการบริหารจัดการความเสี่ยงสูงสุด เปนความเส่ียงที่ควรอยูในความรับผิดชอบของฝายบริหารและคณะกรรมการองคกร

• ระดับ 4 หมายถึงความเสี่ยงสูง มีผลกระทบตอความอยูรอดของแผนงานหรือโครงการสําคัญขององคกร นิยมใชสีสม แสดงถึงความเรงดวนในการบริหารจัดการความเสี่ยงสูง เปนความเสี่ยงที่ควรอยูในความรับผิดชอบของฝายบริหาร

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

• ระดับ 2-1 หมายถึงความเสี่ยงต่ําและคอนขางต่าํ มีผลกระทบตอบางสวนของแผนงานหรือโครงการยอยขององคกร นิยมใชสีเขียว และองคกรไมจําเปนที่ตองหาวิธีจัดการความเสี่ยงใดๆเพ่ิมเติมจากที่มีอยู

30

บทที่ 4 ผลและวิจารณ

ผลการศึกษา

ขอมูลเบื้องตนของผูรวมทดสอบ

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

• ทั้ง 5 คน ประกอบดวยผูที่ทํางานในตําแหนงผูประสานงาน 4 คน (ท้ัง 4 คนมีอายุการทํางานในตําแหนงน้ี นอยกวา 6 เดือน) และในตําแหนง ผูประสานงานศูนยขอมูล 1 คน (ซ่ึงมีประสบการทํางานที่ องคกร ประมาณ 1-2 ป)

• ทั้ง 5 คนไมเคยไดรับการฝกอบรมการใชโปรแกรม “ระบบบริหารโครงการ” —FMS • จาก 5 คน

o 1 คนที่ไมเคยใชโปรแกรม “ระบบบริหารโครงการ” —FMS o 1 คนที่เคยใชโปรแกรม “ระบบบริหารโครงการ” —FMS เพียง 1 ครั้ง o 3 คนที่เคยใชโปรแกรม “ระบบบริหารโครงการ” —FMS มากกวา 1 ครั้ง (หน่ึงใน

สามคนนี้เคยใชFMS มากกวา 40 ครั้งได) • ทั้ง 5 คน มีความเชี่ยวชาญและคุนเคยกับการใชคอมพิวเตอรในการทํางานเปนอยางดี ทุกคน

ไดใชคอมพิวเตอรในการทํางานทุกวัน และใชมาทั้งส้ิน มากกวา 100 ครั้ง • ทั้ง 5 คน มีความเชี่ยวชาญในการใชโปรแกรมสําเร็จรูปโปรแกรมอื่นๆเปนอยางดี ทุกคนได

เคยใชโปรแกรมสําเร็จรูปโปรแกรมอื่นๆ ในการทํางานทุกวัน และใชมาทั้งส้ินมากกวา 100 คร้ัง [หมายเหตุ เชน ไมโครซอทฟออฟฟศ หรือ โปรแกรมใชงานในออฟฟศอื่นๆ]

ผลการทดสอบความสามารถของระบบงานในเชิงปริมาณ

ผลการทดสอบระบบบริหารโครงการในเชิง ตารางที่ 4.1 แสดงผลงานและเวลาที่ใชผูทดสอบระบบฯใชในการทําแตละกิจกรรม (วัดเปนหนวย นาที) และเวลาเฉล่ียที่ผูทดสอบทั้งหมด ใชในการทํากจิกรรมทั้งหมด 10 กิจกรรม

31

ตารางที่ 4. 1 ผลและเวลาทีใ่ช (นาที) ในการทาํกิจกรรม ผูใชที่1 ผูใชที่2 ผูใชที่3 ผูใชที่4 ผูใชที่5 เวลา

เฉลี่ย เวลา เวลา เวลา เวลา เวลา กิจกรรม 1 S 6 S 15 S 9 S 30 S 9 13.80

กิจกรรม 2 G 3 G 9 S 4 G 10 G 5 6.20

กิจกรรม 3 W 22 G 5 G 13 G 7 G 8 11.00

กิจกรรม 4 G 8 G 8 G 8 G 2 G 8 6.80

กิจกรรม 5 S 3 G 9 G 9 G 13 G 8 8.41

กิจกรรม 6 S 1 S 2 S 9 S 8 G 2 4.40

กิจกรรม 7 S 4 G 7 S 10 G 2 G 6 5.80

กิจกรรม 8 S 2 G 3 S 4 G 5 G 5 3.80

กิจกรรม 9 S 2 G 2 S 1 G 9 G 1 3.00

กิจกรรม 10 S 3 S 5 S 5 S 8 S 2 4.60

รวมเวลาที่ใช(นาที) 54 65 72 94 57 67.81

รวมผลงาน (อัตรารอยละ)

S = 22 or 36% ; G = 26 or 54% ; W = 1 or 10 %

หมายเหตุ : S = Success, สําเร็จ G = Give Up, หยุดกลางคัน W = Wrong Answer คําตอบผิด

ผูรวมทดสอบคนที่ 1 ใชเวลาทั้งส้ินประมาณ 54 นาที ทาํงานไดลุลวงตามกาํหนด 6

กิจกรรม ไมลุลวง 4 กิจกรรม (ประสบความสําเร็จ 60 %) ผูรวมทดสอบไดคําตอบผิดสําหรับกิจกรรมที่ 1 สําหรับกิจกรรมที่ 2 และ 4 ผูรวมทดสอบขอหยุดกลางคัน

ผูรวมทดสอบคนที่ 2 ใชเวลาทั้งสิ้นประมาณ 1 ชั่วโมง 5 นาที ทาํงานไดลุลวงตามกําหนด 2 กิจกรรม ไมลุลวง 8 กิจกรรม (ประสบความสําเรจ็ 20 %) ซ่ึงกิจกรรมที่ไมลุลวงทั้งหมดผูรวมทดสอบไดคําตอบผิด 1 กิจกรรม และกิจกรรมที่เหลือ ขอหยุดกลางคันทั้งส้ิน

ผูรวมทดสอบคนที่ 3 ใชเวลาทั้งส้ินประมาณ 1 ชั่วโมง 12 นาที ทํางานไดลุลวงตามกําหนด 7 กิจกรรม ไมลุลวง 3 กิจกรรม (ประสบความสําเรจ็ 70 %) ซ่ึงกิจกรรมที่ไมลุลวงทั้งหมดผูรวมทดสอบขอหยุดกลางคันทั้งส้ิน

32

ผูรวมทดสอบคนที่ 4 ใชเวลาทั้งส้ินประมาณ 54 นาที ทํางานไดลุลวงตามกําหนด 2กิจกรรม ไมลุลวง 8 กิจกรรม (ประสบความสาํเร็จ 20 %) ซ่ึงผูรวมทดสอบไดคําตอบผิด 1 กิจกรรม และกิจกรรมที่เหลือ ขอหยุดกลางคันทั้งส้ิน

ผูรวมทดสอบคนที่ 5 ใชเวลาทั้งส้ินประมาณ 1 ชั่วโมง 34 นาที ทํางานไดลุลวงตามกําหนด 1 กิจกรรม ไมลุลวง 9 กิจกรรม (ประสบความสําเร็จ 10 %) ซ่ึงกิจกรรมท่ีไมลุลวงทั้งหมดผูรวมทดสอบไดคําตอบผิด 1 กิจกรรม และกิจกรรมที่เหลือ ขอหยุดกลางคันทั้งส้ิน

ตารางที่ 4.1 แสดงเวลาที่ผูรวมทดสอบทุกคนใชและคาเฉล่ียเวลาทีใ่ช ซ่ึงเกินกวา 40 นาทีท่ี

กําหนดไว แสดงถึงการขาดประสิทธิภาพของเวลาในการทาํงานในโปรแกรมระบบงานFMS นอกจากนี้จํานวน S ในแตละกิจกรรม ยังสามารถใชแสดงระดับความสําเร็จหรือประสิทธิผลท่ีจะบันทึกขอมูลในกิจกรรมสําเร็จ ในขณะทีจ่ํานวน W แสดงระดับความเสี่ยงของกิจกรรมที่จะบันทกึไมถูกตอง และจาํนวน G แสดงระดับความเสี่ยงของกิจกรรมทีจ่ะบันทึกไมครบถวน ดังน้ันกิจกรรมที่ 2 มีจาํนวน 4G และ 1S แสดงวามีผูรวมทดสอบเพียงคนเดียวที่ทาํกิจกรรมน้ีสําเร็จสวนอีก 4 คนขอยุติกลางคัน กิจกรรมที่ 4 มีคาระดับความเสี่ยงอยูในระดับ 4 สูงกวากิจกรรม 1 ที่มีจาํนวน 5S ซ่ึงแสดงวาผูรวมทดสอบทั้ง 5 คนทาํกิจกรรมนี้สําเร็จ จากขอมูลน้ีผูตรวจสอบสามารถใชในการวางแผนการตรวจ เชน ควรขยายผลการตรวจสอบ กําหนดใชเวลาและใชเทคนิคการตรวจสอบในกิจกรรมที่มีระดับความเสี่ยงสูงกวากิจกรรมทีร่ะดับความเสี่ยงตํ่ากวา เปนตน

Usabilitiy Test of 5 Users

Wrong Answer

10%

Success36%

Give Up54%

Wrong AnswerSuccessGive Up

ภาพที่ 4.1 ผลการทดสอบกิจกรรมจากผูรวมทดสอบทั้ง 5 คน

33

ภาพท่ี 4.1 แสดงผลการทดสอบกิจกรรมจากผูรวมทดสอบทั้ง 5 คน จะเห็นไดวาจากการทํากิจกรรมทั้งส้ิน 10 กิจกรรม มีเพียง 36 เปอรเซ็นต ที่ประสบความสําเร็จในการทํากจิกรรมที่กําหนดให 54 เปอรเซ็นต ที่ขอหยุดกลางคัน และ 10 เปอรเซ็นต ที่ลมเหลวหรือไมประสบความสําเรจ็ในการทํากิจกรรมที่กําหนดให

จากการวิธีการพูดและคิดดังๆ ผูวิจัยพบวาหนาจอระบบบริหารโครงการมีขอบกพรองดังน้ี

1. วิธีท่ีจะทําใหผูใชสามารถคนหาสิ่งท่ีตองการไดพบ (Navigation) เน่ืองจากการออกแบบหรือตั้งชื่อของเมนู Tab หรือลิงคตางๆยังไมสามารถสื่อสารกับผูใชเขาใจได ผูใชจึงไมทราบวาจะตองคลิกที่ปุม Tab หรือล้ิงคใดพ่ือที่จะไปสูหนาจอที่เปนเปาหมายในการทาํกิจกรรมตางๆ (ซ่ึงเปนฟงคชันพ้ืนฐานของระบบ) ไดประสพผลสําเร็จ ได

2. ข้ันตอนการออกแบบและการประเมินระบบ (Design Process and Evaluation) เน่ืองจากผูทดสอบใชเวลาในการเรียนรูโครงสรางของระบบนานกวาที่มาตรฐานกําหนด และเมื่อผูทดสอบกลับมาใชงานระบบฯหลังจากที่เขาไมไดใชระบบไปซักชวงเวลาหนึ่ง สวนใหญพวกเขาจะตองกลับมาเริ่มตนเรียนรูใหมโดยใชเวลาเทาเดิมหรือบางคร้ังนานกวาเดิมเพ่ือทํากิจกรรมที่เคยทําไปแลว

3. การใหประสบการณในการใชระบบอยางดีท่ีสุดแกผูใชระบบ(Optimize the User Experience) เน่ืองจากมีขอผิดพลาดที่เกิดจากการผูทดสอบระบบขึ้นในขณะการทดสอบระบบ ขอผิดพลาดในแตครั้งมีความรุนแรงมากบางนอยบาง แตผูใชสวนใหญไมสามารถแกใขขอผิดพลาดดวยตนเองไดอยางงายดายเลย

4. การควบคุมส่ิงท่ีแสดงบนหนาจอ (Screen-based Control- Widgets) ระบบควรชวยใหผูใชกรอกขอมูลเทาที่จาํเปนเทาน้ันและใหผูใชเสียเวลาในการกรอกนอยที่สุด แตจากการทดสอบผูใชพบวาปญหา เชน ผูใชตองกรอกเองผูใชบางสวนมีปญหาการกรอกวันที่ เพราะในชองการกรอกตัวเลข ไมมีรูปแบบ( format)ระบุไว และ ผูใชบางสวนติดปญหาชองที่ตองกรอกปงบประมาณ ผูทดสอบเขาใจวาตองใสเต็มๆ เชน “2550” แตระบบจะรับแค “50” เปนตน

ผลการทดสอบความคิดเห็นเชิงคุณภาพ

จากการเก็บขอมูลโดยใชแบบสอบถามความคิดเห็นของผูทดสอบ ที่มีตอโปรแกรม “ระบบบริหารโครงการ” 6 ดาน เกี่ยวกับ ความคาดหวังในเรื่องสมรรถนะของโปรแกรมฯ (Performance Expectancy) ความคาดหวังเร่ืองการใชความพยายามของผูใชงาน (Effort

34

Expectancy) ทัศนคติตอการใชงานโปรแกรมฯ (Attitude toward Using Technology) สภาพของสิ่งที่จะชวยอํานวยใหเกิดการดําเนินงาน (Facilitating Conditions) ความรูสึกเช่ือมั่นของผูใช (Computer Self-Efficacy) และความตั้งใจที่จะใชโปรแกรมฯ (Behavioral Intention) ไดผลดังภาพที่ 4.2

ความคาดหวังดานสมรรถนะ

ความคาดหวังดานความพยายาม

ทัศนคติตอการใชงาน

สภาพของ ส่ิงอํานวยความสะดวก

ความเชื่อมั่นของผูใช

ความตั้งใจที่จะใช

คาเฉล่ีย 4.7 3.2 3.25 4.3 4.5 4.75

คาสูงสุด 6 3.6 3.6 5.8 6.2 5.4

คาต่ําสุด 3.8 2.8 2.8 2.8 2.8 4.2

0

1

2

3

4

5

6

7

คาเฉลี่ยคาสูงสุดคาต่ําสุด

ผลการทดสอบตามแบบสอบถาม

ภาพที่ 4.2 ผลการทดสอบความคิดเห็นของผูใชใน 6 ดาน

ภาพท่ี 4.2 แสดงคาคะแนนที่ไดจากแบบสอบถามความคิดเห็นหลังจากผูรวมทดสอบไดทํา

กิจกรรมทั้ง 10 เสร็จ จะเหน็ไดวาจากคะแนนเต็ม 7 คะแนน ดานความตั้งใจทีจ่ะใชและมีความคาดหวังดานสมรรถนะของโปรแกรมระบบงานอยูในระดับ 4.75 และ 4.7 คะแนน แสดงวา ผูรวมทดสอบรูสึกยังไมแนใจหรือยังไมตัดสินใจวาจะใชโปรแกรมหรือไม สวนดานความเชื่อม่ันระบบงานและสภาพของสิ่งอํานวยความสะดวกอยูในระดับ 4.5 และ4.3 คะแนน แสดงถึงความรูสึกคอนขางไมเห็นดวย และมีทศันคติพึงความพอใจที่จะใชงานต่าํ (3.25 และ3.2 คะแนน) แสดงวาความรูสึกวาโปรแกรมใชงานยาก หรือตองใชความพยายามในการทํางานมากกวาคาดหวงั สรุปไดวาผูใชระบบมีความยอมรับระบบ FMS ต่ํากวาที่คาดไว (ดูรายละเอียดในตารางที่ 4.2)

35

ตารางที่ 4.2 ตารางความคิดเห็นของผูทดสอบระบบที่มีตอโปรแกรม FMS ระดับคะแนน

(เต็ม 7) ความคิดเห็นของ ผูรวมทดสอบฯ ประเด็น

ความคาดหวังในเรื่องสมรรถนะของ โปรแกรม FMS ไดคะแนน 4.7 จาก 7 5.2 เห็นดวยเพียง

เล็กนอยวา FMS น้ีมีประโยชนสําหรับการทํางานบริหารโครงการ

3.8 ไมแนใจวา การใชงาน FMS น้ีชวยทําใหผูรวมทดสอบระบบสามารถทํางานดานบริหารโครงการไดรวดเร็วขึ้น

3.8 ไมแนใจวา การใช FMS น้ีชวยใหประสิทธิภาพการทํางานดานบริหารโครงการดีขึ้น (เมื่อเทียบกับการลงบันทึกเกี่ยวกับงานดานบริหารโครงการดวยมือ) โดยสามารถทาํงานไดมากข้ึนในเวลาเทาเดิม

6 เห็นดวยวา ถาผูรวมทดสอบระบบใช FMS เปน จะทําใหผูรวมทดสอบระบบไดรับการยอมรับจากผูรวมงาน และเจานาย มากยิ่งขึ้น

ความคาดหวังเรื่องการใชความพยายามของผูใชงาน FMS ไดคะแนน 3.25 จาก 7

2.8 ไมเห็นดวยเพียงเล็กนอยวา

การใชงาน FMS น้ันเขาใจงายและชัดเจน

3.8 ไมแนใจวา ผูรวมทดสอบระบบจะกลายเปนผูมีทักษะความสามารถในการใชงาน FMS เปนอยางดีไดโดยงาย

3 ไมเห็นดวยเพียงเล็กนอยวา

FMS น้ันงายตอการใชงาน


ผูรวมทดสอบระบบสามารถเรียนรูการใชงาน FMS ไดโดยงาย

ทัศนคติตอการใชงาน FMS ไดคะแนน 3 จาก 7 3 ไมเห็นดวยเพียง

เล็กนอยวา ผูรวมทดสอบระบบเห็นควรที่จะนํา FMS มาใชในการบริหารโครงการ

3.6 ไมแนใจวา งาน (ของผูรวมทดสอบระบบ) มีความนาสนใจมากขึ้นเมื่อนํา FMS มาใช


ผูรวมทดสอบระบบรูสึกสนุกไปกับการใช FMS ได

3.6 ไมแนใจวา ผูรวมทดสอบระบบชอบ/ที่จะใช FMS

36

ระดับคะแนน (เต็ม 7)

ความคิดเห็นของ ผูรวมทดสอบฯ ประเด็น

สภาพของสิ่งท่ีจะชวยอํานวยใหเกิดการดําเนินงาน ไดคะแนน 3.55 จาก 7 5.8 เห็นดวยวา ผูรวมทดสอบระบบมีความรูพ้ืนฐานที่จําเปน (โดยเฉพาะดาน

การใชคอมพิวเตอรขั้นพ้ืนฐาน) เพียงพอที่จะใช FMS ได 3.4 ไมเห็นดวยเพียง

เล็กนอยวา ผูรวมทดสอบระบบมีความรูพ้ืนฐานที่จําเปน (โดยเฉพาะงานที่เก่ียวกับการบริหารโครงการ) เพียงพอที่จะใช FMS ได

2.4 ไมเห็นดวยวา ผูรวมทดสอบระบบมีความรูพ้ืนฐานที่จําเปน (ที่ไดรับจากการฝกอบรมการใชโปรแกรม“ระบบบริหารโครงการ”—FMS ) เพียงพอท่ีจะใช FMS ได


ผูรวมทดสอบระบบมีความรูพ้ืนฐานที่จําเปน (ที่ไดรับจากการอานคูมือการใชงาน FMS) เพียงพอที่จะใช FMS ได

ความรูสึกเช่ือม่ันของผูใช FMS ไดคะแนน 4.8 จาก 7 2.8 ไมเห็นดวยเพียง

เล็กนอยวา ผูรวมทดสอบระบบนาจะสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ดวยตัวของผูรวมทดสอบระบบเอง

6.2 เห็นดวยวา “ผูรวมทดสอบระบบสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถามีคนคอยชวยเหลือเมื่อเกิดปญหา

4.8 เห็นดวยเพียงเล็กนอยวา

ผูรวมทดสอบระบบสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถาผูรวมทดสอบระบบมีเวลามากพอ

5.4 เห็นดวยเพียงเล็กนอยวา

ผูรวมทดสอบระบบสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถามีเมนูชวยเหลือ เชน Help หรือ Troubleshooting

ความตั้งใจท่ีจะใช FMS ไดคะแนน 4.4 จาก 7 4.6 เห็นดวยเพียง

เล็กนอยวา ผูรวมทดสอบระบบมีความตั้งใจที่จะใช FMS ในอนาคต

4.2 ไมแนใจวา ผูรวมทดสอบระบบคาดวาจะใช FMS ในอนาคต” หมายเหตุ ในแบบสอบถามไดใช Likert Scale ซ่ึงแบงเปน 7 ระดับดังนี้ (1 -ไมเห็นดวยอยางมาก, 2 –ไมเห็นดวย,

3 – ไมเห็นดวยเพียงเล็กนอย, 4 –ไมแนใจหรือไมใชอันใดอันหนึ่ง (อยูระหวางไมเห็นดวยกับเห็นดวย), 5 – เห็นดวยเพียงเล็กนอย, 6 – เห็นดวย, และ 7 – เห็นดวยอยางมาก)

37

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

ความเสี่ยงดานความพึงพอใจในการใชระบบ FMS เฉล่ียระดับความเสี่ยงอยูในระดับ 2.8

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

ของผูทดสอบโปรแกรม ระดับ

ความเสี่ยง (5) ระดับคะแนนจากแบบสอบถาม (7)

ความคิดเห็นของผูรวมทดสอบ

ความเสี่ยงดานความพึงพอใจในการใชระบบ FMS เฉล่ียระดับความเสี่ยงอยูในระดับ 2.8 (ความเส่ียงระดับปานกลาง) ความคาดหวังในเรื่องสมรรถนะของโปรแกรม

2.65 4.7 เห็นดวยเล็กนอยเบนไปทางไมแนใจ

ความคาดหวังเรื่องการใชความพยายามของผูใชงาน

3.68 3.25 ไมเห็นดวยเล็กนอย

ทัศนคติตอการใชงาน 4 3 ไมเห็นดวยเล็กนอย สภาพของสิ่งที่จะชวยอํานวยใหเกิดการดําเนินงาน

2.86 3.55 ไมแนใจ

ความรูสึกเชื่อม่ันของผูใช 1.58 4.8 เห็นดวยเล็กนอย ความตั้งใจทีจ่ะใช 1.86 4.4 เห็นดวยเล็กนอย

38

ผลการตรวจในรายละเอียดของปจจัยเชิงคุณภาพของระบบบริหารโครงการทั้ง 5 ดานมีดังน้ี (ดูรายละเอียดเพ่ิมเติมจากตารางที่ 4.4) 1. ความงายตอการเรียนรูการใชระบบ (Learnability) จากผลการตรวจ ระดับความเสีย่งดาน

Learnability เฉลี่ยได 4 ซึ่งเปนความเสี่ยงระดับสูง 2. ประสิทธิภาพของระบบ (Efficiency) จากผลการตรวจ ระดับความเสี่ยงเฉลี่ยดาน Efficiency

ได 5 ซ่ึงเปนความเสี่ยงระดับสูงที่สุด 3. ความสามารถในการจดจําการใชระบบ (Memorability) จากผลการตรวจระดับความเสี่ยง

เฉลี่ยดานMemorabilityได 4 ซึ่งเปนความเสี่ยงระดับสูง 4. ระบบฯสามารถอํานวยใหผูใชสามารถแกไขขอผิดพลาดขณะใชระบบไดดีเพียงใด (Error

Handling) จากผลการตรวจ ระดับความเสี่ยงเฉลี่ยดาน Errors ได 5 ซ่ึงเปนความเสี่ยงระดับสูงที่สุด

5. ความพึงพอใจของผูใชระบบ (Satisfaction) จากผลการตรวจ ระดับความเสี่ยงเฉลี่ยดาน Satisfaction ได 2.8 ซ่ึงเปนความเสี่ยงระดับปานกลาง

39

ตารางที่ 4.4 ผลการตรวจในรายละเอียดของปจจัยเชิงคุณภาพ เรื่องที่ตรวจ ระดับความเสี่ยง

(1-5) คําอธิบาย ขอเสนอแนะ

1 ระดับความเสี่ยงดานความยากหรืองายตอการใชงานของระบบ เฉลี่ยได 4 (เปนความเสี่ยงระดับสูง) ประกอบดวย 1.1 ความงายตอการเรียนรูการใชระบบ

(Learnability) ถาเปนในกรณีที่ผูใชงานระบบ (Novice User) เพิ่งเคยลองใชระบบเปนครั้งแรก มันงายหรือยากอยางไรที่ผูใชจะสามารถทํางานตางๆ (ซึ่งเปนฟงคชันพื้นฐานของระบบ) ไดประสพผลสําเร็จ

ระดับ 4 สีสม สําหรับผูใชงานระบบFMS ที่เพิ่งใชงานครั้งแรกหรือเคยใชงานมาแลวบางนั้น จากตารางที่ 6.1 นํามาแสดงเปน Pie Chart (ภาพที่ 6.3) จะเห็นไดวา จากกิจกรรมทั้งสิ้น 10 กิจกรรม ผูทดสอบระบบทั้ง 5 คนทํากิจกรรมที่ถูกกําหนดไดสําเร็จหรือลุลวงตามกําหนด 36% ขอหยุดกลางคัน 54 % และผูรวมทดสอบคิดวาตนเองทํากิจกรรมที่ถูกกําหนดไดสําเร็จแตไดคําตอบที่ผิด 10 % เปอรเซนตความผิดพลาด 64%

• ควรใชวงจรการพัฒนาระบบ (System Development Life Cycle) เขามาประยุกตใชรวมกับการออกแบบซอฟทแวร โดยในขั้นการออกแบบควรจะใชวิธีการเก็บความตองการของผูใช รวมกับการวิเคราะหงานที่ตองทํา (Task Analysis) การออกแบบแบบวนซ้ํา (Iterative Design) การพัฒนาตนแบบ (Paper and Software Prototype) และการทดสอบตนแบบโดยใชวิธีการทดสอบตนแบบกับผูใช (Target User)ดวย

• เมื่อใชโปรแกรมไปแลวซักระยะหนึ่งควรจะทาํการประเมินโปรแกรมและนําfeedback ที่ไดมาปรับแกโปรแกรมดวย

40

เรื่องที่ตรวจ ระดับความเสี่ยง (1-5)

คําอธิบาย ขอเสนอแนะ

• ควรกําหนดหรือตั้งชื่อ Tab ชื่อปุมและชื่อใน list ใหสื่อความหมายกับผูใช เครื่องมือที่สามารถนํามาใชเพื่อสรางชื่อเมนู คือ Card Sorting โดยจะใหผูใชมีสวนรวมในการตั้งชื่อเมนู และควรใชคาํตางๆ (Terminology)ที่ผูใชคุนเคยในการตั้งชื่อเมนูตางๆ

• ควรกําหนดหรือตั้งชื่อ Tab ชื่อปุมและชื่อใน list ใหมีวามแตกตางกันอยางชัดเจนและสื่อความหมายไดเขาใจ

• สําหรับชื่อเมนู ชื่อ Tab ชื่อปุมและชื่อใน list ควรจะใช Glosses ซึ่งเปน pop-up window ที่แสดงคําอธิบายเพิ่มเติมวา เมนู Tab ปุม หรอื list คืออะไร ผูใชจะไดสามารถอานทาํความเขาใจ กอนที่จะคลิกเลือก

• ควรออกแบบ TabใหดูเหมือนTab โดยอาจใชเงา หรือสามมิติ เขามาชวยทําใหดูเหมือน

41



Tabมากยิ่งขึ้น • ควรออกแบบปุมใหดูเหมือนปุม โดยอาจใช

เงา หรือสามมติิ เขามาชวยทําใหดูเหมือนปุมมากยิ่งขึ้น

• ควรจะมีขั้นตอนที่เปนมาตรฐานเดียวกันในการทํากิจกรรมตางๆ

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

• ระบบควรชวยใหผูใชกรอกขอมูลเทาที่จําเปนเทานั้นและใหผูใชเสียเวลาในการกรอกนอยที่สุด เชน ในการกรอกฟอรม ไดแก การกรอกวันเดือนป ควรจะเขียนformat ที่ตองการใหผูใชกรอกไวขางๆ field

42



ดวย (วัน/เดือน/ป) หรือ ใช calendar เปนเครื่องมือใหผูใชคลิกเลือกวันแทนที่จะตองใหผูใชกรอกเอง

• ในชองการกรอกตัวเลขงบประมาณ ควรมีการขึ้นตัว ลูกน้ํา (,) อัตโนมัติถามีการกรอกเลขในหลักพันและหลักลาน

2 ระดับความเสี่ยงเฉลี่ยดานประสิทธิภาพการใชงานของระบบหรือโปรแกรม (Efficiency / Efficient to use) ได 5 (เปนความเสี่ยงระดับสูงที่สุด) ประกอบดวย 2.1 ประสิทธิภาพของระบบ (Efficiency) ถา

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

ระดับ 5 สีแดง โดยเฉลี่ยผูทดสอบใชเวลาในการทําแตละกิจกรรมเปนเวลาเกินกวา 2 นาที ถึอวาเปนการทํางานที่ชาเกินกวามาตรฐานที่ควรจะเปนมาก

• ควรออกแบบระบบใหงายตอการใชงาน • ควรออกแบบโครงสรางของขอมูลโดยให

ผูใชมีสวนรวมในการออกแบบ (User-Centered Analysis and Design)

43



3 ระดับความเสี่ยงเฉลี่ยดานการทดสอบความงายตอการจดจํา (Memorability / Easy to remember) ได 4 (ความเสี่ยงระดับสูง) ประกอบดวย 3. 1 ความสามารถในการจดจําการใชระบบ

(Memorability) ถาเปนในกรณีที่ผูใชงานระบบไดเคยใชระบบ เมื่อผูใชกลับมาใชงานระบบฯหลังจากที่เขาไมไดใชระบบไปซักชวงเวลาหนึ่ง เขาสามารถใชงานระบบไดคลองแคลวเพียงใด

ระดับ 4 สีสม พบวามีผูทดสอบ 60% (3 คนจาก 5 คน) ที่ไมสามารถเรียนรูโครงสรางของขอมูลได จึงทําใหเมื่อผูใชกลับมาใชงานระบบฯ ในเมนูที่ตองทําขั้นตอนคลายเดิม เขาก็ไมสามารถใชงานระบบไดคลองแคลว


• เมื่อใชโปรแกรมไปแลวซักระยะหนึ่งควรจะทาํการประเมินโปรแกรมและนําfeedback ที่ไดมาปรับแกโปรแกรม

44



4 ระดับความเสี่ยงเฉลี่ยดานขอผิดพลาดของระบบ และการแกไขขอผิดพลาดโดยผูใชระบบ (Errors / Few Errors) ได 5 (ความเสี่ยงระดับสูงที่สุด) ประกอบดวย

4.1 ระบบฯสามารถอํานวยใหผูใชสามารถแกไขขอผิดพลาดขณะใชระบบไดดีเพียงใด (Error Handling)

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

ผูทดสอบไมอานขอความใน Error Message เลยจนทํางานตอไมไดจึงอาน บางครั้ง “พอเจอ Error แลวกลัว ไมกลาทําอะไร กลัวจะไปกระเทือนระบบของเขา”อาน Error ที่ฟองเปนภาษาอังกฤษไมรูเรื่อง ไมเขาใจ

• ขอความฟองที่แสดงใน Error Message ควรระบุปญหาที่เกิดขึ้น พรอมใหทางแกไขแกผูใชที่ชัดเจน และควรใชขอความเปนภาษาไทย

• ควรมีการจัดทําเมนูชวยเหลือ เชน Help หรือ Troubleshooting

45



1. ขอความฟองเปนภาษาอังกฤษ ผูทดสอบอานแลวตีความผิด ไมเขาใจอยางที่ระบบตองการจะสื่อ

2. ทําอยางไรขอความฟองก็ไมหายไป และหาทางกลับไปหนาจอที่กําลังทํางานอยูไมได

3. ผูใชไมสามารถแกไข Error ดวยตนเองได ไมเขาใจวาเกิดปญหาอะไรขึ้นและจะแกไขไดอยางไร เพราะขอความที่ปรากฏขึ้นหนาจอเวลามีปญหา บางทีขึ้นเปนภาษาอังกฤษ เชน ODBC Call Fail และไมบอกวิธีการแกไขให (ขอความฟองไมชัดเจน)

4. เมื่อผูทดสอบพบขอผิดพลาดแลวไมสามารถแกไขดวยตนเองได “ทําไมคลิกอะไรก็ไมไดแลวละ

46



คะ” , “แลวถาเปนยังงี้จะทําไงละคะปดไปเลย หรืออยางไร” , “จะแกอยางไรก็ไมรู”

5 ระดับความเสี่ยงเฉลี่ยดานความพึงพอใจของผูใชระบบ (Satisfaction / Subjectively pleasing) ได 2.8 (ความเสี่ยงระดับปานกลาง) ประกอบดวย 5.1 ความคาดหวังในเรื่องสมรรถนะของ

โปรแกรม ระดับ 2.65 สีเหลือง

1. เห็นดวยเพียงเล็กนอยวา FMS นี้มีประโยชนสําหรับการทํางานบริหารโครงการ

2. ไมแนใจวาการใชงาน FMS นี้ชวยทําใหผูรวมทดสอบระบบสามารถทํางานดานบริหารโครงการไดรวดเร็วขึ้น

3. ไมแนใจวาการใช FMS นี้ชวยใหประสิทธิภาพการทํางานดานบริหารโครงการดีขึ้น (เมื่อเทียบกับการลงบันทึกเกี่ยวกับงานดานบริหารโครงการดวยมือ) โดยสามารถทํางานไดมากขึ้นในเวลา

• ในขั้นการเก็บความตองการและขั้นการวิเคราะหความตองการของผูใชควรจะตองมีการพิจารณาใหดีวาระบบที่จะออกแบบไดทําการรวบรวมฟงกชันที่ผูใชและที่องคกรตองการ

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

• ควรออกแบบระบบใหซับซอนนอยกวานี้ และในขั้นการออกแบบควรมีการทดสอบระบบ โดยวัดเวลาที่ผูทดสอบใชในการทํา

47



เทาเดิม 4. เห็นดวยวาถาผูรวมทดสอบระบบ

ใช FMS เปน จะทาํใหผูรวมทดสอบระบบไดรับการยอมรับจากผูรวมงาน และเจานาย มากยิ่งขึ้น

แตละกิจกรรม ถาใชเวลานานเกินกวาที่คาดหมายไวควรหาทางแกไขระบบดวย

5.2 ความคาดหวังเรื่องการใชความพยายามของผูใชงาน

ระดับ 3.68 สีสม

1. ไมเห็นดวยเพียงเล็กนอยวาการใชงาน FMS นั้นเขาใจงายและชัดเจน

2. ไมแนใจวาผูรวมทดสอบระบบจะกลายเปนผูมีทักษะความสามารถในการใชงาน FMS เปนอยางดีไดโดยงาย

3. ไมเห็นดวยเพียงเล็กนอยว าFMS นั้นงายตอการใชงาน

4. ไมเห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบสามารถเรียนรูการใชงาน FMS ไดโดยงาย


• เมื่อใชโปรแกรมไปแลวซักระยะหนึ่งควร

48



จะทาํการประเมินโปรแกรมและนําfeedback ที่ไดมาปรับแกโปรแกรมดวย

• ควรกําหนดหรือตั้งชื่อ Tab ชื่อปุมและชื่อใน list ใหสื่อความหมายกับผูใช เครื่องมือที่สามารถนํามาใชเพื่อสรางชื่อเมนู คือ Card Sorting โดยจะใหผูใชมีสวนรวมในการตั้งชื่อเมนู และควรใชคาํตางๆ (Terminology)ที่ผูใชคุนเคยในการตั้งชื่อเมนูตางๆ

• ควรกําหนดหรือตั้งชื่อ Tab ชื่อปุมและชื่อใน list ใหมีวามแตกตางกันอยางชัดเจนและสื่อความหมายไดเขาใจ

• สําหรับชื่อเมนู ชื่อ Tab ชื่อปุมและชื่อใน list ควรจะใชGlosses ซึ่งเปน pop-up window ที่แสดงคําอธิบายเพิ่มเติมวา เมนู Tab ปุม หรอื list คืออะไร ผูใชจะไดสามารถอานทาํความเขาใจ กอนที่จะคลิกเลือก

49



• ควรออกแบบTabใหดูเหมือนTab โดยอาจใชเงา หรือสามมิติ เขามาชวยทําใหดูเหมือนTabมากยิ่งขึ้น

• ควรออกแบบปุมใหดูเหมือนปุม โดยอาจใชเงา หรือสามมติิ เขามาชวยทําใหดูเหมือนปุมมากยิ่งขึ้น

• ควรจะมีขั้นตอนที่เปนมาตรฐานเดียวกันในการทํากิจกรรมตางๆ

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

• ระบบควรชวยใหผูใชกรอกขอมูลเทาที่จําเปนเทานั้นและใหผูใชเสียเวลาในการกรอกนอยที่สุด เชน ในการกรอกฟอรม

50



ไดแก การกรอกวันเดือนป ควรจะเขียนformat ที่ตองการใหผูใชกรอกไวขางๆfield ดวย (วัน/เดือน/ป) หรือ ใช calendar เปนเครื่องมือใหผูใชคลิกเลือกวันแทนที่จะตองใหผูใชกรอกเอง

• ในชองการกรอกตัวเลขงบประมาณ ควรมีการขึ้นตัว ลูกน้ํา (,) อัตโนมัติถามีการกรอกเลขในหลักพันและหลักลาน

5.3 ทัศนคติตอการใชงาน ระดับ 4 สีสม 1. ไมเห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบเห็นควรที่จะนํา FMS มาใชในการบริหารโครงการ

2. ไมแนใจวางาน (ของผูรวมทดสอบระบบ) มีความนาสนใจมากขึ้นเมื่อนํา FMS มาใช

3. ไมเห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบรูสึกสนุกไปกับการใช FMS ได

• ควรออกแบบระบบใหไมซับซอน (ดูรายละเอียดเพิ่มเติมตามขอเสนอแนะของขอ 5.2)

• ควรออกแบบใหไมต่ํากวาความคาดหวังของผูใชทั้งในดานหนาของหนาจอระบบ (User Screen)และดานโครงสรางของขอมูล

51



4. ไมแนใจวาผูรวมทดสอบระบบชอบหรือที่จะใช FMS

5.4 สภาพของสิ่งที่จะชวยอํานวยใหเกิดการ

ดําเนินงาน ระดับ 2.86 สีเหลือง

1. เห็นดวยวาผูรวมทดสอบระบบมีความรูพื้นฐานที่จําเปน (โดยเฉพาะดานการใชคอมพิวเตอรขั้นพื้นฐาน) เพียงพอที่จะใช FMS ได

2. ไมเห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบมีความรูพื้นฐานที่จําเปน (โดยเฉพาะงานที่เกี่ยวกับการบริหารโครงการ) เพียงพอที่จะใช FMS ได

3. ไมเห็นดวยวาผูรวมทดสอบระบบมีความรูพื้นฐานที่จําเปน (ที่ไดรับจากการฝกอบรมการใชโปรแกรม“ระบบบริหารโครงการ”—FMS ) เพียงพอที่จะใช FMS ได

• ควรจัดทําคูมือที่เปนปจจุบันสําหรับทุกระบบ

• ควรมีการฝกอบรมการใชโปรแกรมใหกับผูใชทุกคน และควรมีการทดสอบหลังผึกอบรมวาผูใชเขาใจและสามารถทํางานบนระบบไดจริง

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

52



4. ไมเห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบมีความรูพื้นฐานที่จําเปน (ที่ไดรับจากการอานคูมือการใชงาน FMS) เพียงพอที่จะใช FMS ได

5.5 ความรูสึกเชื่อมั่นของผูใช ระดับ 1.58 สีเขียว

1. ไมเห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบนาจะสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ดวยตัวของผูรวมทดสอบระบบเอง

2. เห็นดวยวา“ผูรวมทดสอบระบบสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถามีคนคอยชวยเหลือเมื่อเกิดปญหา

3. เห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบสามารถใช FMS ทํางานบริหารโครงการใหเสร็จ

• ควรมีการจัดทําเมนูชวยเหลือ เชน Help หรือ Troubleshooting

• ขอความที่แสดงใน Error Message ควรระบุปญหาที่เกิดขึ้น พรอมใหทางแกไขแกผูใชที่ชัดเจน และควรใชขอความเปนภาษาไทย

53



สมบูรณได ถาผูรวมทดสอบระบบมีเวลามากพอ

4. เห็นดวยเพียงเล็กนอยวาผูรวมทดสอบระบบสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถามีเมนูชวยเหลือ เชน Help หรือ Troubleshooting

5.6 ความตั้งใจทีจ่ะใช ระดับ1.86

สีเขียว 1. เห็นดวยเพียงเล็กนอยวาผูรวม

ทดสอบระบบมีความตั้งใจทีจ่ะใช FMS ในอนาคต

2. ไมแนใจวาผูรวมทดสอบระบบคาดวาจะใช FMS ในอนาคต”

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

54

บทที่ 5

บทสรุปและขอเสนอแนะ

บทสรุป

เทคนิคการทดสอบความสามารถการใชงานที่ใชในการศึกษาวิจัยคร้ังน้ี เปนเทคนิคที่เก่ียวของกับการสรางสถานการณทํางานใหเสมือนจริง โดยใหผูทดสอบทํากิจกรรมพ้ืนฐานที่สําคัญ ภายใตการสังเกตการณอยางใกลชิดของผูตรวจสอบ รวมทั้งการใหผูรวมทดสอบคิดและพูดในขณะที่ทํางาน ผูตรวจสอบเฝาสังเกต จดบันทึก และถายวีดีทัศนเพ่ือศึกษาพฤติกรรมของผุรวมทดสอบอยางใกลชิด รวมทั้งการทําแบบสอบถามและการวิเคราะหแบบสอบถามตามทฤษฎีการยอมรับและการใชเทคโนโลยี

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

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

การนําเทคนิคน้ีมาใชในการตรวจสอบเมื่อพิจารณาตามแนวทางการพิจารณาการใชเทคนิค

การตรวจสอบที่ใชคอมพิวเตอรชวย 6 ประการที่อางถึงในแนวคิดทฤษฎี คือ 1) ความรู ความเช่ียวชาญ และประสบการณของผูตรวจสอบ 2) ความเปนไปไดของเทคนิคที่จะใชกับอุปกรณคอมพิวเตอร 3) ประสิทธิภาพและประสิทธิผลของเทคนิคที่ใช 4) ขอจาํกัดดานเวลาและการประสานงานกับหนวยงานที่จะตรวจ 5) ความเชือ่ถือไดของระบบและสภาพแวดลอมของระบบสารสนเทศทีจ่ะตรวจ และ 6) ระดับของความเสี่ยงในการตรวจสอบ พบวา เทคนิคน้ีมีขอดีหลายประการ เชน

1) ไมตองใชความรู ความเชีย่วชาญ และประสบการณดานเทคโนโลยีสูงเมื่อเปรียบเทียบเทคนิคอื่น

2) ไมตองกังวลปญหาดานเทคนิคเพราะใชโปรแกรมระบบงานขององคกรเอง

55

3) ไมเสียคาใชจายสูง รวมทัง้แบบประเมินตางๆสามารถนํากลับมาใชไดอีกในการตรวจสอบครั้งตอไป

4) ใชกระบวนการและขั้นตอนเขาใจไดงาย ทําใหผูบริหารและผูใชอนุญาตใหใชระบบและยอมรับผลตรวจสอบไดงาย

5) เปนวิธีที่ใหขอมูลหลักฐานทางตรงเกี่ยวกับผูใช ซ่ึงผูตรวจสอบไมเคยมีมากอน 6) เปนเทคนิคการตรวจสอบที่จําเปนมากและใชเปนหลักฐานไดดี ในกรณีที่ตรวจสอบ

โปรแกรมระบบงานที่องคกรพัฒนาเอง และไมมีการทดสอบการยอมรับของผูใชกอนนํามาใช 7) ไดขอมูลเกี่ยวกับปญหาในการออกแบบหนาจอระบบงาน และขอเสนอในการปรับปรุงที่

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

ไมถูกตองครบถวนของขอมูลท่ีเก็บในแฟมหรือฐานขอมูล 2) ผูตรวจสอบยังจําเปนตองใชเทคนิคการตรวจสอบอื่นในการคนหาและแกไขความไม

ถูกตองครบถวนของขอมูลท่ีเก็บในแฟมหรอืฐานขอมูล

ขอเสนอแนะ

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

56

เอกสารและสิ่งอางอิง

อุษณา ภัทรมนตรี. 2551. การตรวจสอบและการควบคุมดานคอมพิวเตอรทางบัญชี. โรงพิมพจามจุรีโปรดักส. กทม.

อุษณา ภัทรมนตรี. 2550. การตรวจสอบภายในสมัยใหม. บริษัทเท็กซแอนดเจอรนัลพับลิเคชั่นจํากัด. กทม.

American Institute of Certified Public Accountants (AICPA). 2001. Statement of Auditing Standards No. 94. The effect of information technology on the auditor's consideration of internal control in a financial statement audit. New York.

1998. The IT committees’ top 10 list. Journal of Accountancy. 1998;2:183

Cerullo, M. V. and Cerullo, M. J. 2003. Impact of SAS No.94 on Computer Audit Techniques.

ISACA. 1, 2003.

Curtis,M.B and Payne, E. A. 2008.An examination of contextual factors and individual characteristics affecting technology implementation decisions in auditing. International Journal of Accounting Information Systems, 9:104–121.

Fischer, M.J. 1996. Realizing the benefits of new technologies as a source of audit evidence: An interpretive field study. Accounting, Organizations and Society, 21(2/3):219–42.

Genov, A. 2005. Iterative Usability Testing as Continuous Feedback: A Control Systems Perspective. Journal of Usability Studies, 1(l), 18-27.

Hunton,E.J, Bryant,M.S. and Bagranoff,N.A.2004. Core Concepts of Information Technology Auditing.Wiley.

Institute of Internal Auditors (IIA). 2008. Exposure Draft International Standards for the Professional Practice of Internal Auditing. Retrieve March 5, 2008. From: http://www.theiia.org/Guidance.

2002. Innovative Uses of Computer Audit Techniques and Continuous Auditing. Retrieve August 5, 2008. From: http://www.theiia.org/Research Project.

ISACA. 2008. IS Auditing Guideline 3: Use of Computer- Assisted Audit Techniques.

Retrieve August 5, 2008. From: http://www.isaca.org.

Manomuth, V. 2006. An empirical test of the minimal cognitive processing theory of web buyer behavior. Unpublished Doctoral Dissertation, Utah State University, Logan.

Nelson, R. and Cheney, P. 1987. Training end users: an exploratory study. MIS Quarterly, 1987:547–59 (Dec).

Nielsen, J. 2003. Usability 101: Introduction to usability. Retrieved Jan 25, 2008, from: http://www.useit.com/alertbox/20030825.html

57

2000a. Designing Web Usability. Retrieve Jan 14, 2008. From: http://www.usability.gov/methods/

2000b. Why You Only Need to Test with 5 Users. Retrieved Jan 25, 2008, from: http://www.useit.com/alertbox/20000319.html 1993. Usability engineering. San Diego, CA: Morgan Kaufmann.

1994. Usability Engineering. Burlington, MA :Academic Press Inc.

1993. Usability engineering. San Diego, CA: Morgan Kaufmann.

Norden, L., Creelan, J. M., Kimball, D., and Quesenbery, W. 2006. The machinery of democracy: Usability of voting systems. New York: Brennan Center of Justice at NYU School of Law.

Redish, J. 2007.Expanding Usability Testing to Evaluate Complex Systems. Journal of Usability Studies, 2(3): 102-111.

Venkatesh, V., Morris, M. G., Davis, G. B. and Davis, F. D. 2003. User Acceptance of Information Technology: Toward a Unified View. MIS Quarterly 27(3): 425-478.

Van Duyne, D. K., Landay, J. A., and Hong, J. I. 2003. The design of sites: Patterns, principles, and processes for crafting a customer-centered Web experience. San Francisco: Addison Wesley.

Vendrzyk VP, Bagranoff. 2003. The evolving role of IS audit: a field study comparing the perceptions of IS and financial auditors. Advances in Accounting; 20:141–63.

58

ภาคผนวก

แบบฟอรมท่ีใชในการเก็บขอมูล (Protocol for FMS)

กรุณารอจนกวาผูควบคุมการทดสอบระบบฯจะบอกใหเปดหนาถัดไป

59

บทนํา วันน้ีทานจะมโีอกาสไดใชโปรแกรม“ระบบบริหารโครงการ FMS” และจะไดมีสวนรวม

ในการประเมนิและแสดงความคิดเห็นจากประสบการณที่ทานไดรับจากการใชโปรแกรม FMS

ดังน้ันขอความรวมมือจากทาน ในการทดสอบ/ประเมินระบบดวย แตอยากจะเรียนใหทานทราบวา การทดสอบในครั้งน้ีไมใชเปนการวัดความสามารถของตัวทานเอง แตเปนการวัด/ประเมินความสามารถในการใชของตัวระบบงานเอง (Usability) เพ่ือจะไดทราบวาระบบงานมีประสิทธิภาพในการใชงานมากนอยเพียงใด (Efficiency) ระบบงานมีการใชงานไดยาก / งายเพียงใด (Ease of Use) ระบบงานสามารถอํานวยใหผูใชสามารถแกไขขอผิดพลาดขณะใชไดดีเพียงใด (Error Handling) เปนตน

ขอบคุณคะ คณะทํางาน


60

Instruction for Evaluating the FMS

[วิธีการดําเนินการในการทดสอบ/ประเมินการความสามรถในการใชงานโปรแกรม“ระบบบริหารโครงการ” (FMS)]

การทดสอบ/ประเมินระบบในครั้งนี้จะใชเวลาทั้งส้ินประมาณ 45 นาที ส่ิงที่ทานจะตองทําคือ การเขาไปใชโปรแกรม “ระบบบริหารโครงการ” (FMS) เพ่ือทําการบันทึกขอมูลตางๆเกี่ยวกับโครงการ โดยทางทีมงานไดจัดเตรยีมขอมูลไวใหทานแลว (ใหทานคิดอยูในใจวาเวลาของทานนั้นมีคามาก) หนาถัดไปจะมีคําส่ังตางๆใหทานทําตามเพื่อที่จะไดสามารถเขาระบบเพื่อทําการกรอก/บันทึกขอมูลได สิ่งที่ทานจะตองทํามีดังน้ี: 1. กรอกแบบสอบถามขอมูลทั่วไป

2. คลิกเปดโปรแกรม“ระบบบริหารโครงการ” (FMS) 3. กรอกชื่อผูใช และรหัสผานที่กําหนดให

a. ชื่อผูใช user b. รหัสผูใช xu6a

4. ใหทานหาทางดวยตนเองในการทํากิจกรรมที่ไดถูกกําหนดไวใหเปนขอๆ (Specified Tasks)ใหไดสําเร็จ (เชน เลือกวาจะคลิกปุมไหน คลิกหนาจอไหน)

5. ใหทานพูดและวิจารณ(Think aloud) เพื่อแสดงความคิดเห็น ในระหวางการทํากิจกรรมที่ไดถูกกําหนดไวให (Specified Tasks) ( หมายความวา ส่ิงที่ทานคิดอยูในใจ ขอใหพูดออกมาดังๆ เพื่อท่ีจะทําใหทางผูควบคุมการทดสอบระบบฯ ไดทราบวาทานพบอุปสรรคอะไรบางในการใชงานระบบฯ)

6. สําหรับการบันทึกลงในระบบฯ ใหทานใชขอมูลท่ีไดถูกจัดเตรียมไวใหเทานั้น 7. กอนท่ีจะเริ่มทํากิจกรรมแตละขอใหแจงตอผูควบคุมฯ เพื่อที่ผูควบคุมฯจะลงบันทึกเวลาเริ่มตน (Start

time) 8. ถาทานคิดวาทานไดทํากิจกรรมที่ไดถูกกําหนดไว(Specified Tasks) ใหเปนขอๆไดสําเร็จแลว ใหทาน

แจงตอผูควบคุมการทดสอบระบบฯ c. ถาทานทําถูกตองจริง ผูควบคุมฯจะลงบันทึกวา “สําเร็จ” และลงบันทึกเวลาสิ้นสุด (End

time) d. ถาทานยังทําไมถูกตอง ผูควบคุมฯจะแจงวา “ยังไมถูกตองคะ” “จะลองทําตอไหมคะ”

i. ทานสามารถจะพยายามทํากิจกรรมขอนั้นตอไปก็ได หรือ ii. ทานจะหยุดทํากิจกรรมขอนั้นก็ได

iii. ถาทานจะหยุดทํากิจกรรมขอน้ัน ใหแจงกับผูควบคุมการทดสอบระบบฯดวย เพ่ือจะไดลงบันทึกเวลาและเพื่อที่จะไดทําในขอถัดไป [หมายเหตุ: ทานอาจมีความรูสึกทอใจวาไมสามารถทํากิจกรรมขอนั้นๆใหสําเร็จได อาจจะเปนเพราะหาปุมไมพบ หรือทางที่เลือกไวไมอํานวยใหทํากิจกรรมไดสําเร็จ เปนตน]


61

แบบสอบถามขอมูลทั่วไป

คําส่ัง กรุณาตอบคําถามทุกขอ เมื่อตอบคําถามทุกขอแลวกรุณาแจงตอผูควบคุมฯ

1. ทานทํางานในตําแหนงผูประสานงานฯที่องคกรนี้ มานานเทาไหร นอยกวา 6 เดือน 1-2 ป มากกวา 2 ป

2. ทานเคยไดรับการฝกอบรมการใชโปรแกรม“ระบบบริหารโครงการ”—FMS มาทั้งสิ้นประมาณกี่คร้ัง (ตลอดชีวิตของทาน)

0 คร้ัง (ไมเคย) 1 ครั้ง มากกวา 1 ครั้ง

3. ทานเคยใชโปรแกรม“ระบบบริหารโครงการ”—FMS มาทั้งสิ้นประมาณกี่คร้ัง (ตลอดชีวิตของทาน)

0 คร้ัง (ไมเคย) 1 ครั้ง มากกวา 1 ครั้ง

4. ทานเคยใชคอมพิวเตอรในการทํางาน มาทั้งสิ้นประมาณกี่คร้ัง (ตลอดชีวิตของทาน)

0 คร้ัง (ไมเคย) 1-4 คร้ัง 5-9 คร้ัง

10-49 ครั้ง 50-99 ครั้ง มากกวา 100 คร้ัง

5. ทานเคยใชโปรแกรมสําเร็จรูปโปรแกรมอื่นๆ มาทั้งสิน้กี่คร้ัง

[หมายเหตุ เชน ไมโครซอทฟออฟฟศ หรือ โปรแกรมใชงานในออฟฟศอ่ืนๆ]

0 คร้ัง (ไมเคย) 1-4 คร้ัง 5-9 คร้ัง

10-49 ครั้ง 50-99 ครั้ง มากกวา 100 คร้ัง

6. ทานเคยใชคอมพิวเตอรในการทํางาน บอยมากนอยแคไหน 0 (ไมไดใชงานเลย) ใชงานทุกป (1-2 ครั้งตอป) ใชงานทุกสามเดือน (3-4 ครั้งตอป) ใชงานทุกเดือน ใชงานทุกอาทติย ใชงานทุกวัน (ใชงานบอย)

7. ทานเคยใชโปรแกรมสําเร็จรูปโปรแกรมอื่นๆ]ในการทํางาน บอยมากนอย

แคไหน

0 ครั้งตอป(ไมไดใชงานเลย) ใชงานทุกป (1-2 ครั้งตอป) ใชงานทุกสามเดือน (3-4 ครั้งตอป) ใชงานทุกเดือน ใชงานทุกอาทติย ใชงานทุกวัน (ใชงานบอย)

แบบเก็บขอมูลเพ่ือประเมิน โปรแกรม“ระบบบริหารโครงการ” (FMS) เมื่อตอบคําถามทุกขอแลว กรุณาแจงตอผูควบคุมฯ

กรุณากรอกแบบสอบถาม เมื่อทานไดทํางานทุกขอไดเสร็จสมบูรณเทาน้ัน


62

คําสั่ง: กรุณาอานคําสั่งตามลาํดับโดยละเอียด เพื่อทีจ่ะทํางาน (Specified Tasks) ที่ไดถูกกาํหนดไวใหเปนขอๆ ใหไดสําเร็จ

กิจกรรมท่ี 1 – บันทึกรายละเอียดโครงการและออกรหัสโครงการ

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 1จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 1: บันทึกขอมูล โครงการเชิงรุกเพ่ือออกรหัสโครงการ

2.1. บันทึกรายละเอียดโครงการตามขอมูลโครงการที่กําหนดให (ขอมูลที่ใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้ 2.2. ออกรหัสโครงการ 2.3. เมื่อบันทึกและออกรหัสองคกรเรียบรอยแลวใหปดฟอรม

o วันที่รับโครงการ – ลงวันที่ที่ทําการทําสอบระบบ o ชื่อโครงการ – คูมือกระบวนการจัดทําสัญญาโครงการ

เชิงรุก o ระยะเวลาโครงการ วันเร่ิมตน --1 ก.ย. 2550 o ระยะเวลาโครงการ วันกําหนดเสร็จ -- 31 ต.ค. 2550 o ประเภทโครงการ – การวิจัย/พัฒนาองคความรู o เลือก -- โครงการปกติ o ชุดโครงการ -- ไมตองกรอก o องคกรรับทุน – ศูนยกลางระยอง o เปนโครงการประเมินผล ? -- ไมตองประเมิน ถาทานจะหยุดทํากิจกรรมที่ 1 ใหแจงกับผูควบคุมการทดสอบระบบฯดวย เพ่ือจะไดลงบันทึกเวลา

3. บันทกึเวลาสิ้นสุด (End Time) ของการทํา กิจกรรมที่ 1จากเวลาทีป่รากฏอยูบนหนาจอคอมพิวเตอร

o สําเร็จ o ไมสําเร็จ

ไดรหัสโครงการเลขที่

50-

63

กิจกรรมท่ี 2 – บันทึกเพิ่มขอมูลองคกร

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 2จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 2: บันทึกเพิ่มขอมูลองคกร

2.1. บันทึกเพ่ิมขอมูลองคกรตามขอมูลที่กําหนดให (ขอมูลท่ีใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้ (หมายเหตุ องคกรที่ขอรับทุนท่ีจะใหกรอก ยังไมมีรายชื่ออยูในฐานขอมูล เน่ืองจากเปนองคกรรับทุนรายใหม) 2.2. และออกรหัสองคกร 2.3. เมื่อบันทึกและออกรหัสองคกรเรียบรอยแลวใหปดฟอรม

o ชื่อองคกร – ศูนยรวมใจคน 2 o ประเภทองคกร – หนวยงานเอกชน o กระทรวง --ไมตองกรอก o กรมกอง -- ไมตองกรอก o ที่ต้ังองคกร – 250 ถนนวิทยุ o จังหวัด – กรุงเทพ o รหัสไปรษณีย -- 10400 o โทรศัพท -- 02 234 5678

ถาทานจะหยุดทํากิจกรรมที่ 2 ใหแจงกับผูควบคุมการทดสอบระบบฯดวย เพ่ือจะไดลงบันทึกเวลา

3. บันทกึเวลาสิ้นสุด (End Time) ของการทํา กิจกรรมที่ 2 จากเวลาทีป่รากฏอยูบนหนาจอคอมพิวเตอร o สําเร็จ o ไมสําเร็จ

ไดรหัสองคกรเลขที่

64

กิจกรรมท่ี 3 – การทําหนังสือสงใหผูทบทวนโครงการ (Reviewer)

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 3 จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 3: การทําหนังสือสงเอกสารใหผูทบทวนโครงการ (Reviewer) และพิมพหนังสือสงเอกสาร

2.1. กรอกรายละเอียดสําหรับการทําหนังสือเพื่อขอขอคิดเห็นและขอเสนอแนะเพื่อพิจารณาโครงการจากผูทบทวนโครงการ (reviewer) ตามขอมูลท่ีกําหนดให (ขอมูลที่ใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้

โดยใหเลือกโครงการที่ทานไดทําการกรอกไว (จากกิจกรรมที่1) ทานสามารถเปดยอนไปดูเลขที่โครงการที่ทานไดจดบันทึกไวในหนา 5

(หมายเหตุ องคกรไดจัดทําแบบฟอรมหนังสือเพ่ือสงใหผูทบทวนโครงการเตรียมไวในฐานขอมูลแลว เพียงแตผูประสานงานจะตองเขาไปกรอกวันที่จะออกหนังสือ และ กรอกชื่อผูทวบทวนโครงการ)

2.2. และพิมพหนังสือสงเอกสาร ออกมาดูทางหนาจอ (เพ่ือรอพิมพออกทางเครื่องพิมพตอไป) 2.3. เมื่อบันทึกและพิมพเรียบรอยแลวใหปดฟอรม

o หนังสือสงเอกสาร / วันที่ – 15 ส.ค. 2550 o หนังสือสงเอกสาร / เลขท่ีเอกสาร (สถานะ) --ไมตองกรอก o ผูทบทวน( โครงการ) – กาญจนา แกวเทพ



ระบุสถานะ:

65

กิจกรรมท่ี 4 – การเพิ่มเติมขอมูลโครงการ—ขอมูลงบประมาณที่ องคกรอนุมัต ิ

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 4 จากเวลาทีป่รากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 4: บันทึกเพิ่มเติมขอมูลโครงการ—ขอมูลงบประมาณที่ องคกรอนุมัต ิ

2.1. บันทึกเพ่ิมเติมขอมูลของโครงการ เกี่ยวกับขอมูลงบประมาณท่ี องคกรอนุมัติ ตามขอมูลที่กําหนดให (ขอมูลที่ใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้


2.2 เมื่อบันทึกเรียบรอยแลวใหปดฟอรม

o งบที่ (องคกรอนุมัติ) – 9,000 บาท o ปงบประมาณ -- 2550 o เลือกแผนงาน– 0204 (ทุนอุปถัมภ) o งบที่ขอจากหนวยงานอ่ืน – Rockefeller Foundation จํานวน – 1,000 บาท


3. บันทกึเวลาสิ้นสุด (End Time) ของการทํา กิจกรรมที่ 4 จากเวลาทีป่รากฏอยูบนหนาจอคอมพิวเตอร


66

กิจกรรมท่ี 5 – บันทึกขอมูลการแบงงวดงาน / งวดเงิน

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 5 จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 5: บันทึกขอมูลการแบงงวดงาน / งวดเงิน และ พิมพ กําหนดระยะเวลาสงงาน

2.1. บันทึกรายละเอียดงวดงาน งวดเงิน วันที่สงผลงาน ผลงานที่นําสง องคกร และเงื่อนไขตามขอมูลที่กําหนดให (ขอมูลท่ีใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้


2.2. และพิมพ กําหนดระยะเวลาสงงาน ออกมาดูทางหนาจอ (เพื่อรอพิมพออกทางเครื่องพิมพตอไป) 2.3. เมื่อบันทึกเรียบรอยแลวใหปดฟอรม

o งวดงานที่ -- 1 • เร่ิม -- 1 ก.ย. 2550 ส้ินสุด -- 30 ก.ย. 2550 • วันที่นําสงผลงาน -- 20 ก.ย. 2550 • ผลงานที่นําสง องคกร และเงื่อนไข -- องคกร จายเงินอุดหนุนภายใน 15 วันเมือไดรับสัญญาที่ลงนามครบถวน • คาตอบแทน – 0 บาท • คาดําเนินการ – 6,000 บาท

o งวดงานที่ -- 2 • เร่ิม -- 1 ต.ค. 2550 ส้ินสุด -- 31 ต.ค. 2550 • วันที่นําสงผลงาน -- 20 ต.ค. 2550 • ผลงานที่นําสง องคกร และเงื่อนไข -- องคกร จายเงินอุดหนุนภายใน 15 วันเมือไดรับเอกสารและเห็นชอบกัน

รายงานดังนี้ • คาตอบแทน – 0 บาท • คาดําเนินการ – 3,000 บาท



67

กิจกรรมท่ี 6 – อนุมัติโครงการ

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 6 จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 6: อนุมัติโครงการ

2.1. ใหสมมุติวาไดมีการอนุมัติโครงการเรียบน้ีรอยแลว ใหเปล่ียนสถานะโครงการนี้ เปน “อนุมัติ“ (จากเดิม สถานะ: อยูระหวางทบทวนโครงการ) โดยกรอกขอมูลวันท่ีอนุมัติ หมายเหตุ และสาระสําคัญตามขอมูลท่ีกําหนดให (ขอมลูที่ใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางน้ี

โดยใหเลือกโครงการที่ทานไดทําการกรอกไว (จากกิจกรรมที่1) ทานสามารถเปดยอนไปดูเลขที่โครงการที่ทานไดจดบันทึกไวในหนา 5 2.2. เมื่อบันทึกเรียบรอยแลวใหปดฟอรม

o วันที่อนุมัติ – 20 ส.ค. 2550 o หมายเหตุ – ผานการทบทวนจากreviewerแลว o สาระสําคัญ – ไมมีขอแกไข




68

กิจกรรมท่ี 7– บันทึกขอมูลโครงการ--เพื่อทํารายงานสรุปประกอบการขออนุมัติโครงการ

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที ่7 จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 7 : บันทึกขอมูลโครงการ--เพื่อเพ่ือทํารายงานสรุปประกอบการขออนุมัติโครงการ

2.1. เพ่ือทํารายงานสรุปเพ่ือขออนุมัติ (อ.2) ใหบันทึกเพ่ิมเติมขอมูลโครงการ ตามขอมูลที่กําหนดให (ขอมูลที่ใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้

โดยใหเลือกโครงการที่ทานไดทําการกรอกไว (จากกิจกรรมที่1) ทานสามารถเปดยอนไปดูเลขที่โครงการที่ทานไดจดบันทึกไวในหนา 5 2.2. และพิมพรายงานสรุปเพื่อขออนุมัติ (อ.2) ออกมาดูทางหนาจอ (เพื่อรอพิมพออกทางเครื่องพิมพตอไป) (หมายเหตุ ใหในรายงานสรุปแสดงขอมูลที่กรอกดวย) 2.3. เมื่อบันทึกเรียบรอยแลวใหปดฟอรม

o วัตถุประสงค– เพ่ือกระตุนให ประชาชนมีทักษะชีวิตครอบครัว o กลุมเปาหมาย– คนเมืองจังหวัดกรุงเทพ o กิจกรรมหลัก– เขาคาย o การพิจารณาใหทุน – ตามเอกสารแนบ o การปรับขอเสนอโครงการ --ตามเอกสารแนบ… ปรับงบเหลือ 9,000 บาท o ผูรับทุนไดปรับแกแลว -- ตามคําแนะนําของ ผูทรงคุณวุฒิ o พรอมนี้ไดแนบ – แบบขอรับทุน , เอกสารโครงการที่ปรับแลว o พรอมนี้ไดแนบ –สรุปความเห็นและเอกสารทบทวนจากผูทรงคุณวุฒิ ภายนอก 1 คน o การพัฒนาโครงการเชิงรุก -- 1 - องคกร รวมพัฒนาแผนงาน/โครงการกับภาคี o วันที่อนุมัติ – 20 ส.ค. 2550 o ระดับความนาสนใจ -- 3



69

กิจกรรมท่ี 8 – บันทึกขอมูลเพื่อจัดทําสัญญาและออกรหัสสัญญา

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 8 จากเวลาทีป่รากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 8 : บันทึกขอมูลเพ่ือจัดทําสัญญาและออกรหัสสัญญา

2.1. ใหทานเลือกโครงการที่ทานไดทําไวมาจัดทําสัญญา โดยใหบันทึกรายละเอียดสัญญาตามขอมูลท่ีกําหนดให (ขอมูลที่ใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้

โดยใหเลือกโครงการที่ทานไดทําการกรอกไว (จากกิจกรรมที่1) ทานสามารถเปดยอนไปดูเลขที่โครงการที่ทานไดจดบันทึกไวในหนา 5 2.2. และออกรหัสสัญญา 2.3. เมื่อบันทึกเรียบรอยแลวใหปดฟอรม

o วันที่ (ในสัญญา) – 21 ส.ค. 2550



ไดรหัสสัญญาเลขที่

50- -

70

กิจกรรมท่ี 9 – พิมพสัญญา

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 9 จากเวลาทีป่รากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 9: พิมพสัญญา

2.1. ใหทานเลือกสัญญาเลขที่ 50-00-0011 ท่ีขึ้นมาจากฐานขอมูล 2.2. และพิมพสญัญา 2.3. เมื่อบันทึกเรียบรอยแลวใหปดฟอรม


3. บันทกึเวลาสิ้นสุด (End Time) ของการทํา กิจกรรมที่ 9 จากเวลาทีป่รากฏอยูบนหนาจอคอมพิวเตอร


71

กิจกรรมที่ 10 – ปดโครงการ

1. บันทกึเวลาเริ่มตน (Start Time) ของการทํา กิจกรรมที่ 10 จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร 2. กิจกรรมที่ 10: ปดโครงการ

2.1. ใหสมมุติวาไดมีการทําสัญญาและดําเนินโครงการเรียบนี้รอยแลว ใหเปลี่ยนสถานะโครงการนี้ เปน “ปดโครงการ“ (จากเดิม สถานะ: อนุมัติ) โดยกรอกขอมูลวันที่ปดโครงการ หมายเหตุ และสาระสําคัญตามขอมูลที่กําหนดให (ขอมูลท่ีใหไดขีดเสนใตไว) ดังปรากฏในกรอบขางลางนี้

โดยใหเลือกโครงการที่ทานไดทําการกรอกไว (จากกิจกรรมที่1) ทานสามารถเปดยอนไปดูเลขที่โครงการที่ทานไดจดบันทึกไวในหนา 5 2.2. เมื่อบันทึกเรียบรอยแลวใหปดฟอรม

o วันที่ปดโครงการ – 1 พ.ย. 2550 o หมายเหตุ – โครงการส้ินสุดอยางสมบูรณreviewerแลว o สาระสําคัญ – ราบร่ืน


3. บันทกึเวลาสิ้นสุด (End Time) ของการทํา กิจกรรมที่ 10 จากเวลาที่ปรากฏอยูบนหนาจอคอมพิวเตอร



72

แบบสอบถามความคิดเห็นของผูใชโปรแกรม“ระบบบริหารโครงการ”—FMS คําส่ัง: กรุณาตอบคําถามขางลางท้ังหมด 22 ขอโดยอางอิงจากประสบการณที่ทานไดรับจากการใชโปรแกรม“ระบบบริหารโครงการ”—FMS ในครั้งน้ี

1 ไมเห็นดวยอยางมาก

2 ไมเห็นดวย

3 ไมเห็นดวยเพียงเล็กนอย

4 ไมใชอันใดอันหนึ่ง

(อยูระหวางไมเห็นดวยกับเห็นดวย)

5 เห็นดวย เพียง

เล็กนอย

6 เห็นดวย

7 เห็นดวย อยางมาก

ความคาดหวังในเรื่องสมรรถนะของ โปรแกรม“ระบบบริหารโครงการ”—FMS

1. ขาพเจาเห็นวา FMS นีม้ีประโยชนสําหรับการทํางานบริหารโครงการ

1

2

3

4

5

6

7

2. การใชงาน FMS นี้ชวยทําใหขาพเจาสามารถทํางานดานบริหารโครงการไดรวดเร็วขึ้น

1

2

3

4

5

6

7

3. การใช FMS นี้ชวยใหประสิทธิภาพการทํางานดานบริหารโครงการดีข้ึน (เมื่อเทียบกับการลงบันทึกเกี่ยวกับงานดานบริหารโครงการดวยมือ) โดยสามารถทํางานไดมากข้ึนในเวลาเทาเดิม

1

2

3

4

5

6

7

4. ถาขาพเจาใช FMS เปน จะทําใหขาพเจาไดรับการยอมรับจากผูรวมงาน และเจานาย มากยิ่งขึ้น

1

2

3

4

5

6

7

ความคาดหวังเร่ืองการใชความพยายามของผูใชงาน FMS

5. การใชงาน FMS นั้นเขาใจงายและชดัเจน

1

2

3

4

5

6

7

6. ขาพเจาจะกลายเปนผูมีทักษะความสามารถในการใชงาน FMS เปนอยางดีไดโดยงาย

1

2

3

4

5

6

7

7. ขาพเจาเห็นวา FMS นั้นงายตอการใชงาน

1

2

3

4

5

6

7

8. ขาพเจาสามารถเรยีนรูการใชงาน FMS ไดโดยงาย

1

2

3

4

5

6

7

73










ทัศนคติตอการใชงาน FMS

9. ขาพเจาเห็นควรที่จะนํา FMS มาใชในการบริหารโครงการ

1

2

3

4

5

6

7

10. งาน (ของขาพเจา) มีความนาสนใจมากขึ้นเมื่อนํา FMS มาใช

1

2

3

4

5

6

7

11. ขาพเจารูสึกสนุกไปกับการใช FMS

1

2

3

4

5

6

7

12. ขาพเจาชอบ/ที่จะใช FMS 1

2

3

4

5

6

7

สภาพของสิ่งที่จะชวยอํานวยใหเกิดการดําเนินงาน

13. ขาพเจามีความรูพื้นฐานที่จําเปน (โดยเฉพาะดานการใชคอมพิวเตอรข้ันพ้ืนฐาน) เพียงพอที่จะใช FMS ได

1

2

3

4

5

6

7

14. ขาพเจามีความรูพื้นฐานที่จําเปน (โดยเฉพาะงานที่เกี่ยวกับการบริหารโครงการ) เพียงพอที่จะใช FMS ได

1

2

3

4

5

6

7

15. ขาพเจามีความรูพื้นฐานที่จําเปน (ท่ีไดรับจากการฝกอบรมการใชโปรแกรม“ระบบบริหารโครงการ”—FMS ) เพียงพอท่ีจะใช FMS ได

1

2

3

4

5

6

7

16. ขาพเจามีความรูพื้นฐานที่จําเปน (ท่ีไดรับจากการอานคูมือการใชงาน FMS) เพียงพอที่จะใช FMS ได

1

2

3

4

5

6

7

74










ความรูสึกเชื่อม่ันของผูใช FMS

17. ขาพเจานาจะสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ดวยตัวของขาพเจาเอง

1

2

3

4

5

6

7

18. ขาพเจาสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถามีคนคอยชวยเหลือเมื่อเกิดปญหา

1

2

3

4

5

6

7

19. ขาพเจาสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถาขาพเจามีเวลามากพอ

1

2

3

4

5

6

7

20. ขาพเจาสามารถใช FMS ทํางานบริหารโครงการใหเสร็จสมบูรณได ถามีเมนูชวยเหลือ เชน Help หรือ Troubleshooting

1

2

3

4

5

6

7

ความตั้งใจท่ีจะใช FMS

21. ขาพเจามีความตั้งใจที่จะใช FMS ในอนาคต

1

2

3

4

5

6

7

22. ขาพเจาคาดวาจะใช FMS ในอนาคต

1

2

3

4

5

6

7

75

ประวัติการศึกษาและการทํางาน 1. รองศาสตราจารย อุษณา ภทัรมนตร ี

ประวัติการศึกษา • Northumbria University, U.K. (M.B.R.) • University of Florida, U.S.A. (M.B.A. in Accounting - Honourable และ

โดยทุนรัฐบาล • มหาวิทยาลัยธรรมศาสตร(บัญชีบัณฑิต เกียรตินิยม) • โรงเรียนเตรียมอุดมศึกษา พญาไท (นักเรียนติดบอรดประเทศไทย สาย

วิทยาศาสตร)

การทํางานปจจุบัน ประสบการณการทํางาน

• รองศาสตราจารย คณะบริหารธุรกิจ มหาวิทยาลัยเกษตรศาสตร • ประธานคณะกรรมการดําเนินงานโครงการบัญชีภาคพิเศษ

มหาวิทยาลัยเกษตรศาสตร • ผูสอบบัญชีรับอนุญาตแหงประเทศไทย • รองคณบดี ฝายวิชาการ คณะบริหารธุรกิจ มหาวิทยาลัยเกษตรศาสตร • คณะกรรมการศึกษาของสหพันธฺนักบัญชีระหวางประเทศ (IFAC) • ผูเชี่ยวชาญดานการตรวจสอบการดําเนินงาน สํานักงานตรวจเงินแผนดิน • ขาราชการสาํนักงานตรวจเงินแผนดินดีเดน • Canadian Comprehensive Audit Fellow - ประเทศแคนาดา • อาจารยประจาํคณะพาณิชยศาสตรและการบัญชี มหาวิทยาลัยธรรมศาสตร

ผลงานวิชาการ ตําราและหนังสือ 1. การตรวจสอบภายในสมัยใหม : แนวคิดและกรณีศึกษา 2. การตรวจสอบและควบคมุดานคอมพิวเตอร 3. การตรวจสอบและควบคมุภายใน : แนวคิดและกรณีศึกษา 4. การใชโปรแกรมตรวจสอบระบบงานบญัช ี

76

ผลงานวิจัย 1. Applying Usability Testing To Evaluate Information Technology Control Of In-House

Developed Software Application (ป2550 -ไดรับคัดเลือกใหนําเสนอผลงานในการประชุมวิชาการ The IT Audit Symposium รวมกับการประชุมวิชาการดานการตรวจสอบภายในระหวางประเทศ (The IIA Conference 2008) ที่เมืองซานฟรานซิสโก สหรัฐอเมริกาในวันที่ 6-9 กรกฎาคม 2551 และไดพิมพเผยแพรในเอกสารการประชมุวิชาการ e-Case 2009 ที่สิงคโปรในวันที่ 8-10 มกราคม 2552)

2. The Study of the Relationship between the Disclosure of the Corporate Governance and the Firm Performance.(ป 2546 -ไดนําเสนอในการประชุมวิชาการ KU Conference ครั้งที่ 43)

3. The Continuing Professional Education Program in Thailand (ป 2542-2544 ไดนําเสนอในการประชุมวิชาการคณะกรรมการการศึกษา IFAC รวมกับสมาคมผูสอบบัญชีประเทศฮังการี วันที่ 27-30 สิงหาคม 2544)

บทความวิชาการ/ผลงานวิชาการ 1. การวางแผนการสอบบัญช ี2. International Education Standards for Professional Accountants 3. Recognition of Pre-Certification Education Providers by IFAC Member Bodies. 4. Towards Competent Professional Accountants.

77

2. ดร.วรพรรณ เรืองผกา ประวัติการศึกษา • ปริญญาเอก ดานระบบขอมูลสารสนเทศทางธุรกิจ [Doctor of Philosophy in

Education (Business Information Systems)] จาก มหาวิทยาลัยยูทาหสเตท ประเทศสหรัฐอเมริกา ดวยระดับคะแนนเฉลี่ย 3.88 สําเร็จการศึกษาเมือ่วันที่ 5 พฤษภาคม พ.ศ. 2549

• ประกาศนียบัตรรับรองใหเปนนักวิเคราะหความสามารถในการใชงานของประดิษฐกรรม [Certified Usability Analyst (CUA)] จาก Human Factor International, Inc., USA http://humanfactors.com/training/cualist.asp

• ปริญญาโทดานการบัญชี เนนดานระบบสารสนเทศทางการบัญชี [Master of Accounting (Information System)] จาก มหาวิทยาลยัยูทาหสเตท ประเทศสหรัฐอเมริกา ดวยระดับคะแนนเฉลี่ยสะสม 3.97 สําเร็จการศึกษาเมื่อเดือนสิงหาคม พ.ศ. 2543

• ปริญญาตรีดานการบัญชี (Bachelor of Accounting) เกียรตินิยมอันดับหน่ึง จากมหาวิทยาลัยเกษตรศาสตร เมื่อเดือนมีนาคม พ.ศ. 2539

ประวัติการทํางาน • ขาราชการอาจารยระดับ 7 ภาควิชาบัญชี คณะบริหารธุรกิจ มหาวิทยาลัยเกษตรศาสตร (เดือนกันยายน พ.ศ. 2540 ถึง ปจจุบัน)

• ท่ีปรึกษาและผูออกแบบเวปแอพพลิเคชั่นโครงการพัฒนาระบบสารสนเทศทางคลินิกสูการวิจยั (เดือน ธันวาคม พ.ศ.2550 ถึง ปจจุบัน)

• ผูออกแบบเวปไซตและโปรแกรมเมอร ออกแบบและพัฒนาตัวตนแบบเวปไซตใหกับบริษัทตาง ๆ เชน สภากาชาดของเมอืงโลแกน รัฐยูทาห ประเทศสหรัฐอเมริกา บริษัทอีกอสอีโกซิสเต็ม และบริษัทวิทยาศรม จํากัด เปนตน

• ผูชวยนักวิจัย ภาควิชาระบบขอมูลสารสนเทศทางธุรกิจ ภาควิชาระบบขอมูลสารสนเทศทางธุรกิจ เมืองโลแกน รัฐยูทาห ประเทศสหรัฐอเมริกา

• ผูชวยสอน วิชาการพัฒนาการจัดการขอมูลบนเวปไซต ภาควิชาระบบขอมูลสารสนเทศทางธุรกิจ เมืองโลแกน รัฐยูทาห ประเทศสหรัฐอเมริกา (พ.ศ. 2548- 2549)

• ผูชวยผูตรวจสอบบัญชี บริษัทเอรินสแอนดยัง ประเทศไทย (พ.ศ. 2539 – 2540)

78

Documents

รายงานวิจัย เรื่อง4.1 ผลการทดสอบกิจกรรมจากผ ู ร วมทดสอบท ั้ง 5 คน 32 4.2 ผลการทดสอบความคิดเห็นของผ