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

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

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

מה זה אומר להיות "ארגון אקספוננציאלי"?

אנו נמצאים השנה בפתח המהפכה התעשייתית הרביעית, המושפעת בעיקר מהתפתחויות משמעותיות בתחום התובנה המלאכותית (Artificial intelligence), החיבור בין תחום הרובוטיקה, יכולות אוטונומיות, אלגוריתמיקה, ועוד תחומים המצטרפים ומשנים כיום פני תעשיות שלמות. דוגמה ספציפית לשינוי מהותי זה הוא שינוי פני שוק העבודה (על פי מחקר של מכון טאוב, כ-300 מקצועות נמצאים בסיכון גבוה להיעלמות/החלפה על ידי כוח מחשובי, וכ40% משעות העבודה של מקצועות עובדים בישראל נמצאים ב"סיכון גבוה" כזה בשני העשורים הקרובים). חשוב להבין שההתפתחות הנה מהירה, ופוגשת עולם שאינו מוכן להתמודד עם מהפכה זו (לדוגמה, כיום ישנה יכולת טכנולוגית למטוס ללא טייס, אך האם לקוחות בכלל יסכימו לטוס במטוס המוטס לחלוטין על ידי מכונה?). קצב הטכנולוגיה מהיר וגדול מיכולת תעשיות וארגונים לספוג אותה.

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

  • מיהו המתחרה שלנו בתחום ממוקד ה-IT? תקציב ומשאבי הארגון, וכן נותני שירותים חיצוניים המספקים אותו שירות במחיר טוב יותר.
  • מיהו המתחרה בתחום ממוקד- פונקציות עסקיות? Shadow-IT, אותן שירותים ואפליקציות אשר פונקציות עסקיות שונות בארגון כמו שיווק, ניהול לקוחות, כספים – יכולים לצרוך בענן ללא התערבות רבה של IT.
  • מיהו המתחרה בתחום ממוקד-לקוח? מכיוון שכאן מדובר לא על מערכות המשרתות את הארגון על מנת לשרת את הלקוח, אלא מדובר על המוצר הדיגיטלי שלי המשרת ישירות את הלקוח, רמת הקריטיות בניהול תהליכי פיתוח קצרים, שחרור גרסאות מהר, יצירת מערך תמיכה מאוד יעיל ועוד, עולה משמעותית. מדובר על יכולת הארגון לנהל "מוצר SaaS" לכל דבר, עם הבדיקות, שחרור גרסאות קטנות, תמיכה וניהול הצלחת ההטמעה לכל דבר, ממש כמו ספק SaaS טכנולוגי.

ההתפתחויות הטכנולוגיות המשמעותיות ביותר: תחום ה Blockchhain (מעין ספר ראשי מבוזר של טרנזאקציות על ידי חברים ברשת, היישום המפורסם ביותר הוא הפלטפורמה ה"מנהלת" את מטבע הביטקוין אך כיום תעשיות רבות ומגוונות בוחנות וחלקן כבר מיישמות טכנולוגיה מהפכנית זו); מציאות מדומה שתלך ותיעשה נפוצה הרבה יותר; ביג דאטה ואנליטיקה שהשנה, לראשונה, הפכה לטכנולוגיית mainstream בשוק הבינלאומי – עדיין לא בישראל; הספדה בתלת-מימד; סייבר; רובוטים אוטונומיים; אינטרנט-של-דברים וטכנולוגיות מכונה-למכונה; ואספקת שירותי ענן.

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

 

מה זה אומר להיות "ארגון אקספוננציאלי"?

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

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

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

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

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

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

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

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

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

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

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

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 – עדכונים מהירים על קצה המזלג:

מתוך המלצות לרכש 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