"הוא לא סתם ארכיטקט הוא באמת עוזר"

(על תפקיד הCTO  בארגון)

לתפקיד הChief Technology Officer  בארגון יש הרבה שמות, לפעמים מוגדר תפקיד "רשמי" שכזה בשם CTO, לפעמים קוראים לזה מנהל אגף/מחלקה ארכיטקטורה אבל בהרבה מובנים כל התפקידים האלה מתמקדים באותה עשייה. אם בוחנים מלמעלה את תפקידי משרד ה CTO נראה כי הוא מורכב משלושה תחומי פעילות – ארכיטקטורת מערכות מידע, תוכנית מחשוב רב שנתית, וחדשנות.  

ארכיטקטורה פרגמטית...

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

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

תוכנית מחשוב רב-שנתית...

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

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

"חדשנות או למות"...

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