วิธีจัดทำเอกสารกลยุทธ์สำหรับการอัพเกรดซอฟต์แวร์เชิงพาณิชย์

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

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

ฉันจะบันทึกได้อย่างไรว่าไคลเอนต์เดสก์ท็อป A, B, C ... ขึ้นอยู่กับเดสก์ท็อป OS X และ RDBMS Y ซึ่งจะขึ้นอยู่กับเซิร์ฟเวอร์ OS Z และต่อไปนี้เป็นวิธีที่เราเก็บพวกเขาทั้งหมดไว้ใน ต้องมีหนังสืออยู่ข้างนอก แต่ googling ทั้งหมดของฉันได้นำฉันไปสู่สิ่งที่เกี่ยวกับกลยุทธ์ในการอัพเกรดซอฟต์แวร์หนึ่งชิ้นแทนที่จะเป็นกลยุทธ์ในการพิจารณาว่าจะใช้กลยุทธ์เหล่านั้นเมื่อใด

ดูเหมือนว่าคุณกำลังพยายามแก้ไขปัญหาหลายอย่างพร้อมกัน (และดูเหมือนจะไม่เป็นความคิดที่ดี)

จากสิ่งที่ฉันอ่าน:

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

การอัพเกรด "ส่วนสำคัญของซอฟต์แวร์"

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

ดังนั้นสิ่งแรกที่ฉันจะมองหาคือ: ผู้จัดการทราบเกี่ยวกับความเสี่ยงของซอฟต์แวร์ที่ล้าสมัยหรือไม่? พวกเขาบอกว่า?

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

ฉันจะทำการวิเคราะห์ว่าการอัพเกรดนั้นหมายถึงอะไรจริงๆ เตรียมสเปรดชีตอย่างง่ายพร้อมกิจกรรมและระยะเวลาที่พวกเขาจะต้องใช้ (หากคุณไม่ทราบให้เดาและเน้นย้ำอย่างชัดเจนว่าคุณไม่ทราบแน่ชัด) แต่โปรดจำไว้ว่าไม่ได้ระบุ "งานอัปเกรด" ไว้เป็นอย่างดีมันเป็นไปไม่ได้ที่จะทำตามเวลาแก้ไข / ราคาซ่อม

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

ในตอนท้ายคุณควรมีรายการกิจกรรมรายการความเสี่ยงรายการวัสดุ / คนที่คุณต้องการ ในคำที่ไม่จัดการกับการอัพเกรดเป็นปัญหาในชีวิตประจำวันทำมันเป็นโครงการ สิ่งนี้จะช่วยให้คุณสามารถควบคุมความต้องการอย่างฉับพลันของ บริษัท ของคุณได้

หากคุณมีปัญหาในการวิเคราะห์กิจกรรมที่ต้องทำคุณสามารถลองทำแผนที่ความคิด (sw สุดโปรดของฉันคือ xMind) แล้วแปลงเป็นเอกสารที่เป็นทางการมากขึ้น

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

อาจเป็นในกรณีนี้: พูดถึงว่าการอัพเกรดอาจไม่สามารถทำได้เลย

ไม่มีกลยุทธ์ระยะยาว

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

ตัวอย่างความต้องการทางธุรกิจ: ในอีกสองปีเราจะเปิดสำนักงานใหม่ในประเทศจีนและออสเตรเลีย

งานด้านไอทีที่ได้รับ: เตรียมรับพนักงานใหม่ที่เลวร้ายที่สุดสร้างโครงสร้างพื้นฐานในสำนักงานต่างประเทศจัดฝึกอบรมพนักงานใหม่ (อาจใช้ภาษาของตนเอง) เชื่อมต่อที่ปลอดภัยจากสำนักงานเหล่านั้นไปยังศูนย์กลาง ...

หากสิ่งต่าง ๆ เป็นไปด้วยดีคุณอาจมีกลยุทธ์ในอีกไม่กี่เดือนข้างหน้า? ดังนั้นประมาณครึ่งปีจนกระทั่งทุกอย่างตกลงกัน?

การบำรุงรักษาและจัดทำเอกสารโครงสร้างพื้นฐานของคุณ

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

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

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

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