אולם בארגונים גדולים ישנה דילמה גדולה. האם לחלק את צוות התשתיות לפי משימה תפעולית (תפעול למול בנייה), האם לחלק לפי טכנולוגיה, האם לחלק לפי צמידות לעסק (LOB ) וכד'. מדובר על חלוקה ארגונית ראשית וגם משנית. לדוגמה בצוות windows גדול- כייצד יחולקו הפעילויות.
בטבלה זו ריכזתי מספר אפשרויות לחלוקה תוך התייחסות ליתרונות, לחסרונות וספציפית לאפשרות להקטין את זמני הסבב - נקודה כואבת ביותר בארגונים גדולים.
| צורת חלוקה | יתרונות | חסרונות | סיכוי לשיפור time to market |
| תפעול, בנייה, חזון. (run, build, grow) התפעול אמור לכלול גם בנייה של רכיבים סטנדרטיים. בנייה זה דברים לא סטנדרטיים כמו "שדרוג ל- exchange 2010 או כניסה ל- FCOE" | קל לשים SLA על תחזוקה שוטפת\תקלות. | מתח בין תפעול לבנייה. כאשר בנייה מכניסים לייצור דברים לא בשלים. כפילות מסויימת כי ידע צריך להמצא גם ב- RUN וגם ב- BUILD | סיכוי טוב - במידה וצוות התפעול אחראי לפעולות הסטנדרטיות (הקמת שרת, וכד'). |
| לפי טכנולוגיה – אחסון, win לינוקס, VMWARE | מתאים כאשר הטכנולוגיות מופרדות ושונות. יתרון של התמחות בתחום. | סיכוי לשמוע "זה לא אצלי" - בעיית אינטגרציה | קל להגיע למקצועיות |
| לפי סוג מערכת\LOB כלומר כל המערכות של תחום X | אחריות מקצה אל קצה. לא נופלים דברים בין הכסאות. היכרות טובה עם המערכת ועם הצרכים העסקיים | סיכוי טוב לחוסר סטנדרטיים ולאחר מכן מאוד קשה לבצע פרוייקטים רוחביים. | מוריד את "זמן התקשורת" בין גוף לגוף. |
| לפי משימה רוחבית: התקנות, שדרוגים, בדיקות, שיפור ביצועים, DRP | התמקצעות במשימה. ככל שהמשימה דומה בטכנולוגיות השונות (DRP ללינוקס WIN ואחסון) | סיכוי לשמוע "זה לא אצלי" – בעיות אינטגרציה | במידה ויש סוג משימה בעייתי – צורה זו גורמת להתמקצעות מירבית |
| לפי סביבות – ייצור, בדיקות, פיתוח | התמקצעות בסביבה. פחות שומעים "זה לא אצלי" – סיכוי לאיכות טובה יותר כי כל צוות בודק את מה שהוא מקבל | כפילות מסויימת | מדידה של כל שלב – לכן יש סיכוי לשיפור |
אין תגובות:
הוסף רשומת תגובה