SLA – Service Level Agreement

อัปเดต:
เวลาอ่าน 6 นาที
SLA – Service Level Agreement
รูปภาพ: Paradee Paradee | Dreamstime
แบ่งปัน

SLA คืออะไร และ SLA มีบทบาทอย่างไรในความสัมพันธ์ระหว่างลูกค้าและผู้รับเหมาในด้านไอที

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

SLA คืออะไร

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

SLA เป็นหนึ่งในหลักการพื้นฐานของการโต้ตอบระหว่างผู้ใช้บริการ (ส่วนใหญ่ในด้านระบบอัตโนมัติแบบบูรณาการ) และนักพัฒนา/ผู้รวมระบบไอทีที่ดำเนินโครงการตาม หลักการพื้นฐานของข้อตกลงดังกล่าว

การลดค่าแนวคิดของ SLA ในสถานการณ์นี้หมายถึงการลดค่ากระบวนทัศน์ของความสัมพันธ์ระหว่างลูกค้าและผู้รับเหมา

คุกกี้เป็นไฟล์ลึกลับที่น้อยคนนักจะรู้
คุกกี้เป็นไฟล์ลึกลับที่น้อยคนนักจะรู้
เวลาอ่าน 5 นาที
Ratmir Belov
Journalist-writer

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

SLA แบบดั้งเดิมเป็นข้อตกลงระหว่างลูกค้าและผู้ให้บริการ ซึ่งระบุอย่างชัดเจนถึงการรับประกันคุณภาพของโครงการ (ปลายทาง)

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

SLA
รูปภาพ: Joerg Stoeber | Dreamstime

ทุกวันนี้ เมื่อความท้าทายทางธุรกิจเริ่มซับซ้อนขึ้นเรื่อยๆ และวิกฤตต่างๆ นานา รวมถึงโรคระบาดใหญ่ ทำให้องค์กรต่างๆ ต้องลด time lag เพื่อปรับตัวให้เข้ากับมัน ให้ทำงานเร็วขึ้น ดีขึ้น ในรูปแบบใหม่ก็แปลก หากองค์กรไอทีไม่ตอบสนองอย่างเหมาะสม ในเวลาที่สั้นที่สุด วิธีการพัฒนากลุ่มที่ซับซ้อน (Agile, DevOps, กลุ่มการแบ่งปัน) ถูกนำมาใช้โดยโครงสร้างไอทีระดับมืออาชีพเกือบทั้งหมด – ทั้งบริษัทพัฒนาขนาดใหญ่และองค์กรไอทีขนาดเล็กที่มีความเชี่ยวชาญสูง

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

DevOps – การพัฒนาและปฏิบัติการ
DevOps – การพัฒนาและปฏิบัติการ
เวลาอ่าน 4 นาที
Ratmir Belov
Journalist-writer

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

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

การออกแบบโดเมนที่ขับเคลื่อนด้วย – การเขียนโปรแกรม DDD
การออกแบบโดเมนที่ขับเคลื่อนด้วย – การเขียนโปรแกรม DDD
เวลาอ่าน 5 นาที
Ratmir Belov
Journalist-writer

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

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

SLA
รูปภาพ: Joerg Stoeber | Dreamstime

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

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

การออกแบบ UX – การออกแบบประสบการณ์ผู้ใช้
การออกแบบ UX – การออกแบบประสบการณ์ผู้ใช้
เวลาอ่าน 4 นาที
Ratmir Belov
Journalist-writer

จนถึงตอนนี้ แนวทางนี้ยังไม่แพร่หลายในรัสเซียและยุโรปตะวันออก

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

บริษัทแห่งหนึ่งไม่สามารถแก้ไขงานที่ซับซ้อนเช่นนี้ในระดับประเทศได้ ต้องใช้ความพยายามร่วมกันของนักพัฒนาไอที ผู้วางระบบ ซัพพลายเออร์อุปกรณ์ และแน่นอนว่าเป็นความต้องการของลูกค้า . เส้นทางนี้จะผ่านเราไปในทุกกรณี แต่ต้องทำอย่างรวดเร็วและเป็นระบบ
คะแนนบทความ
0.0
0 รายการจัดอันดับ
ให้คะแนนบทความนี้
Kirill Vladimirov
Kirill Vladimirov
กรุณาเขียนความคิดเห็นของคุณในหัวข้อนี้:
avatar
  การแจ้งเตือนความคิดเห็น  
แจ้งเตือน
ให้คะแนนมัน ความคิดเห็น
แบ่งปัน