STKI Market Pulse – עדכונים מהירים על קצה המזלג:

מיהו ה- CTO החדש?

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

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

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

שימוש במוצרי BI במודל קוד פתוח

לאחרונה קיבלנו כמה פניות מארגונים ששוקלים שימוש בכלי BI קוד פתוח. המניע לשאלות אלה בתחום ה-BI ספציפית הנו ברובו הגדול של המקרים בו אנו נתקלים – חיסכון בעלויות רישוי. חלק מהארגונים מעוניינים להרחיב משמעותית את השימוש בשירותי BI אל מעבר למשתמשי ה-BI הקלאסיים (כיום % משתמשי ה-BI עומד על כ-30% מכלל העובדים), לשותפים חיצוניים או ללקוחות. במקרה זה, ה Business case של שימוש במוצרי קוד פתוח הנו ברור. כאשר בוחנים כלי BI קוד פתוח, מעניין לראות כי בתחום זה ספציפית, כל שלושת המוצרים הבולטים נרכשו על ידי חברות טכנולוגיות:

  • Pentaho – אשר נרכשה לפני מספר חודשים על ידי HDS במטרה המוצהרת להיכנס לתחום האנליטיקה ב-IoT analytics
  • JasperReport – נקנו על ידי Tibco
  • BIRT – חלק מ Eclipse, נדחף על ידי Actuate- כיום חלק מ-Open Text.

רוב השימוש בכלים אלה עד כה הנו לחברות טכנולוגיות המעוניינות לפתח רכיבי BI ולשלבם בתוך האפליקציות שלהם אותן הן מוכרות לשוק (Embedded BI). אולם מודלי הרישוי – המאפשרים גישה למסה של משתמשים, הרבה יותר מותאמים ל Customer facing BI מאשר אלה של רוב ספקי ה-BI המסורתיים. כתוצאה מכך, אנו צופים שארגונים אשר יהיו מעוניינים להציע שירותי BI אל מחוץ לגבולות הארגון יבחנו ברצינות מודל קוד פתוח. ייתכן והדבר יוביל בסופו של דבר לרצון לממש כלי קוד פתוח גם לשימוש של BI פנים ארגוני לעובדים (אך כיום ובעתיד הנראה לעין אנו לא רואים מגמה כזו בארגוני Enterprise).

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

שורה תחתונה: פתרונות במודל קוד פתוח בתחום ה-BI מהוות אלטרנטיבה טובה אשר ראוי לבחון ב use case של שימוש חיצוני כלפי שותפים/ ספקים / לקוחות הארגון, אך יש להיערך לנושא התמיכה ולוודא כי יש גישה לידע הנדרש, בין אם בהתארגנות פנימית או בהסתמכות על כ"א חיצוני.

ניהול סיכוני טכנולוגיות המידע

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

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

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

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

מודעות פרסומת
STKI Market Pulse – עדכונים מהירים על קצה המזלג: