✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

CCoE: איך שומרים על מצוינות בענן?

IsraelClouds
|
Jun 4, 2020
alt="blogs"
alt="blogs"
Events
title="Google"
alt="blogs"
Event

אחד מהצעדים הבסיסיים אותם ארגונים לוקחים כחלק מהמסע שלהם למעבר בענן, הוא הקמה של Cloud Center of Excellence (CCoE). מדובר בצוות מגוון שמטרתו היא להטמיע את המדיניות, המשמעת, הפרקטיקות המובילות, והארכיטקטורה הנדרשת בכדי לאמץ את טכנולוגיית הענן בדרך היעילה ביותר עבור ארגונים גדולים אחרים המעוניינים לעבור לענן.
משימה זו דורשת יכולות ביצוע גבוהות ומדויקות ביחד עם יצירתיות, בכדי ליצור ולחדש תהליכים מבוססי ענן, תוך שיפור של הליכים קיימים והימנעות מגורמים מגבילים בהליכים המסורתיים והקיימים.

ניתן להבין בקלות למה ארגונים רבים רוצים הדרכה לגבי הקמה ותפעול של CCoE משלהם, ויש שתי גישות מומלצות להגיע לתוצאה הרצויה: הראשונה היא הקמה של צוות חדש עם סט יכולות מגוונות מעולמות עקביים ופונקציונאליים שיכולות לסייע בהקמה של מודל ענן תפעולי. CCoE שנבנה בגישה זאת לרוב כולל נציגים מ-Ops של תשתיות, PMO, ארכיטקטורה ארגונית, App Dev, Infosec, Procurement ובקרת איכות.

הגישה השנייה היא למנף צוות מוביל ולהפיץ אותם מחדש כ-CCoE. בניגוד לגישה הראשונה בה יש צורך לגבש את הקבוצה ורק אז לפעול, התחלת עבודה עם הצוות המוביל שכבר מכיר את השותפים ויודע איך לעבוד יחדיו, תהיה מהירה וקלה יותר, וניתן יהיה לראות תוצאות תוך זמן קצר. גישה זו מתאימה יותר לארגונים גדולים שכבר הקימו צוותים העובדים עם מגוון מחלקות ומחזיקים בסט יכולות נרחב, ביחד עם יכולות פיתוח אגיליות.

איזו גישה עדיפה?

ישנו היגיון בשתי הגישות, ויש אינספור הוכחות לאפקטיביות של שתיהן בכל הנוגע לפעילות יעילה בארגון, אך מחקרים מצביעים שהדרך בה אנו מרכיבים את הקבוצות הנ"ל יכולה להשפיע לרעה על התוצאות שאנו מצפים לראות מתהליכים אלו. מחקרים אלו הניבו תוצאות אותן מיישמים כבר בסביבת העבודה המודרנית בכדי להקים צוותים מבוססי חדשנות (גם בענן), ונראה שהתוצאות עצמן מוצלחות. מידע מעניין נוסף – המסקנות התבססו על מחקר שבחן מה הופך מחזות זמר בברודווי למוצלחים, אך הקסם הוא להבין שמה שנכון עבור עיר המחזות, נכון גם עבור ארגונים גדולים.

החוקרים בריאן עוזי וג'ארט ספירו, למדו את יחסי הגומלין בין יוצרים (מלחינים, במאים, משוררים, כותבים, מפיקים וכו') מ-500 מחזות זמר שונים שהופקו בברודווי בין השנים 1945 ל-1989. באמצעות שימוש בקנה מידה שהתבסס על יחסי גומלין קודמים (שנקראו Q), החוקרים מצאו כי מחזות זמר בהם לא הייתה היכרות קודמת ועבודה משותפת (Q נמוך), נועדו לביצועים בינוניים ואף לכישלון. התמונה המפתיעה הציגה שגם במקרים בהם הצוותים הכירו אחד את השני ועבדו על מספר פרויקטים ביחד (Q גבוה), עדיין לא הייתה אינדיקציה מובטחת להצלחה. הנתון המעניין הציג, שצוותים בהם היה שילוב של מערכות יחסים קיימות וחדשות, היו בעלי סיכוי גדול פי 3 להצלחה. כלומר, אם תשמרו על איזון של אנשים שעבדו ביחד בעבר, ותצרפו אליהם אנשים חדשים לחלוטין – כנראה שתהיה לכם הפקה מוצלחת במיוחד. הסיבה לכך, היא שהאנשים הוותיקים יכלו לתרום רבות מהניסיון, הידע וההבנה שלהם בעקרונות התעשיה, אך האנשים החדשים הם אלו שהביאו איתם שפע של רעיונות חדשים ואנרגיה. עכשיו כשיש לנו את ההבנה ואנו יכולים ליישם אותה לגבי ארגונים, נשאלת שאלה – אילו אתגרים עומדים מולנו?

כשאנו מסתכלים על הגישה הראשונה, כיסינו את כל הנושאים המקצועיים שאנו צריכים בכדי להקים את הצוות הנדרש, אבל אנחנו בעצם נמצאים בקבוצה הראשונה במחקר, בה כולם היו חדשים אחד לשני. צוותים אלו צריכים להתאמץ יותר בכדי להביא תוצאות, וההתחלה שלהם קשה במיוחד ויש צורך להשקיע יותר בתיאום ובסנכרון שלהם. בהתחשב בעולם העסקי והטכנולוגי של היום, רוב הארגונים מעוניינים להשיג תוצאות טובות ומהר, ואין להם זמן או רצון לניסוי וטעייה.

הגישה השנייה מביאה לשולחן חברי צוות מנוסים המכירים האחד את השני, ולמרות שהם יכולים להתחיל להביא תוצאות מהיום הראשון, הרי שהסטטוס, וההצלחות שלהם מהעבר יכולים להיות בעוכריהם. הם יכולים לדוגמא, לצמצם את הזמן הנדרש מפרויקט ל-4 שבועות במקום 8 שבועות, אבל הם כנראה יעצרו בנקודה זו, יטפחו לעצמם על השכם ולא יחשבו על צמצום של אותו הזמן לשבועיים, שבוע, או אפילו מספר שעות בודדות. למה? מפני שהם עובדים כבר שנים עם מודלי עבודה ויחסי גומלין ספציפיים, המונעים מהם לבחון ולאמץ רעיונות חדשניים.

ב-2102, פרויקט מעניין במיוחד, הבין את מסקנות המחקר בברודווי ויישם אותו בהצלחה בפרויקט זה היה צורך להנהיג את צוות הענן הראשון בחברת Edmunds. המטרה הייתה להקים צוות חדש עם וותק והיכרות ברמות שונות, שיוכלו לייצר יעילות מחשבתית וביצועית חדשה. צוות מהנדסי התשתית הציג רשימת הישגים ענפה, הכוללת הקמת ענן פרטי עם פלטפורמת IaaS מבוססת Chef עם הספק אוטומטי. על פניו, נראה שהם היו הצוות המתאים ביותר למשימה.

למרות מה שהיה נראה לעין, ההחלטה שעמדה מאחורי הקמת הצוות, התבססה גם על פרמטרים מלבד שיפור המהירות באספקת והקמת השרתים, כמו שיפור הדרך בה אפליקציות ארכיטקטורה והפצה הועברו לענן. אותם פרמטרים של איך ניתן להשיג איזון בין יכולת הביצוע לבין חשיבה חדשנית, הובילו למפתחות העיקריים של הצלחה, שדרשו מאיתנו לחשוב יותר לעומק על תמהיל ה-CCoE בחברה.

ההחלטה הייתה ציוות לא קונבנציונאלי של מהנדסי התשתית המובילים והחברים הצעירים בצוות הבדיקות האוטומטיות. אמנם היה מדובר בהחלטה שאינה נפוצה בעולמות הענן המסורתיים, אך הזמן עבר וההחלטה הוכיחה את עצמה. בעוד הוותיקים בתשתית הביאו את הניסיון שלהם במערכות אוטומציה, מהנדסי התוכנה הכירו את האפליקציות טוב יותר מכל גורם אחר בחברה, ועל ידי הבנה זו היה קל להבין אלו אפליקציות היו מעולות, רעשניות או כאלו הדורשות תלותיות עדינה, ובכך מיפו מאות אפליקציות ארגוניות ופיתחו תכנית מואצת למעבר לענן, ביחד עם כלים ותהליכים עבור המעבר של אותן אפליקציות. כתוצאה מכך, החברה הצליחה לעבור לענן ולהפסיק את פעילות חוות השרתים האחרונה שלה כבר ב-2016.

השנים עברו ואיתן גם התובנות השונות לגבי הקמת צוותים למגוון מטרות, בין אם מדובר בפיתוח מוצרים ללקוחות קצה, או עבודות "מאחורי הקלעים", וישנם 2 קריטריונים עיקריים איתם מומלץ לעבוד:

1. מהי בעצם מטרת העל, ומיהם הבכירים או החברים בצוות שכבר עבדו יחדיו בשיתוף פעולה וברמה מספקת? סביר להניח שיש לכם כבר מספר שמות אשר יבטיחו שהתוצרים לא יהיו חובבניים.
2. מה חדש או שונה לגבי המטרה אותה מנסים להשיג, ומי יכול להציג פרספקטיבה שונה לגבי אותם אתגרים?

לסיכום

אין ספק שנקיטה בגישה זו יכולה לעורר מתחים ותחרותיות, אך בסופו של דבר, כדאי לעודד סביבה בה ניתן לצפות דברים כאלו מראש ולתעל אותם לטובת יצירתיות, ובכך להשיג תוצאות שהן מעבר למטרה פשוטה כמו גידול ארגוני. בשיטת פעולה, לאמצוותים אנשים אקראים יחדיו ומצפים שהכל יעבוד, אלא משלבים עובדים וותיקים בכדי לפתור את בעיית הביצועים הנמוכים בתחילת הדרך, אך עדיין לא מסתמכים על מודלים ישנים שלא בהכרח יעבדו, או יממשו רק חלק מהפוטנציאל.

ארגונים בוחרים להקים CCoE בכדי להתמקד במעבר לענן ולצפות ליציבות, אמינות וביצועים טובים ומהירים יותר, אך חשוב לזכור שהצוות אותו הם יקימו צריך לכלול את האיזון הנכון של יעילות תפעולית וחשיבה חדשנית, בכדי להשיג את היעדים הנדרשים בדרך הנכונה.


מאת: מערכת IsraelClouds

רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה

אחד מהצעדים הבסיסיים אותם ארגונים לוקחים כחלק מהמסע שלהם למעבר בענן, הוא הקמה של Cloud Center of Excellence (CCoE). מדובר בצוות מגוון שמטרתו היא להטמיע את המדיניות, המשמעת, הפרקטיקות המובילות, והארכיטקטורה הנדרשת בכדי לאמץ את טכנולוגיית הענן בדרך היעילה ביותר עבור ארגונים גדולים אחרים המעוניינים לעבור לענן.
משימה זו דורשת יכולות ביצוע גבוהות ומדויקות ביחד עם יצירתיות, בכדי ליצור ולחדש תהליכים מבוססי ענן, תוך שיפור של הליכים קיימים והימנעות מגורמים מגבילים בהליכים המסורתיים והקיימים.

ניתן להבין בקלות למה ארגונים רבים רוצים הדרכה לגבי הקמה ותפעול של CCoE משלהם, ויש שתי גישות מומלצות להגיע לתוצאה הרצויה: הראשונה היא הקמה של צוות חדש עם סט יכולות מגוונות מעולמות עקביים ופונקציונאליים שיכולות לסייע בהקמה של מודל ענן תפעולי. CCoE שנבנה בגישה זאת לרוב כולל נציגים מ-Ops של תשתיות, PMO, ארכיטקטורה ארגונית, App Dev, Infosec, Procurement ובקרת איכות.

הגישה השנייה היא למנף צוות מוביל ולהפיץ אותם מחדש כ-CCoE. בניגוד לגישה הראשונה בה יש צורך לגבש את הקבוצה ורק אז לפעול, התחלת עבודה עם הצוות המוביל שכבר מכיר את השותפים ויודע איך לעבוד יחדיו, תהיה מהירה וקלה יותר, וניתן יהיה לראות תוצאות תוך זמן קצר. גישה זו מתאימה יותר לארגונים גדולים שכבר הקימו צוותים העובדים עם מגוון מחלקות ומחזיקים בסט יכולות נרחב, ביחד עם יכולות פיתוח אגיליות.

איזו גישה עדיפה?

ישנו היגיון בשתי הגישות, ויש אינספור הוכחות לאפקטיביות של שתיהן בכל הנוגע לפעילות יעילה בארגון, אך מחקרים מצביעים שהדרך בה אנו מרכיבים את הקבוצות הנ"ל יכולה להשפיע לרעה על התוצאות שאנו מצפים לראות מתהליכים אלו. מחקרים אלו הניבו תוצאות אותן מיישמים כבר בסביבת העבודה המודרנית בכדי להקים צוותים מבוססי חדשנות (גם בענן), ונראה שהתוצאות עצמן מוצלחות. מידע מעניין נוסף – המסקנות התבססו על מחקר שבחן מה הופך מחזות זמר בברודווי למוצלחים, אך הקסם הוא להבין שמה שנכון עבור עיר המחזות, נכון גם עבור ארגונים גדולים.

החוקרים בריאן עוזי וג'ארט ספירו, למדו את יחסי הגומלין בין יוצרים (מלחינים, במאים, משוררים, כותבים, מפיקים וכו') מ-500 מחזות זמר שונים שהופקו בברודווי בין השנים 1945 ל-1989. באמצעות שימוש בקנה מידה שהתבסס על יחסי גומלין קודמים (שנקראו Q), החוקרים מצאו כי מחזות זמר בהם לא הייתה היכרות קודמת ועבודה משותפת (Q נמוך), נועדו לביצועים בינוניים ואף לכישלון. התמונה המפתיעה הציגה שגם במקרים בהם הצוותים הכירו אחד את השני ועבדו על מספר פרויקטים ביחד (Q גבוה), עדיין לא הייתה אינדיקציה מובטחת להצלחה. הנתון המעניין הציג, שצוותים בהם היה שילוב של מערכות יחסים קיימות וחדשות, היו בעלי סיכוי גדול פי 3 להצלחה. כלומר, אם תשמרו על איזון של אנשים שעבדו ביחד בעבר, ותצרפו אליהם אנשים חדשים לחלוטין – כנראה שתהיה לכם הפקה מוצלחת במיוחד. הסיבה לכך, היא שהאנשים הוותיקים יכלו לתרום רבות מהניסיון, הידע וההבנה שלהם בעקרונות התעשיה, אך האנשים החדשים הם אלו שהביאו איתם שפע של רעיונות חדשים ואנרגיה. עכשיו כשיש לנו את ההבנה ואנו יכולים ליישם אותה לגבי ארגונים, נשאלת שאלה – אילו אתגרים עומדים מולנו?

כשאנו מסתכלים על הגישה הראשונה, כיסינו את כל הנושאים המקצועיים שאנו צריכים בכדי להקים את הצוות הנדרש, אבל אנחנו בעצם נמצאים בקבוצה הראשונה במחקר, בה כולם היו חדשים אחד לשני. צוותים אלו צריכים להתאמץ יותר בכדי להביא תוצאות, וההתחלה שלהם קשה במיוחד ויש צורך להשקיע יותר בתיאום ובסנכרון שלהם. בהתחשב בעולם העסקי והטכנולוגי של היום, רוב הארגונים מעוניינים להשיג תוצאות טובות ומהר, ואין להם זמן או רצון לניסוי וטעייה.

הגישה השנייה מביאה לשולחן חברי צוות מנוסים המכירים האחד את השני, ולמרות שהם יכולים להתחיל להביא תוצאות מהיום הראשון, הרי שהסטטוס, וההצלחות שלהם מהעבר יכולים להיות בעוכריהם. הם יכולים לדוגמא, לצמצם את הזמן הנדרש מפרויקט ל-4 שבועות במקום 8 שבועות, אבל הם כנראה יעצרו בנקודה זו, יטפחו לעצמם על השכם ולא יחשבו על צמצום של אותו הזמן לשבועיים, שבוע, או אפילו מספר שעות בודדות. למה? מפני שהם עובדים כבר שנים עם מודלי עבודה ויחסי גומלין ספציפיים, המונעים מהם לבחון ולאמץ רעיונות חדשניים.

ב-2102, פרויקט מעניין במיוחד, הבין את מסקנות המחקר בברודווי ויישם אותו בהצלחה בפרויקט זה היה צורך להנהיג את צוות הענן הראשון בחברת Edmunds. המטרה הייתה להקים צוות חדש עם וותק והיכרות ברמות שונות, שיוכלו לייצר יעילות מחשבתית וביצועית חדשה. צוות מהנדסי התשתית הציג רשימת הישגים ענפה, הכוללת הקמת ענן פרטי עם פלטפורמת IaaS מבוססת Chef עם הספק אוטומטי. על פניו, נראה שהם היו הצוות המתאים ביותר למשימה.

למרות מה שהיה נראה לעין, ההחלטה שעמדה מאחורי הקמת הצוות, התבססה גם על פרמטרים מלבד שיפור המהירות באספקת והקמת השרתים, כמו שיפור הדרך בה אפליקציות ארכיטקטורה והפצה הועברו לענן. אותם פרמטרים של איך ניתן להשיג איזון בין יכולת הביצוע לבין חשיבה חדשנית, הובילו למפתחות העיקריים של הצלחה, שדרשו מאיתנו לחשוב יותר לעומק על תמהיל ה-CCoE בחברה.

ההחלטה הייתה ציוות לא קונבנציונאלי של מהנדסי התשתית המובילים והחברים הצעירים בצוות הבדיקות האוטומטיות. אמנם היה מדובר בהחלטה שאינה נפוצה בעולמות הענן המסורתיים, אך הזמן עבר וההחלטה הוכיחה את עצמה. בעוד הוותיקים בתשתית הביאו את הניסיון שלהם במערכות אוטומציה, מהנדסי התוכנה הכירו את האפליקציות טוב יותר מכל גורם אחר בחברה, ועל ידי הבנה זו היה קל להבין אלו אפליקציות היו מעולות, רעשניות או כאלו הדורשות תלותיות עדינה, ובכך מיפו מאות אפליקציות ארגוניות ופיתחו תכנית מואצת למעבר לענן, ביחד עם כלים ותהליכים עבור המעבר של אותן אפליקציות. כתוצאה מכך, החברה הצליחה לעבור לענן ולהפסיק את פעילות חוות השרתים האחרונה שלה כבר ב-2016.

השנים עברו ואיתן גם התובנות השונות לגבי הקמת צוותים למגוון מטרות, בין אם מדובר בפיתוח מוצרים ללקוחות קצה, או עבודות "מאחורי הקלעים", וישנם 2 קריטריונים עיקריים איתם מומלץ לעבוד:

1. מהי בעצם מטרת העל, ומיהם הבכירים או החברים בצוות שכבר עבדו יחדיו בשיתוף פעולה וברמה מספקת? סביר להניח שיש לכם כבר מספר שמות אשר יבטיחו שהתוצרים לא יהיו חובבניים.
2. מה חדש או שונה לגבי המטרה אותה מנסים להשיג, ומי יכול להציג פרספקטיבה שונה לגבי אותם אתגרים?

לסיכום

אין ספק שנקיטה בגישה זו יכולה לעורר מתחים ותחרותיות, אך בסופו של דבר, כדאי לעודד סביבה בה ניתן לצפות דברים כאלו מראש ולתעל אותם לטובת יצירתיות, ובכך להשיג תוצאות שהן מעבר למטרה פשוטה כמו גידול ארגוני. בשיטת פעולה, לאמצוותים אנשים אקראים יחדיו ומצפים שהכל יעבוד, אלא משלבים עובדים וותיקים בכדי לפתור את בעיית הביצועים הנמוכים בתחילת הדרך, אך עדיין לא מסתמכים על מודלים ישנים שלא בהכרח יעבדו, או יממשו רק חלק מהפוטנציאל.

ארגונים בוחרים להקים CCoE בכדי להתמקד במעבר לענן ולצפות ליציבות, אמינות וביצועים טובים ומהירים יותר, אך חשוב לזכור שהצוות אותו הם יקימו צריך לכלול את האיזון הנכון של יעילות תפעולית וחשיבה חדשנית, בכדי להשיג את היעדים הנדרשים בדרך הנכונה.


מאת: מערכת IsraelClouds

רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה

לפרטים נוספים ויצירת קשר עם נציג אורקל

תודה הודעתך התקבלה

הודעתך לא התקבלה - נסה שוב מאוחר יותר

הירשם לרשימת הדיוור של IsraelClouds

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

מילון מונחיםהשירותים שלנו תנאי שימושהרשמה לניוזלטרמדיניות פרטיות