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

הדבר הבא באנליטיקה: Machine intelligence

Machine Intelligence (השילוב בין Machine Learning ובין Artificial intelligence) הנה ההתפתחות הטכנולוגית המעניינת ביותר שתשפיע לא רק על עולם העסקים, אלא על הדרך בה אנחנו כצרכנים ועובדים נחיה את חיינו היום-יומיים. מחשבים כבר למדו לחשוב, לקרוא, להבין, לדבר וללמוד דפוסי התנהגות (כיום עובדים על חוש הריח).

אך היכן נמצא השוק ביחס להתפתחויות טכנולוגיות אלה? טכנולוגיות Machine learning כבר די בשלות, ברמות שונות. ישנן טכנולוגיות בסיסיות אשר זמינות ופותחות החוצה את שירותיהן בתצורת APIs, יש מתקדמות יותר. וישנן גם אפליקציות – וכאן החלק המעניין באמת. במסגרת כנס ביג דאטה ו Machine Learning,Shivon Willis (החוקרת את התחום ב- Bloomberg), יצרה מפת טכנולוגיות מעניינת, אותה היא מחלקת לטכנולוגיות; אפליקציות המיועדות לשינוי חיי אנשים; תעשיות; Enterprises; כלים משלימים ועוד חלקים המרכיבים את ה Eco system הזה, שכמעט כולו מורכב מסטארטאפים. אבל לא רק, גם ספקים כדוגמת מיקרוסופט (יכולות ML ב Azure), אמאזון Machine Learning, היכולות הקוגניטיביות, ספקי אנליטיקה כדוגמת SAS ועוד.

שורה תחתונה: בקרוב כולנו נרגיש את ההשפעה של כלי Machine Learning בתחומים שונים, כאשר בתחומי ה-IT התחום הראשון בו ארגונים יוכלו להתחיל ליהנות מיכולות אלה יהיה תחום האנליטיקה, במיוחד פרויקטים חדשניים באנליטיקה ו – Big data analytics בהם לאנליסטים ו Data Scientists "מתחילים" אין תמיד מספיק ניסיון לדעת איזה מודל אנליטי מתאים לאיזו בעיה עסקית, טכנולוגיות אלה יוכלו לסייע בתהליך חשוב זה ולקצר את עקומת הלמידה, שהנה מאוד משמעותית כיום ומעכבת time to market. אנו ממליצים לחפש יכולות ML בכלי האנליטיקה שארגונים בוחנים כיום.

 Internet of Things

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

שעון מעורר המנטר את השינה שלי יצלצל בדיוק בשלב המתאים ביותר להתעוררות, הסנסורים בבית החכם ידליקו את האור (בהדרגה) ויפעילו את מכונת הקפה, ובזכות החיבור ליומן ולפקקים מכשירים אישיים חכמים יציעו לי מתי לצאת מהבית, יתאמו מוזיקה, ידברו עם הרכב… וכמובן, הציפייה לשירות מחובר, רציף, מנותר ופרו-אקטיבי נכנסת במהירות גם לעולם הארגוני. אולם, תחום ה- M2M – Machine-to-Machine קיים כבר היום, מכונת השתייה שידרה למרכז הבקרה שהקולה נגמרה, אבל האדם היה זה שהחליט האם להוציא את משלוח הקוקה קולה כבר עכשיו וכמה בקבוקים צריכים להיות שם. העתיד מדבר על מערכות שייקחו את ההחלטות הללו באופן עצמאי. מכשירים חכמים, המדברים בינם ובין עצמם משדרים לענן, מנתחים את המידע ומחליטים החלטות בכל רגע נתון.

שורה תחתונה: ניטור וניתוח מתמיד של מידע המתאפשר היום בזכות מיליוני סנסורים, ענן, אנליטיקה דיגיטאלית, מזהה דפוסים שלא היינו ערים להם קודם לכן, מקצר לנו את תהליך של קבלת ההחלטות, מציע ומבצע את הדבר המומלץ ביותר עבורי. ולמרות לא מעט אתגרים לא פתורים של התחום, הצדקתו הכלכלית ברורה וקלה להוכחה. אנו צופים בתקופה הקרובה כניסה רחבה של ארגונים לפרויקטי IoT, הן פרויקטים הפונים לקהל הרחב, אשר משדרגים את חווית הלקוח וחדשנות, והן פרויקטים ארגוניים Internet of Corporate Things-, אשר מייעלים תפעול, חוסכים העלויות ומציעים תהליכי עבודה שלא היו אפשריים קודם לכן.

תיבות דואר בענן כמשל לענן – פוטנציאל גדול אך מציאות מורכבת

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

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

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

פידבק נוסף דיבר על מצבים שבהם מגיעים למגבלות בענן. תיבת דואר בענן מוגבלת למשלוח של 30 הודעות מייל בדקה או 10K הודעות ביום. אין אדם שמגיע או אפילו מתקרב למגבלות אלו אולם תיבת דואר מתוך אפליקציה (ERP\CRM) או תיבת דואר ארגונית המספקת הודעות ארגוניות (תקלות בארגון, אירועים חשובים וכד') מגיעה בקלות למגבלות אלו ולכן נדרשת התאמה מיוחדת ושינויים באפליקציה כאשר עוברים לענן.

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

The Israeli Privacy Data Dance – Opportunity or Difficulty?

Israel's Privacy Protection Law states that a citizen's personal data cannot be exported to a country with a lesser level of protection than that guaranteed by Israel. On October 6th, the European Court of Justice (ECJ) decided to invalidate the Safe Harbor Program between the EU and US.  The European Court of Justice held that the U.S.-EU Safe Harbor Program failed to provide adequate protection for EU citizens. Based on that decision, the Information and Technology Authority (ILITA), Israel's data protection authority revoked on October 19th its prior authorization for data transfers from Israel to the U.S. based on the U.S-EU Safe Harbor Program certification.

This may create an opportunity for Israeli companies, since the European Commission's 2011 decision remains in effect, the ECJ decision may create a competitive advantage to companies conducting processing or storage activities in Israel, as these companies can continue to receive data from Europe without the uncertainty now inherent in EU-US data transfers. Consequently, Israeli companies will need to find an alternative legal basis for transferring personal data to the U.S., and could experience an “uncomfortable transition period,” according to Limor Shmerling, ILITA's director of licensing and inspection.  “It's too early to tell how the market will be affected and how practices may need to be changed,” she said, adding that the authority is “considering the implications of the new legal status and will further address the subject accordingly.”

This may also create a challenge for local operators of multi-nationals including large local operations of multi-nationals such as IBM, Intel Corp., Microsoft Corp., Google Inc., Facebook Inc. and Hewlett-Packard Co., as well as Israeli “unicorns” such as Waze, Wix and IronSource., according to a statement by the U.S.-based International Association of Privacy Professionals (IAPP), “the decision could pose a significant barrier to data flow from Israel's surging technology sector,”

“Since the Safe Harbor arrangement is currently invalid under European law, and as long as there is no other valid arrangement or another formal decision of the European Union (EU) with respect to the transfer of data from Europe to destinations in the United States, database owners who wish to transfer personal data from Israel to entities in the United States are therefore required to assess whether they can base the data transfer on another of the derogations determined in the regulations,“ the ILITA said in its decision.

The EU's recognition of U.S. Safe Harbor certification, combined with its 2011 granting of “adequacy” status to Israel under the EU Data Protection Directive, allowed personal data to flow freely between the EU and Israel, and on to U.S. companies on the Safe Harbor certification list.

The Safe Harbor system has been widely used to legitimize the outsourcing of services by EU-based companies and their commercial partners to U.S.-based cloud or software-as-a service (SAAS) providers, and to facilitate intra-group data-sharing among entities with both U.S. and EU operations.  Although this has not had the desired effect in Israel and this new stance by ILITA goes hand in hand with the new Israeli Cloud Banking Regulation 357 stating that core data cannot be in the cloud.

It added, however, that current Israeli business models could be affected, including Israeli companies with European affiliates that previously relied on the Safe Harbor arrangement to transfer data to the U.S., as well as Israeli companies outsourcing storage or processing activities to U.S. service providers or affiliates that include information on European customers, in which case they may need to amend their customer agreements to include authorization for the transfers.

Bottom Line: Know your options and plan accordingly.

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

אתרי ה- Web החדשים – מקבלים "חיזוק" מפלטפורמות מסחר אלקטרוני

ארגונים כיום מכל הסקטורים בוחנים מחדש את התצורה בה הם מדברים עם הלקוחות בערוצים הדיגיטליים ובתוך כך האתר (הערוץ מס' 2 בחשיבותו כיום אחרי המוקד הטלפוני! וערוץ משמעותי עבור נושא שירות-עצמי) מקבל תשומת לב רבה. אנחנו עדים כיום להרבה פרויקטים בישראל של "בנייה מחדש" וגם חשיבה מחדש של אתרי ווב. פשוט – האתרים הרגילים כבר אינם מתאימים! מה ארגונים מחפשים כיום? מה שהלקוחות שלהם רוצים:

  1. פרסונליזציה, התאמת האתר והתכנים ללקוח
  2. בניית "קטלוג שירותים / מוצרים" בצורה יותר קלה לשימוש – הורדת ה"סירבול" בשימוש באתר
  3. התאמה ל Devices השונים (אסטרטגיית מובייל / נייטיב / ריספונסיב וכד')
  4. חיבור יותר הדוק בין הערוצים השונים לבין עצמם (יכולת "מעבר" בין פעולה שהתחלתי ב WEB לפעולה שאמשיך במובייל וכד')
  5. יכולות שירות עצמי
  6. חיבור בין אונליין לאופליין (כשלקוח מתקשר למוקד הטלפוני לאחר שגלש במשך 10 דקות באתר – לנציג יהיה כבר פרופיל דיגיטלי ויוכל לספק שירות יותר ספציפי)
  7. יכולת לנתח ולבצע אנליטיקה על התנהגות וחוויית הלקוחות באתר ובמובייל (על כך קיימנו מפגש לאחרונה – Digital analytics – אשר את סיכומי נפרסם בקרוב).

מגמות בשוק הישראלי:

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

מבחינת מפת הספקים בתחום ה Ecommerce ספציפית:

נוצרו 2 מחנות של כלים:

  1. מחנה אחד הוא כלי ה- High End ה"גדולים" (SAP Hybris, אורקל ATG, יבמ Websphere Commerce)
  2. המחנה השני הוא כלי קוד פתוח (בארץ בעיקר Nopcommerce ו – Magento). בשוק המקומי ארגונים נוטים לא לאמץ את הכלים הגדולים והיקרים, אלא ללכת על כלי קוד פתוח – Magento (שמבוסס PHP) אל מול NopCommerce (מבוסס דוט נט – לכן גם יותר נפוץ בארץ, אין לנו עדיין המון אנשי PHP). כלומר, זהו אחד המקרים הבודדים בהם ארגונים בישראל מעדיפים קוד פתוח על פני כלים רגילים, בעיקר בגלל ההתארגנות של הספקים המקומיים – מיישמי ה WEB COMMERCE המובילים (EWAVE, רילקומרס, מטריקס, NG SOFT ועוד) תומכים בכלים אלה ויש כבר רשימת פרויקטים מכובדת מאוד.

ב 16.11.15 נקיים מפגש בנושא אסטרטגיות Web, mobile, Ecommerce בו נשוחח על סוגיות אלה.

אתרי ה- Web החדשים – מקבלים "חיזוק" מפלטפורמות מסחר אלקטרוני

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