Cloud FinOps สำคัญต่อธุรกิจยุคดิจิทัลอย่างไร

I. Introduce

ใช้ Cloud เพราะถูกกว่า

ใช้ Cloud เพราะดีกว่า

ใช้ Cloud เพราะอยากสร้าง Innovation

ใช้ Cloud เพราะยืดหยุ่นกว่า

ประโยชน์ของ Cloud computing จริง ๆ แล้วคืออะไรกันแน่ ทำไมเห็นหลาย ๆ คนอธิบายถึง Cloud computing ถึงยังไม่ค่อยเข้าเห็นภาพชัดเจน บทความนี้มี FinOps Foundation ซึ่งศึกษาเกี่ยวกับประโยชน์ของ Cloud computing มาอธิบายให้เห็นอย่างเป็นระเบียบ โดยศึกษาจาก use case ของบริษัทเช่น Apple, Accenture, Adobe, Deloitte, Fidelity, HSBC, Microsoft, VMware เป็นต้น

‍

‍

II. FinOps ?  

A. FinOps (cloud Financial Operations)

FinOps Foundation เป็น Foundation ที่ได้รับการสนับสนุนจาก The Linux Foundation ในการช่วยสร้าง Foundation สำหรับการส่งเสริมและผลักดันการใช้งาน Cloud computing อย่างมีคุณค่า

B. History

FinOps Foundation ก่อตั้งขึ้นมาตอน 2019 เกิดขึ้นหลังจากการมีอยู่ของ Cloud computing ประมาณ 10 ปี (AWS establish in 2006) ซึ่งถือว่าเป็น Foundation ที่มีอายุน้อยมาก (เทียบกับปี 2023) ฉะนั้นแล้วในส่วนของ Framework และ Best practice มีการอัพเดทอย่างรวดเร็วและเพิ่มขึ้นอย่างต่อเนื่อง เนื่องจาก use case ส่วนที่ยังไม่ได้ค้นพบยังมีอยู่มหาศาล.

‍

III. Cloud in real life  

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

A. Spending decision

ความรับผิดชอบด้านการจัดซื้อถูกย้ายมาให้กับทีม Engineer โดยตั้งใจหรือไม่ตั้งใจ ก็เป็นไปได้ทั้งสองกรณี โดยปกติแล้วการตัดสินใจในรายจ่ายเราจะมอบให้กับทีม Financial หรือทีม Procurement แต่เมื่อเป็น Cloud environment เรียบร้อยแล้ว คนที่เข้าใจ Cloud มากที่สุดกลับเป็นทีม Engineer ที่ไม่มีหน้าที่ในการรับผิดชอบการใช้จ่ายของบริษัท หรือเมื่อ Spending decision ยังอยู่กับทีม Financial คนที่ต้อง Commit รายจ่ายของ Cloud computing ก็ยังคงเป็นทีม Engineer.

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

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

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

B. Variable spending

การใช้งานบางบริษัทของผู้ให้บริการ Cloud computing ไม่ได้คิดค่าบริการตามจำนวนชั่วโมงที่ใช้งานอย่างที่เราเข้าใจ แต่การคิดค่าบริการอาจคิดจากจำนวนการเรียกใช้งานหรือจำนวนของ bandwidth เป็นต้น

ลักษณะการคิดค่าบริการดังกล่าวมีข้อดีคือเป็นการคิดค่าใช้จ่ายแบบ Variable cost เราสามารถนำไปใช้ในการคำนวณหา Cost Of Goods Sold (COGS) ได้ทันที

ส่วนข้อเสียคือถ้าทีม Financial ไม่เข้าใจที่มาของต้นทุนดังกล่าวแล้วไม่ได้ลงไว้ใน Variable cost หรือ COGS จะเกิดคำถามว่าทำไมค่าใช้จ่าย Cloud computing ในแต่ละเดือนนั้น ไม่เท่ากันและไม่สามารถพิจารณาค่าใช้จ่าย Cloud computing ล่วงหน้า

วิธีแก้ไขของหลายบริษัทคือไม่ใช้งาน Cloud computing ในส่วน Variable cost หรือไม่ต้องใช้งาน Cloud ไปเลย

C. Scalable resource

การปรับจำนวนทรัพยากรได้ตลอดเวลานั้นสามารถส่งเสริมให้เกิดนวัตกรรมได้ตลอดเวลา เนื่องจากทีม Engineer สามารถเข้าถึงทรัพยากรได้อย่างรวดเร็วและเข้าถึงบางทรัพยากรที่ไม่เคยมีมาก่อน เช่น การเข้าถึง High performance computer, การเข้าถึง Computer cluster เป็นต้น สิ่งเหล่านี้จะทำให้ทีม Engineer สามารถทดลองนวัตกรรมใหม่ ๆ หรือสำรวจความเป็นไปได้ใหม่ ๆ โดยปราศจากข้อจำกัดด้านการจัดซื้อ

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

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

‍

‍

IV. What is “REAL” cloud value ?

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

“Cloud FinOps“

Cloud FinOps (FinOps) นั้นถูกพัฒนามาจากวัฒนธรรมและระเบียบจาก Cloud financial management โดยมีการขับเคลื่อนดังนี้

“ช่วยให้บริษัทนั้นสามารถเข้าถึงคุณค่าของ Cloud computing และใช้อย่างมีประสิทธิภาพต่อธุรกิจมากที่สุด ผ่านการช่วยเหลือจากทีม Engineer, ทีม Finance และทีม Business นำไปสู่การทำงานร่วมกันระหว่างทีมงานเพื่อที่จะได้มาซึ่ง กระบวนการตัดสินใจด้านรายจ่ายโดยอาศัยข้อมูลเป็นตัวขับเคลื่อน“

ในแต่ละประโยคที่ FinOps foundation นั้นต้องการที่สื่อสารนั้น เราจะมาขยายความเพิ่มโดยเปรียบเทียบกับบริษัทที่ยังไม่เริ่มใช้งาน Cloud computing

“ช่วยให้บริษัทนั้นสามารถเข้าถึงคุณค่าของ Cloud computing และใช้อย่างมีประสิทธิภาพต่อธุรกิจมากที่สุด”

เนื่องจากการที่บริษัทต้องการเปลี่ยนมาใช้งาน Cloud computing มีประสบการณ์ไม่เพียงพอ, ไม่มีผู้เชี่ยวชาญที่เหมาะสม หรือมอบให้เป็นหน้าที่ของทีม Engineer ไปศึกษาและสรุปผล จึงไม่แปลกที่บริษัทจะมองเห็นถึง Downside ที่มีมากกว่าฝั่งของ Upside

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

“ผ่านการช่วยเหลือจากทีม Engineer, ทีม Finance และทีม Business”

หากปราศจากการช่วยเหลือซึ่งแต่ละทีมจะเกิดเหตุการณ์สงครามกลาง(การ)เมืองเกิดขึ้น เช่น

ทีม Business ได้ commit KPI สำหรับ KPI user satisfaction เพิ่มขึ้น 5% เนื่องจากรู้ว่าทรัพยากร IT สามารถปรับเพิ่มได้จึงคุยกับทีม Engineer โดยได้ข้อสรุปว่าจำเป็นต้องให้ Software นั้นแสดงผลรวดเร็วขึ้นและประมวลผลไวขึ้น

ผ่านไป 1 เดือน User satisfaction เพิ่มขึ้น 10% ทีม Business นำตัวเลขดังกล่าวไปโชว์กับที่ประชุมโดยบอกว่าเราปรับปรุง Software ของเราอย่างถูกต้องเรียบร้อยแล้ว จบไตรมาศนี้ตัวเลข user satisfaction น่าจะไม่เปลี่ยนแปลง

ขณะที่ทีม Business ประชุมอยู่นั้น ทีม Finance กับ ทีม Engineer ก็กำลังประชุมอีกหนึ่งหัวข้อ โดยหัวข้อที่ประชุมอยู่คือหัวข้อ รายจ่ายด้าน Cloud computing ที่เพิ่มขึ้นอย่างรวดเร็ว ซึ่งทีม Finance ต้องการให้ค่าใช้จ่าย Cloud computing อยู่ในระดับเดิม เนื่องจาก Forecast รายจ่ายไว้ล่วงหน้า 1 ปีเรียบร้อยแล้ว ทีม Engineer จึงต้องลดรายจ่ายด้าน Cloud computing

ผ่านไปอีก 1 เดือน User satisfaction ลดลงจากเดือนก่อนหน้า 20% ทีม Business จึงเร่งกันหาสาเหตุว่าทำไมจู่ ๆ User satisfaction ถึงลดลงแล้วก็พบว่าเกิดจากทีม Engineer ได้ลดขนาดของ Cloud computing ลงไป ทำให้การแสดงผลและการประมวลผลนั้นช้าลง

ทีม Business จึงเข้าไปพูดคุยกับทีม Engineer ให้เพิ่มขนาด Cloud computing ให้เท่าเดิมแต่ทีม Engineer ทำไม่ได้เพราะทีม Finance ต้องการลดรายจ่าย ซึ่งทีม Business จึงต้องกดดันให้ทีม Engineer ทำผลลัพธ์ให้ได้เท่าเดิมแต่รายจ่ายต้องไม่เพิ่มขึ้น

ผ่านไปอีก 1 เดือน บริษัทดังกล่าวกลับไปซื้อ Server และใช้งาน On premise เหมือนเดิม ทีม Business ไม่สามารถ Commit KPI ได้เนื่องจากทรัพยากร IT มีจำกัด ทีม Finance ได้ตัวเลขรายจ่ายตามที่วางแผนไว้ ส่วนทีม Engineer ไม่ต้องโดนกดดันจากทีมอื่น

“นำไปสู่การทำงานร่วมกันระหว่างทีมงานเพื่อที่จะได้มาซึ่ง กระบวนการตัดสินใจด้านรายจ่ายโดยอาศัยข้อมูลเป็นตัวขับเคลื่อน (Data-driven spending decision)”

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

จากเหตุการณ์ตัวอย่างดังกล่าว เราสามารถเห็นถึงโอกาสที่เราสามารถไปถึงจุดมุ่งหมายโดยเพิ่มรายจ่ายด้าน Cloud computing

ถ้าให้เปรียบเทียบให้เห็นภาพชัดขึ้น โดยเราสามารถเปรียบเทียบกับการดำเนินงานฝั่ง Marketing ในการดำเนินงานส่วน Advertise ซึ่งเราต้องตั้ง Budget ก่อนเริ่มโฆษณาและผลลัพธ์ที่เราคาดหวัง ซึ่งสมการที่เรียบง่ายที่สุดและสมเหตุสมผลที่สุดคือ

Result = budget x efficiency

เปรียบเทียบกับการใช้งาน Cloud computing, FinOps Foundation อยากให้มองค่าใช้จ่ายด้าน Cloud computing ให้เหมือนกับ budget ที่เราใส่ลงไปในการโฆษณา ถ้าใส่น้อย Result ได้น้อยก็ไม่แปลก แต่ถ้าอยากได้ Result ที่มากขึ้นก็ควรจะเพิ่ม Budget มากขึ้น

ความสามารถที่น่าสนใจที่สุดของ Cloud computing คือส่วนของ Report เราสามารถที่จะปรับปรุงศักยภาพของ Report รวมถึงเราสามารถสร้าง Dashboard สำหรับรายจ่าย Cloud แบบ Realtime เทียบกับ จำนวนการใช้งาน Cloud แบบเรียล์ไทม์ (Realtime) หรือเทียบตัวชี้วัดอื่น ๆ ตามที่เราต้องการ

ส่วนของแบบแผนในการทำงานร่วมกันนั้นถูกกำหนดออกมาเป็นแต่ละ Domain โดยมีหน่วยย่อยคือ Capabilities

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

‍

V. แนวโน้มในการนำ FinOps ใช้ในบริษัท

เราอาจมองได้ว่าการเป็นที่ FinOps ยอมรับและการเป็นปัญหาที่พบในบริษัทที่ใช้งาน Cloud computing เราอาจมองได้จากการค้นหางานและการประกาศรับสมัครพนักงานในหน้าที่ความรับผิดชอบที่ใกล้เคียงกับที่นิยาม โดยแหล่งข้อมูลที่ทาง FinOps foundation นั้นนำมาแสดงให้เห็นคือข้อมูลจาก Linkedin และ FinOps Foundation Slack (Slack)

เราจะเห็นได้ว่าแนวโน้มการประกาศหางานใน Linkedin และ Slack นั้นเริ่มเติบโตมาตั้งแต่ปี 2019 และยังมีความต้องการที่สูงมากขึ้นเรื่อย ๆ เทียบจาก Slack Q1 ปี 2021 กับ Q1 ปี 2022 มีการเติบโตมากกว่า 3 เท่า

ในส่วนของ Linkedin นั้นมีการเติบโตตั้งแต่ปี 2019 ตลอดจนปี 2023 โดยเห็นได้ชัดในช่วงของปี 2021 - 2022 สอดคล้องกับข้อมูลใน Slack ที่มีการเติบโตขึ้นอย่างรวดเร็ว

หนึ่งข้อสังเกตุที่น่าสนใจคือบริษัทที่โพสประกาศรับสมัครลงใน Slack ส่วนใหญ่จะระบุความต้องการ FinOps practitioner certification ลงในเงื่อนไขการสมัครงาน

‍

VI. สัดส่วนของปัญหาและความท้าทาย

ผู้ชนะแบบไม่ต้องสงสัยคือเรื่องของการ Optimize cost โดยปัญหาดังกล่าวถือเป็นปัญหาที่อยู่มาเนิ่นนานและยังคงเป็นปัญหาและความท้าทายจนมาถึงปัจจุบัน เนื่องจาก Model การคิดราคาของผู้ให้บริการ Cloud computing นั้นมีหลากหลายรูปแบบ ซึ่งความซับซ้อนของผู้ใช้งานแต่แลกมากับความเป็นไปได้ที่จะประหยัดค่าใช้จ่าย บางรูปแบบนั้นเสนอราคาที่ถูกลงถึง 90 % แต่มีเงื่อนไขเพิ่มมาบางประการ ทำให้การ Optimize cost นั้นมีความจำเพาะขึ้นอยู่กับแต่ละบริษัท

อันดับถัดมาคือการประเมินรายจ่ายในอนาคต ซึ่งถือเป็นอีกความท้าทายหนึ่ง เนื่องจากการใช้งาน Cloud computing นั้นจะเกิดรายจ่ายเมื่อใช้งานและไม่คิดเงินในช่วงที่ไม่ใช้งาน ทำให้การประเมินรายจ่ายล่วงหน้านั้นเป็นไปได้ยาก

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

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

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

สุดท้ายคือเรื่องของการทำงานในทิศทางเดียวกันระหว่างทีม Finance และทีม Engineer ซึ่งสามารถขับเคลื่อน FinOps ได้อย่างเป็นรูปธรรมและชัดเจน เนื่องจากวัดผลได้โดยง่าย

‍

‍VII . FinOps framework ถูกสร้างขึ้นมาโดยมีหัวข้อหลักทั้งหมด 5 หัวข้อ ดังนี้

1. Maturity
2. Principles
3. Personas
4. Phases
5. Domains

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

เราขอเริ่มอธิบายจากหัวข้อแรก

A. Maturity

Maturity เราอาจจะเรียกได้ว่าเป็นประสบการณ์ของทีม แต่ในที่นี้ขอเรียกว่าความเข้ากันได้ เนื่องจากบางบริษัททีมมีความเข้ากันได้อยู่แล้ว เคยทำงานร่วมกันด้วยความเข้าใจดีเยี่ยม ความเข้ากันได้ของทีมนั้น ๆ ก็จะสูงตาม

ในบริบทของ FinOps เราแบ่ง Maturity ออกเป็น 3 ช่วง ได้แก่

1. Crawl

ช่วงแรกเริ่มของการนำ FinOps เข้ามาประยุกต์เข้ากับบริษัทของตัวเอง ซึ่งเราสามารถประเมินได้ว่าบริษัทที่อยู่ในช่วงดังกล่าวได้ว่า กระบวนการทำงาน, กระบวนการรายงานผล ยังอยู่ในรูปแบบของ Manual หรือไม่ได้ใช้ระบบอัตโนมัติเข้ามาช่วย รวมถึงการทำงานบางส่วน เช่น Forecast ค่าใช้จ่าย ยังคงต้องคำนวนใหม่ทุกครั้ง ยังไม่ได้สร้างสูตรหรือโมเดลในการช่วยคำนวน ต้องให้ทีม Finance ประเมินทุก ๆ คร้ัง

1. Walk

บางบริษัทอาจจะเริ่มจากช่วงนี้เลยก็เป็นไปได้ สำหรับช่วง walk นั้นจะเรียกได้ว่าเป็นช่วงของ Semi-Automate process เนื่องจากทีมมีบุคคลที่มีความสามารถในการสร้าง Automate process ด้วยตัวเอง ไม่ว่าจะเป็นทีม Engineer, ทีม Finance หรือทีม Finance ทำให้งานบางประเภทนั้นมีความสามารถในการทำงานอย่างอัตโนมัติ. Automate process ที่สร้างขึ้นมานั้นสามารถให้คนที่ไม่มีความเชี่ยวชาญที่เกี่ยวข้องสามารถใช้งานได้โดยไม่มีผู้เชี่ยวชาญ

1. Run

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

B. Principles

Principles คือสิ่งที่ระบุถึงสิ่งที่จำเป็นต้องบรรลุเมื่อต้องการนำ FinOps เข้ามาใช้ในบริษัท ส่วนของ Principles นั้นจะมีความใกล้เคียงกับ Framework ที่เกี่ยวข้องกับ Digital transformation อย่างเช่น Agile หรือ DevOps เนื่องจากต้องการให้บริษัทไม่จำเป็นต้องปรับตัวทั้งหมดเพื่อที่จะเริ่มนำ FinOps ไปใช้งาน โดย Principles นั้นมีอยู่ทั้งหมด 6 ข้อได้แก่

1. ทีมต้องทำงานร่วมกัน
2. ทุกคนต้องเป็นเจ้าของการใช้งาน Cloud computing ร่วมกัน
3. FinOps นั้นจะถูกขับเคลื่อนโดยทีมส่วนกลาง
4. Report ที่เกี่ยวข้อง (Engineer, Finance, Business) ต้องเข้าถึงได้และทันท่วงที
5. การตัดสินใจต้องถูกขับเคลื่อนโดยคุณค่าด้านธุรกิจผ่านการใช้งาน Cloud computing
6. ใช้ความได้เปรียบด้าน Variable cost จาก Cloud computing

C. Personas

Personas ในที่นี้จะระบุถึงแรงจูงใจ, ปัญหา, ตัวชี้วัดและสิ่งที่ได้จาก FinOps ซึ่ง Personas นั้นจะถูกแบ่งออกเป็น 5 บุคคลที่เกี่ยวข้องได้แก่

1. FinOps Practitioner

บุคคลผู้ซึ่งต้องการนำ FinOps เข้ามาใช้กับกระบวนการทำงานปัจจุบันของบริษัท โดยเป็นผู้ที่มีความเข้าใจใน Personas ของผู้อื่นมากที่สุด นิยามอย่างง่ายคือ ทีม Finance มองว่า (Practitioner) เป็นคนจากทีม Engineer แต่ทีม Engineer มองว่าเป็นคนจากทีม Fiannce

2. Executive

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

3. Business

ทีม Business หรือ Product owner ผู้ซึ่งต้องดูแลการเติบโตและวางเป้าหมายให้ตัวผลิตภัฑณ์หรือบริการที่กำลังดูแลอยู่นั้น ส่งมอบมูลค่าแก่ลูกค้าได้อย่างครบถ้วนและตรงจุด เป็นผู้ซึ่งเข้าใจในส่วนของ User หรือ Customer ได้ดีที่สุดจากทั้ง 5 บุคคลที่เกี่ยวข้อง

4. Finance

ทีม Finance เป็นทีมที่ดูแลเกี่ยวกับการลงทุนในแต่ละโปรเจคและต้องคอยประเมินถึงค่าใช้จ่ายระยะยาว โดยต้องประเมินถึงความคุ้มทุนของโปรเจคที่ต้องลงทุนและประเมินว่าเมื่อถึงเวลาใดจะเป็นจุด Break event point

5. Engineer

บุคคลที่เป็นคนตัดสินความเป็นไปได้ของการสร้างผลิตภัฑณ์หรือบริการ ซึ่งความเป็นไปได้สำหรับผลิตภัฑณ์หรือบริการทางด้าน software นั้น ตั้งอยู่บนพื้นฐาน 3 สิ่งคือ Quality, Cost และ Time สามารถเลือกได้แค่ 2 ใน 3 เท่านั้น

D. Phases

Phase กล่าวคือวงวนกระบวนการสำหรับ FinOps โดยกระบวนการดังกล่าวนั้นสามารถเริ่มจากกระบวนการใดก็ได้ ไม่จำเป็นต้องเริ่มจาก Inform แต่จำเป็นต้องทำตามลำดับเช่น เริ่มจาก Optimize จากนั้นเรียงไป Operate และ Inform ตามลำดับ ซึ่งเมื่อเราสามารถวนครบรอบได้แล้ว เราสามารถทำต่อไปได้ไม่มีที่สิ้นสุด เนื่องจากทุก ๆ ครั้งในการครบรอบสิ่งที่ทีมจะได้เพิ่มคือความเข้ากันได้ของทีม (Maturity)

Phase แบ่งออกด้วยกันทั้งหมด 3 phase ได้แก่

1.Inform

Phase inform จะเน้นผลลัพธ์ในการสร้างการเข้าถึงข้อมูล, การจัดการข้อมูล, การวัดผล, การกำหนดรายจ่าย และการ forecast รายจ่าย ในส่วนของ Inform จำเป็นต้องสร้างตัวชี้วัดโดยอาศัยข้อมูลจากทีมอื่นเข้ามาเป็นตัวแปรร่วมด้วย

2.Optimize

หลาย ๆ บริษัทมักอยากจะกระโดดเข้ามาใน Phase นี้เป็นส่วนแรก เนื่องจากเห็นผลได้รวดเร็วและมองเห็นถึงผลลัพธ์ได้ง่าย ในส่วนของ FinOps Foundation นั้นให้ความหมายของ Phase นี้เอาไว้ว่า เป็นช่วงที่ต้องมองหาความเป็นไปได้ในการลดต้นทุนและใช้ทรัพยากรที่มีอยู่ให้มีประสิทธิภาพสูงที่สุด หรือเข้าใจโดยง่ายว่า การ Optimize ทุกอย่างนั้นจะเกิดขึ้นแบบทฤษฎีก่อนนำไปให้ทีมที่เกี่ยวข้องนั้นนำไปใช้งานจริง

3.Operate

Phase นี้มักเป็นส่วนที่ถูกมองข้ามในการจำกัดความแต่ในการปฏิบัตินั้นเกิดขึ้นโดยไม่รู้ตัว ซึ่งการ Operate จะเป็นการเริ่มติดตามถึงตัวชี้วัดที่เราวางไว้, ติดตามถึงผลกระทบในส่วนของ Quality, Cost และ Time และในส่วนของการลงมือนำแผนการจาก Optimize นำไปใช้จริง

E. Domain

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

1. Understanding cloud usage and cost

สำหรับ Domain นี้คือการรวมรวบข้อมูลที่เกี่ยวข้องกับการใช้งาน Cloud computing และนำข้อมูลที่ได้มานั้ดจัดให้อยู่ในรูปแบบที่สามารถเข้าถึงได้ ซึ่งข้อมูลดังกล่าวต้องตอบสนองต่อแต่ละ Personas อย่างครบถ้วน

2. Performance Tracking & Benchmarking

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

3. Real-Time Decision Making

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

4. Cloud Rate Optimization

ภายใน Domain นี้จะกล่าวถึงการทำความเข้าใจเกี่ยวกับรูปแบบการคิดค่าบริการของผู้ให้บริการ Cloud computing และทำการปรับปรุงรายจ่าย Cloud computing ของบริษัทให้สอดคล้องกับรูปแบบการคิดค่าบริการของผู้ให้บริการ โดยคำนึงถึงข้อจำกัดที่แปรผันตามรูปแบบการคิดค่าบริการที่ต่างไป

5. Cloud Usage Optimization

Domain นี้ให้ความสำคัญถึงการใช้ทรัพยากรที่มีอยู่ให้คุ้มค่าที่สุด โดยการระบุและลงมือเปลี่ยนแปลงงานบางประเภทให้ประมวลผลให้ช่วงเวลาที่ Cloud computing นั้นไม่ได้ใช้งาน และรวมถึงการเปลี่ยนแปลงทรัพยากรที่มีอยู่ในเหมาะสมกับประเภทของงาน

6. Organizational Alignment

สำหรับ Domain นี้จะกล่าวถึงการที่บริษัทนั้นมีทิศทางในการใช้งาน Cloud computing ในทิศทางเดียวกันผ่าน Principles ของ FinOps ร่วมกัน เพื่อที่จะกำหนดวัฒนธรรมและนโยบายสำหรับบริษัทโดยไม่ขัดแย้งต่อวัฒนธรรมเดิมที่มีอยู่ของบริษัท

‍