לעשות יוותר Do more

לפי ממספר שבועות קיימנו באילת את כנס המנהלים השנתי שלנו בשיתוף חברת נספרו. בכנס סקרנו מגמות חשובות הרלוונטיות לעולם מערכות המידע כמו גם המלצנו ללקוחות לשנס מותניים ולהכנס לעולמות חדשים וביניהם - הכנסה של מכשירי tablet לשימוש שותף בארגון, פיתוח אפליקציות שירוצו בסביבת native במכשירים סלולרים חכמים, כניסה לעולם ה- big data ועוד עוד.

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

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

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

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

דוגמה נוספת היא צימצום תהליכים. לדוגמה אם בזמנו הוגדרו ג'ובים שונים של גיבוי לפי טווח הזמן שיש לשמור את הקלטות, כיום בגלל שימוש ב- vtl dedup ניתן לאחד ג'ובים שונים ובכך להוריד ממשימת תפעול סביבת הגיבוי. כלומר ככל שמכניסים טכנולוגיות חדשות חיבים במקביל להוריד טכנולוגיות ותהליכים קיימים כל זאת במטרה להיות כמה שיותר סטנדרטיים וכמה שיותר שירותיים מלשון service oriented infrastructure.

מעבר לכך פעילויות של enterprise architecture ובמקביל agile ו- lean it אמורים גם הם אמורים לסייע בהורדת משימות התפעול.

הפער- The Gap

הנושא המרכזי במצגת שלי בכנס השנתי הוא הפער ההולך וגדל לדעתי בין ארגוני ה- IT והמשתמשים הארגוניים לבין הטכנולוגיות שנמצאות מחוץ לעולם זה. לבקשת לקוחות אני מעלה את עקרי הדברים בכתב.
טכנולוגיות שנמצאות בשימוש על ידי NITU – none IT technology users. במצגת שנמצאת בלינק הבא והחל משקף 10 תארתי מספר מימדים מתבטע פער זה כאשר פער זה גודל במהלך השנים ואינו קטן!
לפני מספר שנים ארגוני ה- IT רכשו מחשבי Tier 1 לעומת ה- NITU אשר רכשו Non-Brands, ארגוני ה- IT הגנו על עצמם ב-3 מעטפות אבטחת מידע וה- NITU הסתפקו בשכבה אחת. באופן כללי ה- NITU ניסו לחכות את הפעילות בארגוני ה- IT תוך שימוש במשאבים מצומצמים יותר. אולם כעת התמונה השתנתה באופן דרמתי וה- NITU מוליכים את חזית השימוש בטכנולוגיות. לדוגמה:

• ארגוני ה- IT כמעט ולא משתמשים במחשבי MAC כאשר מחוץ ל- IT יש שימוש נרחב במחשבי MAC.
• ארגוני ה- IT רוכשים את המחשבים עבור המשתמשים שלהם כאשר מחוץ ל- IT ישנה תופעה של BOYPC – Bring Your Own PC – המשתמשים משתמשים במחשבים הביתיים שלהם לצורך הפעילות העסקות.
• ארגוני ה- IT (ולקוחותיהם) משתמשים לתקשורת רק ב- MAIL כאשר מחוץ ל- IT יש שימוש גם ברשתות חברתיות כמנגנון לתקשורת. גם במידה והארגונים מכניסים שימוש ברשתות חברתיות הנושא מטופל ברוב המקרים במחלקת השיווק ולא באחריות ה- IT.
• ארגוני IT נותנים שירותים בתצורה של On-Line ו- Batch כאשר מחוץ ל- IT יש שימוש ב- On-Line בלבד.
• ארגוני ה- IT אינם משתמשים בתוכנות חינמיות או תוכנות Open Source (בהקשר זה של שימוש ללא תשלום Redhat לדוגמא אינם נחשבים כ- Open Source כאשר מחוץ ל- IT יש שימוש נרחב בתוכנות מסוג זה.
• ארגוני ה- IT מקיימים תהליכי החלטות מסורתיים הררכיים כאשר מחוץ ל- IT יש שימוש נרחב ב- Crowdsourcing – רתימת העובדים והלקוחות בצורה בלתי אמצעית לקבלת החלטות מרכזיות.
• ה- NITU משתמשים בשירותים ציבוריים בענן (SAAS PAAS IAAS) בצורה הרבה יותר נרחבת מאשר ארגוני ה- IT הסטנדרטיים.

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

בעיות בפרוייקט IT

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

1. הלך רוח של המשתמשים המובילים שעיקרו "אם כבר מבצעים פרוייקט אז...". כלומר ניצול הפרוייקט הנוכחי לבעור "כל עוולות העולם".
2. דרישה לפונקציונליות מקסימלית בעדיפות על לוחות זמנים. משהו כמו "הכל חשוב הכל דחוף הכל עכשיו". כמעט ללא מוכנות לוותר על פונקציונליות בכדי לעמוד בלוחות זמנים.
3. דרישה לפתרון ייחודי – כתפיסת עולם – ללא עדיפות לתהליכים ופתרונות קיימים או מוצעים על ידי החבילה או המפתחים.
4. נקודה חשובה ביותר שעשוייה לתקן את הגורמים שציינוו קודם - זמינות של business leaders. אותו business leader צריך לוודא שהרפרנט המקצועי מטעמו לא יפול למלכודות שציינו מקודם ובמידה וכן - להחליפו במהירות.
   
5. זמינות מיישמים ומפתחים. מדובר בקושי אשר במקרים רבים ניתן לפתרון.
6. סיכון חוצה חברות – ביצוע פרוייקטים משיקים. המשמעיות בסיכון זה היא שפרוייקט אחד מתבצע ללא ידיעה מוחלטת כיצד הפרוייקט השני ישפיע על התהליכים העסקיים המשותפים.
7. הסבה טיוב נתונים. טיוב נתונים היא ה"כביסה המלוכלכת" של הארגון. נושא שאף אחד לא רוצה להכנס עליו בצורה משמעותית מכיוון שמדובר על תהליך עתיר משאבים שמחצין יריבויות בין היחידות העסקיות השונות בארגון.
8. מוכנות ארגונית – בתוך זה הטמעה לא מספיקה, דרישות לא מדוייקות, פתרון: צוות משאבי אנוש, צוות שינוי. לוקחים מוביל עסקי מהחברה כמוביל.
9. תקלות בניהול והגדרת הרשאות
10. מבנה והגדרת תפקידים לא ברורים במנהלת הפרוייקטים. מיקום חברי הצוות של הפרוייקט– פיזור אנשי הפרוייקט בתחומים שונים פוגע בתאום בין הצוותים . כלומר כדאי לרכז אנשים לפרוייקטים.
    
11. אי הסכמות והפתעות בנושאי עלויות וחיובים במהלך פרוייקטים מול שינויים ותוספות נדרשים.

לסיכום - גזור ושמור. בכל פרוייקט יש לעבור על נקודות אלו פעם בשבוע לפחות!

תמחור פנימי - תמונת מצב IT Chargeback

לקוחות רבים שואלים את עצמם לגבי תמחור פנימי לפעולות IT (הכוונה ל- IT Charge-back). אולם בסופו של דבר מסתבר שרובם המכריע של ארגוני ה- IT בישראל אינם מבצעים נכון להיום תמחור פנימי.
גם אותם הארגונים אשר כן מבצעים תמחור כזה מודים שמדובר בתחשיב חסר שאינו משקף בצורה טובה את המציאות. המתודולוגיה היא לקחת את העלויות הישירות (אגב, בד"כ ללא שכר של עובדי החברה) בתוספת אחוזים מסויימים 20% עד 50%.
לדוגמה, אחד הלקוחות מתמחר נכון להיום מכונה וירטואלית ב- 3.5K$. התמחור כולל את הקמת המכונה, מכונת DRP , תשתית גיבוי, שליטה ובקרה, אנטיוירוס וכד', ותמיכה שוטפת (כלומר לא צריך להוסיף כסף בשנה הבאה) אבל אם יצרכו להוסיף זיכרון , להעביר למחשב חזק יותר – הלקוח ידרש לתוספת תקציב. דוגמה זו לא כוללת תמחור של אחסון המתומחר בצורה נפרדת.
ישנם מקרים שבהם יש תמחור מורכב יותר – לדוגמה בחברת תקשורת, יש תמחור די מסובך ל- call center המורכב מעלויות משתנות- עמדת הקצה, תוכנות וכד', וגם עלויות קבועות- תשתית חשמל, תקשורת, שרתים וכד'. לטענת הלקוח – מודל שכבר לא עדכני אבל "זה מה יש".
על פי בדיקה שקיימנו לאחרונה מסתבר שרובם המכריע של הלקוחות משתמשים ב- EXCEL ולא בתוכנה או כלי יעודיים. יש לקוחות שמקווים שיישום CMDB יסיייע במשימה זו אולם עד לרגע זה לא הצלחנו לאתר לקוחות בישראל שמשתמשים ביישום CMDB לבצוע תמחור בפועל.
אנו מניחים שככל שתפיסת הענן תבשיל, הן הענן החיצוני אשר בו מדובר על תשלום בפועל והן הענן כלים וטכנולוגיות בתחום הענן הפנימי ששם אפשרות לביצוע charge back היא חלק מובנה מהפתרון, יותר ויותר ארגונים יבצעו תמחור מסוג זה שעשוי גם לשפר את יעילות גוף ה- IT.

מדידת מרכזי שליטה ובקרה NOC metrics

מדידה והערכה של גוף ה- NOC \ מרכז התפעול היא משימה קשה. זאת עקב העובדה שבמובן מסויים לגוף ה- NOC עצמו אין ממש שליטה על פעולותיו.
במונח NOC התכוונה כאן Network Operation Center כלומר ל-"חדר המחשב" או "הפעלה" או "מפעילים" או "הגשר" או "תפעול", כלומר הגוף אשר נמצא 7*24, מקורו בהרבה ארגונים במפעילי ה- MF. תפקיד גוף זה לדאוג לפקח על פעולת ה"ייצור" בארגון ה- IT ובמידה ויש תקלה לטפל בה. במידת האפשר בעצמו ואם לא להפעיל את הגורמים המתאימים.כלומר לא מדובר רק על תחום התקשורת.

כאמור חלק מהמדדים כאן הם מדדים שמתאימים רק ל- NOC וחלק מהמדדים הנם מדדים שמתאימים גם לגופים אחרים ב- IT.


פעולות ה- NOC מתחלקות (באופן גס) ל:
1. טיפול בתקלות – CASES – בד"כ לפי נוהל שהוגדר מראש ב- Run Book - ההוראות למפעילים.
2. ביצוע משימות עזר שוטפות – TASKS - (לדוגמה, מעבר על LOGS לוודא שגיבוי התבצע כשורה, התקנת PATCH של WIN על רשימה של שרתים).
בשני המקרים מי שמגדיר ל- NOC את הפעולות לביצוע הוא גוף התשתיות ולכן גם אם יש NOC נהדר לפעמים מדידת גוף זה תתן תוצאות לא טובות – זאת בגלל שגוף התשתיות לא העביר מספיק משימות\אחריות ל- NOC.

להלן מספר רעיונות\הצעות למדידה והערכה של ה- NOC ועובדיו:

1. מדדי זמינות וביצועים – לווא דווקא קשורים ספציפית ל- NOC

• זמינות המערכות. גם תשתיות וגם שירותים תוך התייחסות ל- SLA (זמינות שהובטחה ללקוחות הסופיים) ו- OLA – operation level agreement (זמינות שהובטחה בתוך הארגון בין הגופים השונים– לדוגמה OLA של סביבת האחסון).
• מדידת ביצועי מערכות (זמני תגובה של האפליקציות)
• כמה זמן עבר עד לתיקון התקלה (אפילו אם טופלה מחוץ ל- NOC ) – time to repair.
• d. Monitoring coverage - כמה מהתקלות התגלו על ידי מערכות השליטה והבקרה וכמה על ידי המשתמשים הסופיים.

2. מדדים לכמות ואיכות הטיפול ב- CASES על ידי ה- NOC

• מתוך הזמן לטיפול בתקלה (MTTR) איזה חלק מהזמן היה בטיפול של ה- NOC.
• % סגירה ב- NOC. כלומר איזה אחוז מהקריאות נסגרו ב- NOC ללא צורך להפעיל גורמים חיצוניים.
• יש ארגונים שבהם ה-NOC לוקח שליטה על עבודת HD בשעות הלילה אז נכלל פה גם מדידות HD. כמו כמות תקלות שלא נפתרו והועברו לצוות PC ללא צורך להגיע ללקוח. (שיפור הידע)
• כמה זמן מאז שהתרחשה התקלה ה- NOC התחיל לטפל (ערנות).
• כמות תקלות שנבעו מטעיות ב-NOC (בד"כ טעויות אנוש)
• איכות ה- follow up של תקלות שנפתחו במשמרת. עד כמה עוקבים אחרי התקלות בתדירות רצוייה.

3. איכות כללית של ה- NOC

• תהליך של incident מול problem. כמה פעמים ה-NOC או התומך מצאו דרך למנוע את התקלה בפעם הבאה (על ידי פעולות פרואקטיביות) או לגלות את התקלה בצורה מהירה יותר.
• עד כמה מבצע את הפעולות השוטפות (TASKS) בצורה טובה.
• איכות התעוד גם מבחינת פרטים וגם בהיבט של מועד עדכון המערכת (הזנת הפרטים בזמן הקריאה ולא בסוף המשמרת).
• איכות ה"אסקלציה" (התקשורת) – עד כמה התקשורת שבצע ה- NOC (בדרך כלל ה- MAIL ששלח או הודעות SMS ) הייתה מתאימה מבחינת בהירות המסר וניסוחו, סוג הנמענים, תוך כמה זמן התבצעה התקשורת וכד'.
• תמיכה בתהליכים חדשים (בתקופה מסויימת) ועד כמה התהליכים נקלטו בצורה טובה על ידי ה- NOC
• עד כמה צוות ה- NOC מעורב בתהליך של capacity planning בארגון והאם בצע מעקב בצורה טובה (לדוגמא התריעה מספיק זמן שהאחסון מתמלא).

4. איכות ה- run book ,ביצועו ואטומציה

• אחוז כיסוי ב- run book. לכמה מהתקלות שהתרחשו בתקופה יש run book
• עד כמה ה- run book מלא (מטפל בכל ההיבטים והאינפוטים של התקלה).
• כמה מה- run books מוטפלים בצורה אוטומטית (מדד נוסף בתחום זה – ניסויים ל- run book האוטומטיים).
• עבודה לפי run book – עד כמה ה- CASE טופל בצורה מלאה לפי מה שמופיע ב- run book.

בסיס ל- Enterprise Architecture

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


מהם הכלים לשימוש בפרויקטי EA?
שימוש בכלים תלוי במטרה של ה- EA. האם הכוונה ב- EA להיות עזר לניהול התקציב או להיות לעזר בבניית אפליקציות על ידי הגדרה של patterns וכד'. אבל אם מדברים רק על EA בסיסי שאמור לתת inventory של הטכנולוגיות שבשימוש בארגון הרי שישנם ארגונים אשר מתחילים ב- Excel ואז ניתן להגדיר סטנדרטים של טכנולוגיות ולעקוב אחר יישומים. במקביל ישנם ארגונים רבים אחרים אשר בכל זאת מתחילים במודולים בסיסיים של כלי EA. דוגמה לכלי פופולארי היא TROUX שחקנים נוספים הם IBM , IDS SCHEER (כיום חלק מ- softwareAG), MEGA, METASTORM ואחרים.
הסיבה לשימוש בכלים בכל זאת היא הרצון להגדיר קשרים בצורה נוחה. הגדרה כזו תאפשר ל-EA לענות על שאלות מורכבות יותר כגון "לאיזה מערכות מהווה השרת X כ- fail over ומה המשמעות של עדכון גרסה של מערכת ההפעלה שלו". במקביל המענה של הכלים לשאלות בסיסיות כגון "במידה ומוציאים משרות את מערכת X כמה שרתים זה יחסוך" יהיה בהיר יותר ומתאים יותר למנהלים. כמו כן הכלים יאפשרו הזנת נתונים בצורה נוחה גם דרך ממשק WEB וגם דרך קבלת מידע ממקורות שכבר קיימים בארגון כגון מערכות שליטה ובקרה. הכלים מאפשרים גם להתייחס ל- roadmap טכנולוגיה ולבדוק מה הם הפערים בין המצב הנוכחי למצב הרצוי- כל זאת בצורה נוחה. לסיכום, במידה וה- EA הנה תוכנית חשובה של ה-IT אז מומלץ להתחיל בכלים. במידה ורוצים "לטעום" את מהות ה- EA ה- Excel מספיק בהחלט וניתן יהיה להעביר את המידע בעת הצורך לכלים.

 
עד איזה אמת פירוט צריכה להגיע תוכנת ה- EA?
בדרך כלל ה- inventory צריך לכלול מידע מפורט כולל רמת ה- Service Pack. אבל לגבי גרסאות DLL מקובל לשמור מידע ספציפי רק אם הם מיוחדות ומהוות שירות ספציפי. ניתן להתחיל בגרסאות ראשיות ולאחר מכן לרדת לפרטים במידה וצריך.

באיזה תהליכים בארגון ה- IT צוות ה- EA אמור להיות מעורב?
תלוי ברמת הבשלות (maturity level) של צוות ה- EA.
ברמה הבסיסית צוות ה- EA אחראי על התמונה הכוללת של הטכנולוגיות של הארגון. ולכן הוא צריך להיות אחראי על הסטנדרטים הטכנולוגיים ולהיות מעורב בהחלטות טכנולגיות של כל מערכת בשלב ה-design. כלומר בדרך כלל צוות ה-EA יהיה מעורב בשלב הקונספטואלי של ה- design ולאחר שיתבצע תכנון מפורט של המערכת על ידי צוות הפרוייקט, צוות ה- EA יאשר את התכנון.
עם הזמן כאשר תחום ה- EA מבשיל, מתגבשים בתוך צוות ה- EA מספר תפקידים או תחומי אחריות:

• Business Architecture – אשר מחזיק מידע על תהליכים עסקיים בארגון והנו שותף לקביעת תהליכים עסקיים אלו תוך ראייה כוללת של תמיכת ה- IT בכלל התהליכים העסקיים.
• Information Architecture – אשר מחזיק מידע על פרטי המידע בארגון. הוא יכול לענות לדוגמה על השאלה "באיזה מערכות ואיפה נמצא המידע על הלקוחות של הארגון".
• Application Architecture – אשר מחזיק במידע יותר מפורט מה- Business Architecture על הטיפול של האפליקציות השונות בתהליכים העסקיים והממשקים בינהם.
• Technology Architecture – אשר מחזיק מידע על הטכנולוגיות השונות (שזה השלב ההתחלתי של ה- EA).

ארגוני EA כיום מטמיעים תפיסה של SOA תוך התייחסות לשירותים בשתי רמות. רמה של Foundation Technology - כגון אבטחה, שרתים וכד'. ורמה של High Level Services כגון "מכירות" "לקוחות" וכד'.


האם מקובל לכלול ב- EA מידע על תהליכי IT בארגון (לדוגמה "נוהל שחזור") ומידע על האנשים והפונקציות ב- IT (לדוגמה מי הם מתכנתי Natural)?
ישנם ארגונים אשר כוללים במסגרת ה- EA מידע זה אך ברוב המקרים אין התייחסות למידע זה מכיוון שמידע על תהלכים נמצא ברמה טובה בגופי התפעול השונים כולל התייחסות לאנשים. המידע שכן נכלל בדרך כל ב- EA ומתקבל מהתפעול הנו רמת השירות (Service Level)של המערכות וזאת בכדי שניתן יהיה לקבל מידע על מידת הזמינות של המערכות.

דוגמאות בהם ה- EA משפר את קבלת ההחלטות \ כיצד להצדיק EA \ דוגמאות לתוצרים של EA?
כבר הרמה הבסיסית של inventory חוסכת לארגונים כסף רב. לדוגמה, ארגון אשר הטמיע EA לאחרונה גילה שיש לו 250 (!!!) קומבינציות של Oracle (עם חומרה ומערכת הפעלה ספציפית) שמחייבות התייחסות תחזוקתית נפרדת והפעלת patches ומנגנוני בדיקה. ארגון זה הוריד את מספר הקומבינציות של Oracle בהדרגה תוך מהלכי עדכון מתוכננים ל- 12.
ארגון אשר הטמיע EA בסיסי גילה שיש לו מספר מערכות BEA אשר משמשות לצרכים שונים (LOB שונים) אשר יכולות לרוץ על אותו שרת ובכך הורידו את מספר השרתים בארגון.
ארגון פיננסי אשר הטמיע EA גילה שיש לו 3 אפליקציות אשר מבצעות את אותה פעולה -credit card validation ! החסכון במקרה זה היה מיידי.
כאשר מביאים אפליקציה חדשה לארגון הגוף היחיד בארגון שיכול לתת תשובה אמיתית ומהירה לשאלה "מה משמעות הטמעת המערכת החדשה" הוא גוף ה- EA. זאת מכיוון שגוף ה- EA הנו הגוף היחידי שמכיר את כל הטכנולוגיות בארגון וכיווני ההתפתחות שלהם וכמו כן את צורת ההתממשקות. ניתן לחילופין לשאול כל גוף טכנולוגי בארגון בנפרד – תשתיות, תקשורת, אינטגרציה, אבטחת מידע וכד'. אולם כל גוף זה יתן רק את הפרספטיבה שלו ללא ניתנה של סדר עדיפויות וגם תהליך כזה ייקח המון זמן.
במידה והארגון כבר מימש SOA ה-EA עוזר לזהות איזה שירותים כבר קיימים בארגון ואיך לבנות את השירותים כך שיתנו מענה לכמה שיותר צרכים.
במידה ויש EA בוגר אשר גם מכיל מידע אל האפליקציות ועל העלויות, אזי ה- EA משמש ככלי בניהול התקציב. ישנם מקרים רבים בהם ה-EA "גילה" לארגון שהוא משקיע תקציב רב במערכת שמשמשת למספר לא רב של משתמשים. בדרך כלל מצב כזה קורה כאשר פעם מערכת אכן הייתה קריטית אבל היא כבר הוחלפה ברוב הפונקציונליות שלה אבל בכל זאת משאירים אותה בשביל מספר פונקציות שאינן נתמכות במערכת החדשה וממשיכים לקצב את האפליקציה הישנה. במקרים כאלו ה- EA עזר לחשוף את העיוות.
כאשר ישנה תוכנית EA בוגרת, ישנו שיפור בתהליכים העסקיים ותיעול הזדמנויות עסקיות אשר מתגלות על ידי ה- EA. כמו גם הארגון מבצע שינויים בצורה מהירה יותר. כלומר יש תרומה ל- business agility.
כאשר ישנה תוכנית EA בוגרת שמממשת SOA, מראים להנהלה מדי פעם איזה אפליקציות חדשות הוקמו על בסיס שירותים שכבר קיימים.

מספר המלצות להתחלה של EA
במקרים רבים צוות ה-EA דואג לאיסוף המידע הראשוני בצורה ידנית וגם בצורה של גזירה מנתונים קיימים (דוגמה ממערכות שליטה ובקרה).
במידה ויש חלקים בארגון שמתנגדים במיוחד ל- EA – יש להשאיר אותם לסוף לאחר שכבר נאסף מידע בארגון.
ניתן גם לבצע pilot של EA – בנייה של EA אבל רק בכמה domains לדוגמה- שרתים ו- DBMS ואפילו APP SERVER. אם מוכיחים שה- pilot גילה דברים מעניינים – ההנהלה נותנת תקציב להמשך.
המידע שנאסף על ידי ה- EA חייב להיות פתוח לכל הארגון.
גם בשלבים הראשונים חייבים שיהיה executive sponsorship. ללא זה – לא ניתן להתקדם כלל.

דוגמה אישית גם ב- KPI ?

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

מה תפקידו של מנהל תשתיות או איך צריך לישון בלילה?

בדיון שנערך לאחרונה תאר מנהל תשתיות בכיר פרוייקט מתקדם שביצע. הפרויקט הינו ייחודי בישראל (ואולי גם בעולם) כאשר רוב הארגונים משתמשים עבור אותה משימה עסקית בטכנולוגיה שונה. השימוש בטכנולוגיה שונה מהמקובל גרם לכך שהפרוייקט הסתיים בעלות של כ- 30K$ וזאת לעומת הטכנולוגיה הסטנדרטית שהייתה אמורה לעלות כ- 500K$. חסכון מרשים ביותר. עם זאת הפרוייקט לא עבר על "מי מנוחות" והיו רגעים במהלך הפרוייקט שנדמה וחוזרים לנקודת ההתחלה וגם כעת, למרות שהטכנולוגיה עובדת מצויין ישנו חשש בבגלל חוסר נסיון יהיו תקלות משביתות.
כאן העלה מנהל התשתיות הבכיר אימרה מעניינת - "בשביל מה משלמים לי משכורת? בכדי שלא אשן בשקט!". ההסבר שנתן מנהל התשתיות היה שבכדי לבחור טכנולוגיות סטנדרטיות ללא סיכונים ובעלות גבוהה עם פונקציונליות שאינה מתקדמת - לא צריך "מנהל תשתיות בכיר" אלא "סתם פונקציונר".
לדעתי זאת אימרה מאוד חזקה. ישנם מנהלי תשתיות (או מנהלים בכלל) אשר כל מטרתם היא "לשון בשקט" תוך בחירה בטכנולוגיות סטנדרטיות ללא פונקציונליות מתקדמת ולעיתים בעלות גבוהה - רק בגלל הרצון "לשון בשקט" ולא לבצע בחירות מסוכנות. מצד שני ישנם מנהלים אשר בכל רגע נתון בוחרים בטכנולוגיה הכי חדשה שיש גם בכלל שהם מרותקים מטכנולוגיות חדשות וגם מכיוון שהם רוצים "לתפוס כותרות".
המצב הרצוי הוא שילוב של השניים. מנהל תשתיות (או כל מנהל) צריך להחליט ביודעין באיזה אזורים הוא "רוצה לישון בשקט" ובאיזה אזורים הוא "מוכן לקחת סיכון בכדי להתקדם".
הסכום אמור להיות מה שמומלץ לכולם - שינה סבירה. כאשר ההמלצה שלנו למנהלים היא לבחור ביודעין את התחומים שבהם הם מוכנים לקחת סיכון ואת התחומים שהם לא מוכנים לקחת סיכון.

על ניהול ו"שוק שחור"

במפגש שערכנו לאחרונה בין מנהלי פיתוח בארגונים שהם יצרני תוכנה עלתה תופעה בעייתית.
אחד הלקוחות דיבר שבזמנו דרישות ההנהלה היו מאוד קשות עד "בלתי הגיוניות" בתחום של באגים ואיכות. לחץ זה גרם להתפתחות של "שוק שחור" בתחום כלומר במקום לפתוח באגים בכלי הארגוני (clearquest במקרה זה) היו פותחים באגים בקבצי EXCEL . דבר זה התרחש אצל כל העובדים - גם העובדים המסורים ביותר. בעקבות ניסיון מר זה הוחלט בארגון שלא להציב מדדים קישחים או לתגמל בצורה מפורשת על גילוי באגים ותיקונם.
לסיכום - מנהל לא יכול לשנות מציאות ב"הינף קולמוס". הנחיות שיורדות מההנהלה חייבות להיות מותאמות למציאות בשטח זאת מכיוון שבמצב של חוסר ברירה גם העובדים המסורים ביותר "יעגלו את הריבוע".
מפגש זה היה מעניין ביותר- אפרסם עוד מתוכנו.

מה זה - שדרוג או הקשחה?

ארגוני מדווחים על קושי בפרויקטים המשנים ומגבילים את סביבת הלקוח. פרויקטים כמו הקשחת מחשבים או SBC – Server Based Computing (שימוש ב- thin clients).
אחד הלקוחות סיפר על דוגמה טובה לפרוייקט הקשחת מחשבים. משמעות הקשחת המחשבים היא שכעת ניתן להשתמש רק בתוכנות אשר אושרו מראש בארגון וגם לא ניתן לחבר התקנים ניידים כ- disk on key.
מנהל התשתיות באותו ארגון המתין עם הפרוייקט למועד מתאים ואיתר את המועד כאשר הוחלט על מעבר ל- Office 2007. ואז, במקום פרוייקט "הקשחה" התבשרו עובדי הארגון על פרוייקט "שדרוג" שבו יקבלו Office 2007 , מצלמת אינטרנט לשיחות וידאו בתוך הארגון ועוד. כאשר הסתבר לעובדים שחלק מהתוכנות שעליהם עבדו לא קיימות יותר לאחר ה"שדרוג" נמסר להם שמדובר בבעיות תאימות ולא ב"פרוייקט הקשחה".
זכורה לי סיטואציה דומה אשר בה הוחלפו מחשבים אישיים בעמדות thin client כאשר רק מי שביצע את ההחלפה קיבל מסך דק – דבר חדשני בזמנו.
לסיכום – יש זמן ומועד לכל דבר כאשר העטיפה חשובה לא פחות מהתוכן.

מאזן הכישלונות של פרויקטי תוכנה

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

תנאי מספיק להצלחת פרוייקט שליטה ובקרה

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

פרסום של מגמות עקריות בתחום ה- IT בשנת 2009 לקראת כנס STKI

להלן פרסום של מגמות עקריות בתחום ה- IT בשנת 2009 לקראת כנס STKI.

http://it.themarker.com/tmit/article/6175
http://www.themarker.com/tmc/articleCom.jhtml?ArtID=bh20090319_1017

"זהו אינו מיתון", אומר ד"ר ג'ימי שוורצקוף, מנכ"ל חברת STKI, "זוהי רעידת אדמה, החלפת מודלים עסקיים, ובמילים אחרות: Restart". על פי תוצאות מחקר STKI השנתי בקרב ארגוני IT מובילים בשוק הישראלי, שוקהמחשוב צפוי להתכווץ משמעותית בשנת 2009 לעומת 2008 בסדר גודל של 13% ויעמוד על כ-4 מיליארד $ לעומת 4.7 מיליארד $ ב-2008. הקיצוץ התקציבי והאווירה הכלכלית גורמת למנמ"רים לשנות מיקוד, כאשר המיקוד העיקרי במהלך 2009 יהיה "לעשות סדר פסח" בנכסי ה-IT.

במיתון הקודם, בין השנים 2001-2003, המיתון היה תחום בתוך גבולות תחום מערכות המידע, בתקופה זו ראינו ירידה של 40% בהוצאות המחשוב. עם היציאה מהמיתון, בין השנים 2004-2008 הייתה עלייה דרסטית של 70% בהוצאות המחשוב בישראל. בזמן עלייה זו, התרחשו רכישות ומיזוגים משמעותיים של חברות גדולות בשוק ה-IT מה שהביא ל-5 חברות ענק בשוק ה-IT בישראל שמכתיבות את הלך הרוח בתחום.

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

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

שוק החומרה בישראל:

בתחום החומרה המגמות הבולטות הן: סטנדרטיזציה וקונסולידציה של ספקים וכלים. בתחום השרתים הסטנדרטיים אנו צופים לירידת ערך שוק דרמטית הרבה יותר מהירידה הכללית של השוק בסדר גודל של כ-30%, וזאת מכיוון שנכון להיום בתחום זה קיים תת-ניצול משמעותי של משאבים. שרתים רבים עובדים בארגון בניצולת (בזמן השיא) של 40% ופחות. משמעות הדבר היא שאם חברה השקיעה במשך 4 השנים האחרונות 100 מיליון ₪ בשרתים, זה אומר שרק פחות מ 40 מיליון ₪ מנוצלים.

עם זאת, בתחום זה ישנה מצוקה של כוח אדם: ע"פ תוצאות מחקר STKI, חבר אחד בצוות מחשוב מטפל בממוצע ב-100 שרתי windows (לעומת 90 שרתים בשנה שעברה).

בתחום האחסון ישנה מגמה בולטת כבר מספר שנים של גידול עצום בשטחי האחסון מצד אחד, ומצד שני ירידה בעלות ממוצעת ליחידת אחסון בקצב של כ-35% בשנה. זוהי מגמה "טיפוסית" של השנים האחרונות. המשבר משפיע כקטליזאטור בתחום זה, כבר עתה אנו חשים בירידת מחירים מוגברת שייתכן שתוצאתה תהיה האצת קצב הירידה בעלות (לשם המחשה, במיתון הקודם בשנת 2002 ירדו המחירים בקצב של כ-50% בשנה אחת, השנה ייתכן שעוד נעבור רמות אלה). עקב צריכה גבוהה יותר של אחסון, ב-STKI צופים ששוק זה בסה"כ לא יצנח בצורה דרמטית (ירידה של 5%). כמו כן, קיים מחסור חריף בכ"א מיומן ובהקצאת תקנים בארגון לתחום האחסון. כתוצאה מכך, היו גם בשנת 2008 תקלות IT מערכתיות שקשורות לסביבת האחסון.

בתחום תחנות הקצה (מחשבים שולחניים וניידים), התקשורת והמדפסות תהיה ירידה של כ-20-25% כאשר מגמה חשובה בתחום היא התגברות השימוש במחשבים ניידים על חשבון מחשבים שולחניים וכניסה של מחשבי netbooks. בהתייחס לתחום התקשורת הארגונית, השנה ראינו המשך במגמת ההתכנסות בין פלטפורמות תשתית התקשורת לבין שירותי הערך המוסף שהן מספקות. מתגי התקשורת ממשיכים להוסיף לעצמם "שכל ארגוני" כמו יכולות ניהול וניטור מורכבות יותר, יכולות שונות של אבטחת מידע ויכולות עבודה בתצורה וירטואלית על בסיס שיתופי פעולה מסקרים בין יצרני תקשורת כמו סיסקו, ג'וניפר HP ואחרים עם VMWARE ו MICROSOFT.

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

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

שוק התוכנה:

שוק התוכנה צפוי לרדת ב12% ב 2009 לעומת 2008. אחת מהבעיות הגדולות בתחום זה הנה עודף רישיונות שקיים כיום בקרב ארגונים, עליהם ארגונים משלמים אחוזי תחזוקה גבוהים, ולעתים גם לתוכנות בהן אינם משתמשים / עושים שימוש מוגבל ביותר. מגמה נוספת מעניינת בתחום הנה הסתכלות גם על תוכנות קוד פתוח (דבר עדיין די נדיר בארגוני enterprises בישראל), אך בשוק הישראלי הסתכלות זו תהיה מוגבלת בתחילה לתחומים ספציפיים.

שוק תוכנות התשתית (מערכות הפעלה, מסדי נתונים וכד') יקטן ב-16%, תחום כלי ניהול IT (מערכות שו"ב, HELP DESK, וכלי ניהול IT, ואבטחת מידע) יירד בכ-10% אך 2009 תהווה שנת הכנה לקראת השקעה מוגברת בתחום זה בשנים הבאות, כי באמצעות השקעה בתחום זה ניתן לבצע את אותו "סדר פסח" אותו ארגונים צריכים לעשות במערך ה-IT.

תחום התוכנות הארגוניות (הכולל ERP, CRM, ניהול ידע) צפוי לרדת בכ-20% ברמות שונות (לדוגמה, דווקא שוק ה-CRM צפוי לשמור על יציבות), הפרויקטים "המועדפים" אליהם ארגונים ייכנסו הנם קטנים, ממוקדים, קצרים (עד שנה) בעלי סיכון נמוך והחזר השקעה מהיר (כמה חודשים). כמו כן, ארגונים מציינים כי חיזוק יכולות SELF SERVICE וריבוי ערוצים (WEB, MOBILE, קיוסקים וכד') הנם פרויקטים אסטרטגיים אשר מונעים הן מרצון לחיסכון עלויות במוקדי המכירה והשירות (עלות שיחה עם מוקדן: 5$ בממוצע, עלות אינטראקציה ב-IVR: 1$, ואילו עלות אינטראקציה בשירות עצמי באתר האינטרנט: כ-20 סנט), והן מרצון למקסם ערך השירות ללקוח (מחקרים בינלאומיים מוכיחים כי שילוב אפקטיבי של יכולת שירות עצמי מעלים את רמת שביעות הרצון של הלקוח).

בעולם כלי אבטחת המידע וניהול הסיכונים בארגון, בניגוד למגמה הרווחת בשאר עולם מערכות המידע, ממשיכה הצמיחה אם כי בקצב נמוך בהשוואה לשנה הקודמת. בחלוקה בין שני תתי התחומים (GRC – governance risk and compliance, ואבטחת מידע)ניתן לראות כי הוצאות בגין GRC צפויות לעלות גם השנה ואילו התקציב המוקצה לתת-התחום אבטחת המידע צפוי להישאר ברמה דומה לזו שהייתה בשנה הקודמת ואף קצת לרדת במקצת. רוב פרויקטי המחשוב מחייבים תשומות אבטחתיות כחלק אינטגרלי מהפרויקט ולכן עיקר הקיצוץ השנה נובע מעצירה כללית של פרויקטים ארגוניים בעקבות המצב הקשה.

שוק השירותים:

שוק השירותים צפוי לרדת ב-8% (ירידה מתונה יחסית לתחומים אחרים בגלל שפרויקטים שכבר נמצאים באמצע דרכם לרוב אינם נעצרים, מה שימשיך "להזין" שוק זה גם ב-2009). בתוך שוק השירותים, תחום מיקור החוץ לא צפוי להשתנות מבחינת מחזור ההוצאות בגלל אופי ההתקשרויות (ארוכות טווח, למס' שנים). אולם במהלך 2008 ראינו ירידה משמעותית במס' עסקאות מיקור חוץ חדשות (מלבד עסקה גדולה אחת במגזר הממשלתי) וכן בתכולה וגודל החוזה. חשוב לציין שבישראל אין אנו עדים לתופעת ה – BACKSOURCING (החזרת פעילויות ה-IT ממיקור החוץ חזרה לארגון) שרווחת בחו"ל. התחום העיקרי שנפגע הנו תחום עובדי ההשמה: ירידה של 30%. עיקר הקיצוץ בתחום זה מגיע מהורדת התעריפים ובשעות העבודה של האנשים המועסקים כעובדי השמה. כפי שהובטח, עובדי ההשמה אכן אפשרו גמישות רבה לארגון בזמנים בהם פעילותו קטנה בצורה משמעותית.

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

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

נושאים אלה יידונו בכנס השנתי של STKI, ובו STKI תחשוף את תוצאות המחקר השנתי, דירוגי חברות בישראל ומגמות. הכנס ייערך ב 24.03.09. לפרטים:
http://www.stki.info/index.php?page_id=9

מדוע נכשלים פרויקטים של שליטה ובקרה?

להלן מאמר שכתבתי לפני מספר שנים ועדיין מאוד רלוונטי.

תחום השליטה והבקרה הנו תחום המועד לפורענות ולכישלון, יותר מתחומים אחרים בתחום ה- IT למרות שתחום זה הנו תחום בשל יציב ואשר טכנולוגית אינו מורכב. באופן עקרוני יישום פרוייקטים מסוג זה מתבצעים על ידי הצבה של agents ברכיבי המחשוב השונים אשר מדווחים למרכז נתונים חיוניים (האם השרת עובד, האם יש מקום בדיסק, האם ביצועי התקשורת סבירים וכד'). בשנים האחרונות ישנה נטייה גם ליצור "מפות עסקיות" של רכיבי המחשוב השונים.
הסיבה החמקמקה לכישלונות בתחום זה קשורה לאופיו הייחודי של הפרוייקט.
באופן טבעי, מוטל עומס רב על צוותי ה- IT השונים. ולכן, לעיתים תכופות, צוותי ה-IT שאחראים לתחזוקת הפרוייקטים אינם יכולים לבצע את כל שנדרש מהם בצורה מלאה ולכן הפרוייקט נפגע בצורה חלקית. כך למשל, אם במידה וצוות הממשקים קיבל תפקיד נוסף, ולכן משקיע 5% פחות מזמנו בטיפול השוטף בממשקים, הרי ש- 5% מפרוייקט הממשקים נפגע. באופן ברור הצוות יכוון את הפגיעה בממשקים הפחות חיוניים. כנ"ל הדבר גם בפרוייקטי IT אחרים כגון CRM, ERP, אחסון ועוד. ואולם, בתחום השליטה והבקרה, המצב שונה בתכלית. אם צוות השליטה והבקרה עמוס, ולכן משקיע בתפקידו פחות מהרצוי, אפילו ב- 5%, הרי שלאחר תקופת זמן של מספר חודשים ישנה פגיעה ב- 100% מתפקוד מערכת השליטה והבקרה. זאת מכיוון שבמידה ואפילו שינויים מעטים במערכות הייצור אינן מעודכנות לסביבת השליטה והבקרה (לדוגמה, התווסף שרת חדש, לדוגמה, הוחלפו שני routers לדוגמה השתנה מספר IP וכד') הרי שהחיוויים במערכת השליטה והבקרה אינם אמינים, משתמשי הפרוייקט אינם מאמינים למערכת ולכן יעדכנו אותה פחות, ותוך תקופה לא ארוכה, ישנה התמוטטות מוחלטת של כל פרוייקט השליטה והבקרה.
בארגוני IT לא גדולים, צוות השליטה והבקרה מונה אדם אחד (או אפילו לא משרה שלמה) וכאשר אותו אדם לא נמצא בעבודה או קיבל תפקיד נוסף ולכן לא יכול לבצע את כל העדכונים, הרי שהדרך להתמוטטות סביבת השליטה והבקרה כמעט מובטחת.

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

טכנולוגיה היא לא תחליף לתהליך

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

לקוח enterprise ראשון שעושה שימוש ב- Cloud Computing בתחום התשתיות

נכון להיום רובם של לקוחות ה- Enterprise "מעקמים את האף" כשאר אנחנו מדברים איתם על Cloud Computing. הטענה העיקרית שמושמעת כנגד הטכנולוגיה זו היא הסוגיה של אבטחת מידע – המשמעות של העברת הנתונים החשובים ביותר של הארגון לידיים אחרות. טענה אחרת היא הסוגיה של זמינות – עד כמה שירותי ה- Cloud זמינים. ישנם סוגיות בעייתיות אחרות כמו עברית וכד'.
עם זאת, לאחרונה גיליתי להפתעתי שישנם לקוחות שכבר משתמשים בטכנולוגיה מתקדמת זו. לקוח מסורתי ממגזר מוביל ביצע בחינה של פתרונות בתחום של XML Firewall. לצורך הבחירה בין המוצרים השונים דרש הלקוח לבצע בחינה Proof of Concept של הפתרונות השונים שהוצעו. אך הסתבר שבאותה נקודת זמן לא היו בארגון שרתים זמינים שמתאימים לביצוע הבחינה. אצל רובם המכריע של לקוחות ה- enterprise סיטואציה כזו גורמת לעיקוב משמעותי בלו"ז של הפרוייקט. אולם, לקוח זה התקין את המוצרים על שרתים בתוך ה- Amazon EC2 וביצע את הבחינה הטכנולוגית בצורה מיידית וחלקה ללא עיקוב הלו"ז של הפרוייקט.
זאת למיטב ידיעתי הדוגמה הראשונה של לקוח מתחום ה- Enterprise שעושה שימוש ב IAAS – Infrastructure as a service בתוך ה- Cloud. לקוחות קטנים יותר בעיקר ממגזר ה- startups משתמשים בטכנולוגיה זו בצורה מאסיבית. אנו מעריכים שלקוחות נוספים מתחום ה- Enterprise ילכו בעקבותיו.

מדרגות זה טוב - מעלית זה רע

באחת הפגישות האחרונות שלי דיבר מנהל התשתיות על פרוייקט ארגוני גדול שאמור להעביר את כל משתמשי הארגון (אלפים) לעבודה בטכנולוגיה של VDI – Virtual Desktop Infrastructure. הלקוח מבצע כעת Pilot ואמור לאחר הניסוי להכנס לפרוייקט ארוך טווח. ואולם, למרות שתחום זה בעל פוטנציאל גדול, הטכנולוגיה עדיין לא הוטמעה בצורה מלאה אצל לקוחות גדולים ורבים. במקביל, ישנן טכנולוגיות נוספות (כמו Application Virtualization או Cloud Computing ) שגם הן רלוונטיות מאוד לתחום תחנות הקצה. ולכן בתור סיכום של הפגישה הוחלט להמשיך עם הניסוי אך בכל מקרה לא להתחייב לרכישה\הטמעה מיידית ובכל הארגון.
כלומר- מדרגות זה טוב, מעלית זה רע!