רונאלדו או מסי? iPhone או גלקסי? קולה או פפסי?

איך לבנות נכון את גוף ה-IT -היררכי או מטריציוני?

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

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

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

אני מציע, כאמור, מבנה מטריציוני של שתי שכבות. השכבה הראשונה מפרידה בין Customer Facing לבין Delivery. את ניהול הקשר עם הלקוחות הפנימיים נכון שירכז גוף שזה ייעודו. במקרה של בזק – אגף "לקוחות ויישום". גוף זה כולל מנהלי לקוחות, בדרך כלל אדם אחד מול כל BU. תפקידם הוא להביא פנימה, ל-IT, הבנה עמוקה עם התהליכים העסקיים, הדרישות והצרכים של היחידה הארגונית, ומנגד להוות מולה את נקודת המגע המרכזית ב-IT ולהציג את האפשרויות והאילוצים. בנוסף, הגוף כולל את ה-PMO ואת קבוצת הארכיטקטורה והאינטגרציה, בעזרתם לבצע את ה-Strategic Gating (תעדוף עסקי), לבנות ולדחוף את תכנית העבודה של ה-IT  ליישום. לימים, התגבשה על בסיס הרעיון הזה תפיסת ה-BRM (ר"ת Business Relations Management). בעיניי נכון שגוף ה-BRM ישמש גם כרכז ומפעיל של תכנית העבודה. כך נוצרת רציפות וסגירות של התהליכים מצרכים למימוש.

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

אם בשאלות שבראש המאמר אין הכרעה, כאן לדעתי כבר יש…

תגובות

(0)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

אין לשלוח תגובות הכוללות דברי הסתה, דיבה, וסגנון החורג מהטעם הטוב

אירועים קרובים