הענן פה – אז מה עושים?

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

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

הטמעת תמידית של תהליכים עסקיים ומערכות המידע התומכות בהם

רובם המכריע של הפתרונות המוצעים בענן מבוססים על ארכיטקטורה של multi-tenant והמשמעות היא שכל המשתמשים בעולם נמצאים באותו בסיס של קוד ומסד נתונים ולכן כאשר מתבצע שדרוג – הוא מתבצע לכל המשתמשים בעולם באותו זמן ולא ניתן לדחות שדרוג זה. רוב יצרני הפתרונות בענן מבצעים שדרוג פעמיים בשנה והמשמעות היא שארגונים צריכים (תלוי בגודל השינוי של הגרסה החדשה לעומת הגרסה הישנה) לבצע הטמעה של הגרסה החדשה של המערכת, כולל שינוי של תהליכים עסקיים המתבקשים משינויי המערכת. זאת לעומת המצב הקודם שבו שינויים (אמנם גדולים יותר) היו מתרחשים רק פעם במספר שנים. לפיכך, מאמץ ההטמעה הארגוני אמור לגדול, כאשר הטמעת מערכות הופכת להיות פעולה שהיא יותר on going ולא פעולה שמתרחשת פעם במספר שנים. הגורמים העסקיים צריכים לקבל את העובדה שתהליכים העסקיים משתנים\מתפתחים כל הזמן.

מעבר מ- CAPEX ל- OPEX

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

סייבר ורגולציה בקצב מואץ

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

מבנה ארגוני חדש ושדרוג תהליכי תפעול ללא דריסת ה"ישן"

במאמר הקודם כבר דיברנו על כך שהענן מחייב התארגנות שונה ובניית תהליכים חדשים בין הגורמים הבאים: תפעול תשתיות, רגולציה, רכש ,מטה ה- IT (העוקב אחרי התקציבים ומתעדף משאבים) ואבטחת מידע\סייבר. במאמר גם הזכרנו כלים אשר באים לתת מענה לסוגיות אלו – תחום ה- cloud management platforms. הפעם נשים את הדגש על שילוב הישן עם החדש. לארגונים יש נטייה לבנות צוות ענן המופרד מהצוותים הקיימים בארגון. למרות היתרון במיקוד ובמקצועיות מדובר על מהלך שגוי, מכיוון שבניית צוות נפרד אשר מטפל בענן גורם ליצירת שני מחנות בארגון "ישן" מול "חדש", דבר שמהווה מתכון לכישלון בטווח הארוך. הדרך המומלצת היא לשלב את החדש בתוך הישן – במידת האפשר. כלומר, לדוגמא, צוות הסיסטם יטפל בשרתים בענן וגם בשרתים on prem. צוות ה- DBA יטפל בנתונים גם בענן וגם ב- on prem וכד'. רק האזורים שלא קיימים כלל בסביבת ה- on prem צריכים להיות מטופלים על ידי צוות הענן – דברים כמו ניהול הקשר מול ספק הענן בהקשר של תקציבים, מידת השימוש וכד'.

עד כאן להפעם.

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

מודעות פרסומת
הענן פה – אז מה עושים?

מתוך המלצות לרכש IT

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

המלצות כלליות:

  • הגדרת ההצלחה של הפרויקט. רצוי לבנות מודל שבו התשלום לספק\אינטגטור יהיו מבוססים על ההצלחה של הפרוייקט. דברים כמו (בדוגמה לפרוייקט של CRM כשהמטרה העקרית היא להוריד את זמן הטיפול בקריאות) "במידה ומצליחים להוריד את זמן הטיפול הממוצע בקריאה ב- 5% אז התשלום יהיה  X. במידה ומצליחים להוריד את זמן הטיפול הממוצע לקריאה ב- 10% התשלום יהיה Y".
  • כיצד מחשבים את תאריך תחילת התשלום עבור הרישוי (תחילת הפרויקט/עלייה לאוויר)
  • אי עמידה בחוזה – מה קורה אם לא עומדים בחוזה?
  • הערה כללית חשובה – שינויים בהסכם יתבצעו רק מול הרכש באופן ספציפי (אחד הלקוחות תאר מצב שבו האנשים הטכניים התקינו גרסה חדשה של מוצר ובמסגרת ההתקנה לחצו על I AGREE ששינה את תנאי הרישוי – איך סופרים רישיונות).
  • הגדרת האחריות בין גורמים השונים המעורבים בפרויקט (לקוח/ ספק בינ"ל, ספק מקומי/ אינטגרטור)
  • יש להגדיר גבולות של מערכת וגם אפשרות לחרוג לעיתים מהגבולות. לדוגמה, נניח שהספק מספק מערכת שמבוססת על microfocus cobol. נניח שהלקוח מעדיף לעבור ל- cobol-IT. רצוי שיהיה סנריו שבו (במידה ומעדיפים לבצע מהלך כזה באופן עצמאי ולא על ידי הספק) הלקוח יוכל לבצע את ההחלפה בעצמו ולהחזיר את המערכת לאחריות הספק. הדוגמה כאן היא מתחום התשתיות אבל העקרון צריך להיות כללי.
  • אם אפשר- במידה ויש חילוקי דעות לקיים בוררות\משפט בישראל תל אביב.
  • במידה והתוכנה יקרה per seat רצוי לכלול בפתרון רכיב של usage\metering אשר בוחן את מידת השימוש בתוכנה. כך למשל תוסר התוכנה מלקוחות אשר לא ישתמשו באופן מהותי בתוכנה (לפי מדידות רכיב ה- usage\metering) .
  • שהספק לא יתקין כלום – אפילו לא לבדיקה- מבלי שקיבל אישור של רכש
  • רצוי לנסות ולהבין כמה שיותר מוקדם כיצד מתוגמלים אנשי המכירות הן של היצרן והן של האינטגרטור הגלובלי והמקומי. האם מתוגמלים לפי סה"כ הכנסות? האם רק לפי רישוי חדש? האם לפי גידול? ואז לנסות ולהתאים את המשא ומתן לפי ידע זה.
  • רצוי לקבל התחייבות שהתנאים בהסכם יהיו תקפים גם עם היצרן או האינטגרטור (הישראלי\חו"ל) ירכשו או יתמזגו על ידיד אחרים (כולל תוקפו של הסעיף על מוצרים עתידיים).
  • רצוי שיהיה פירוט מחירים ברמת השורה הבודדת של העסקה (לא מחיר כללי לעסקה) כך שבמידה ויש שינוי אפשר להשליך על משמעות השינוי.
  • באופן כללי רצוי לבנות את ההסכם "מוכן לשינויים" כלומר באופן שיקל על ביצוע שינויים בתכולה כמה שיותר.
  • באופן כללי – צריך לבנות את ההסכם הנוכחי כך שיכין את התנאים להסכם הבא. כלומר אם חותמים על הסכם ל- 5 שנים רצוי להוסיף פסקה שמדברת כל כך שהתנאים בהסכם זה יהיו תקפים גם להסכם הבא (הסכם התחזוקה). כך שהספק לא יוכל להעלות מחירי תחזוקה וכד'.

 

מוצר ורישוי

  • התחייבות לכמות הפעמים (בכל פעם שיוצאת גרסה חדשה/ אחר)
  • מה בדיוק מקנה הרישוי: רישיון תמידי perpetual license)) ותחזוקה או מנוי (subscription license)
  • במידה ומדובר על perpetual – לוודא שיש אפשרות להשתמש במוצר ללא תשלום דמי תחזוקה.
  • במידה ובוחרים ב- subscription מה המשמעות לעבור "חזרה" ל- perpetual
  • בכל מודל – צריך לוודא שהנתונים הם בבעלות הלקוח.
  • לנסות לקבל מראש מידע איזה שדרוגים אמורים לקבל ומתי.
  • להתייחס לסוגיה של עדכוני תשתיות – כלומר שעלות התחזוקה כוללת עדכון המוצר\פתרון לגרסאות חדשות של לינוקס\windows IOS ANDROID וכד'.
  • האם יש אפשרות לעבור מהמודלים השונים ל"בעלות על התוכנה והקוד" (כמו שאמדוקס מוכרים את התוכנה שלהם – והלקוח מקבל את התוכנה ויכול לשנות אותה בעצמו)
  • לוודא שכאשר כותבים קוד במסגרת הפרוייקט (אפילו קסטומצזיה של המוצר) – שהלקוח הוא הבעלים של הקוד שנכתב.
  • להגדיר מראש איך סופרים את רישוי התוכנה. הדבר הכי טוב הוא לציין שבארגון משתמשים ב- SMS או CA או משהו כזה – ולפי הדו"ח של הכלי יקבעו הכמויות. כך מונעים מהספק לבוא ולבצע ספירה בעצמו (עם כלים שהוא מתקין).
  • לגבי רכיבי משנה של תוכנה – האם ניתן יהיה להעביר את הרישוי (perpetual ) או זכות השימוש (אם ב- subscription) למערכות אחרות בלקוח? לדוגמא, אם במסגרת העסקה רוכשים\שוכרים 10 רישיונות של המוצר אבל בפועל מסתבר שמשתמשים רק ב- 8, האם ניתן להעביר את 2 הרישיונות לשימוש במקום אחר בלקוח? האם ניתן להעביר רישוי בין שרת פיזי לוירטואלי , לענן ובין פלטפורמות שונות (לינוקס, WINDOWS , מ- IOS ל- android)?
  • האם יש אפשרות להקפיא רישוי? לדוגמה אם רוכשים 10 רשיונות אבל תקופה מסויימת מבינים שצריך להשתמש רק ב- 8 רשיונות, האם אפשר "להקפיא את הרישוי" ולאחר תקופת הזמן לחזור לשימוש ב- 10 רשיונות?
  • האם אפשר יהיה להעביר את הרשיונות לגורם שלישי (לשכת שירות)?
  • האם ניתן ל"הביא רישוי" מהבית (של מוצרי תשתית)?
  • מודולים / מנועים / גרסאות עתידיות:
    1. מהי מדיניות התמחור לגרסאות חדשות? האם יש גרסאות משמעותיות שיצריכו רכישה מחודשת של רישוי?
    2. מה קורה עם המוצר (או חלק ממנו) מפסיק להיות נתמך (discontinues) או לחילופין מה קורה אם מאחדים מוצר (או מודול) עם מוצר אחר (או מפצלים מוצר לכמה תתי מוצרים)- האם צריך כעת לשלם על המוצר המורחב? רצוי לנסח בצורה כזו "ש"החברה מתחייבת לשמור על הפונקציונליות הנוכחית של המוצר\פתרון לאורך זמן על פי התמחור הבסיסי של ההסכם. במידה והפונקציונליות אינה מתקיימת במוצר הנוכחי, הספק יבצע החלפה למוצר או מוצרים תחליפים ללא עלות ובכדי לשמור על התנאים של הסכם זה".
    3. האם המחיר כולל "מנועים" (ניהול ארכיון מסמכים / BI מובנה / תשתית אינטגרציה ועוד)
    4. % הנחה ממחירון למנועים / מודולים נוספים
    5. במידה ומוזכרים מחירונים בעסקה – יש לציין ספציפית באיזה מחירון מדובר, להדפיס מחירון זה ביום תחילת ההסכם (לייתר בטחון).
    6. עדיף כמובן להשתמש במחירים גלובליים ולא במחירונים ישראלים או regional.
מתוך המלצות לרכש IT