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

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

הקו המנחה הכללי בהטמעת טכנולוגיות חדשות בהקשר של מבנה ארגוני הוא: לא לפצל אחריות.

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

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

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

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

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

נקודה נוספת היא ריבוי טכנולוגיות. מאז ומתמיד קיים הקונפליקט של "אחידות טכנולוגית" אל מול "שימוש בטכנולוגיות מגוונות". כעת, ישנו יתרון מסוים ל"גיוון" לעומת כפיית אחידות. בתחום הפיתוח מקובל לדבר על “polyglot” – פיתוח פרויקט במספר שפות במקביל. אנחנו צופים שמגמה זו תחדור גם לתחום התשתיות ואין מן המנע שנראה מצב בו "צוות ה- DATA" משתמש בכלי אוטומציה A ו"צוות שרתים" משתמש בכלי אוטומציה B, כאשר שני הכלים נתמכים על ידי "צוות האוטומציה" (מובן שרצוי שכולם ישתמשו באותו כלי – אולם בגלל ההתמחות של הכלים לא תמיד הדבר אפשרי וכעת יש יותר פתיחות לשימוש במספר כלים).

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

מגמות עיקריות ל-2016

שנת 2016 תעסוק בעיקר בארגון הדיגיטלי

ארגונים כיום מרכזים את רוב תשומת הלב ב"טרנספורמציה הדיגיטלית". המסר המגיע היישר מההנהלה הבכירה מחלחל לארגון כולו. אנו משוחחים עם מנמ"רים אשר קיבלו השנה שאלה מהמנכ"לים (אשר קיבלו אותה ממועצת המנהלים) והיא: מהי האסטרטגיה של הארגון בנושא הטרנספורמציה הדיגיטלית? מהי הטקטיקה? מה הארגון עושה על מנת להיערך לנושא? כל מחלקה – מערכות מידע, שיווק, שירות… נערכת על מנת לספק תשובה לשאלה זו. אך האם זה באמת "נושא" שצריך להיערך אליו? האם טרנספורמציה דיגיטלית משמעותה שיפור של הקיים (שירות יותר טוב, שיפור חויית הלקוח באמצעים דיגיטלים? שיפור חווית העובד?) או האם מדובר במהלך שאמור "להפוך את הארגון על פיו" ולהציג מודלים עסקיים חדשים לחלוטין? (Digital Innovation?) האם מדובר במהלך שאמור לשנות תעשיות שלמות? (Disruptive digital innovation)? עם שאלות אלה ארגונים כיום מתחילים להתמודד, כמו גם שאלות פרקטיות נוספות כגון – כיצד אנחנו במערכות מידע אמורים לשנות את ההתנהלות, מבנה ארגוני, תהליכי ושיטות עבודה שלנו? מהן המשמעויות היומיומיות של "להיות ארגון דיגיטלי"?

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

התארגנות מחודשת לטובת אימוץ טכנולוגיות חדשות

המסרים המגיעים מהגורמים העסקיים המדברים על "טרנספורמציה דיגיטלית" מחלחלים גם לגורמי התפעול אשר נמצאים כעת בעיצומה של התארגנות מחודשת לטובת אימוץ הטכנולוגיות החדשות אשר מאפשרות את הטרנספורמציה הדיגיטלית. החל מיישום טכנולוגיות המאפשרות פתרונות IOT, יישום מתודולוגיות פיתוח מבוססות microservices והשקעה מחודשת באוטומציה של בדיקות שהנן תנאי הכרחי ליישום Devops מתקדם. במקביל, ארגונים מחפשים את האזורים בהם ניתן ליישם ענן ציבורי וכמו כן בארגונים גדולים ישנם צעדים ראשונים של יישום ענן פנימי ורמות מתקדמות של וירטואליזציה כגון sdn (network)  , sds (storage) ואוטומציה. אפשרויות חסכון נבחנות על ידי העברת פתרונות לקוד פתוח ומעבר לתחזוקת תוכנה צד שלישי.

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

צעד חשוב נוסף הוא לכמת באופן ברור (עד כמה שאפשר) את המטרות מיישום הטכנולוגיות החדשות. מה בדיוק רוצים להשיג ממתודולוגיית Devops? כיצד SDN  תייעל ותשפר את תפעול וגמישות הרשת? וכד'.

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

The Internet of Things

We’ve seen a wave of mobile devices and wearables stream into the workplace, each offering a new potential inroad for a cybercriminal, but the Internet of Things represents another looming threat. As connectivity spreads into every corner of our lives and businesses, it becomes more and more challenging to maintain a clear view of entry points and data flow.

The IoT may herald some exciting business opportunities, but we must be mindful about ensuring that access is limited and secure. Sensitive data should be encrypted, access must be restricted, and oversight is needed. It’s important to be able to manage and block access to enterprise devices and networks when necessary.

Bottom line: If you expect to enjoy success in 2016, and you want to ensure that your plans aren’t derailed, then make sure that these cybersecurity trends are on your radar.

הגל הבא של ניהול IT

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

תפקיד המטה של IT ישתנה גם הוא. בנוסף לטיפול ברגולציה, תיעדוף דרישות, ניהול משאבים וכ"ד IT  חייב לתת מענה מהיר ויעיל של כוח מחשוב הנדרש ללקוחות העסקיים בכל רגע נתון לפי הצורך. חלק מהארגונים כבר בנו תפקיד BRM – Business Relationship Manager, אשר יעבור בצמוד לחטיבות העסקיות, יישמע את קולם וכאבם, יציע פתרונות, יכניס חדשנות טכנולוגית ובמקום להסביר למה פרויקט לא יכול לצאת לפועל יענה בצורה מידית על הצורך העסקי.

ככל שה- IT יבין מהר יותר, כי בזכות המודל הענן המון מוצרי ה- IT הקלאסיים הופכו ל-commodity, הוא יבין שאם ביזנס לא יהיה שבע רצון מהשירות של IT, הוא יכול, במינימום מאמץ, לרכוש שרת באמזון. IT  חייב למצוא את דרכו במציאות חדשה ולמצוא את הערך המוסף שהוא יכול לתת ללקוחות. בעיקר IT חייב לבנות מומחיות (skills) חדשה, אשר בצמוד ל- Office of the CIO, תבחן כל דרישה עסקית בעיניים של טכנולוגיות חדשות: האם נכון שהפרויקט החדש יפותח על – Open source, ענן – ואם כן, אז איזה (אמזון/ מיקרוסופט/ גוגל), במתוד' agile/DevOps/ microservices , וכ"ד

שורה תחתונה: IT governance v2.0 חייב לצאת לדרך. IT  לא יכול יותר להרשות לעצמו להווה צוואר הבקבוק הארגוני לכוח מחשוב. מטה IT חייב לבחון מחדש את הרלוונטיות של מבנה ארגוני, שיטות וכלי ניהול, ומתודולוגיות הקיימות ב IT.

 

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 מצליח לתקשר את הזיקה בין סיכוני טכנולוגיות המידע, לבין פגיעה פוטנציאלית ביעדים העסקיים של הארגון.