BI לנתוני SAP - רשמים משולחן עגול

בשולחן עגול בנושא BI לנתוני SAP בו השתתפו ארגונים משתמשי SAP, עלו הנושאים הבאים:

• שימוש ב-BW של SAP כ ETL מובנה לנתוני SAP: במפגש הייתה הסכמה כללית על השימוש הרצוי ב-BW כ'שער' לנתוני SAP. כלומר, גישה לנתוני SAP לא תתבצע ישירות מול ה-SAP התפעולי, אלא בכל מקרה הנתון יילקח מה-BW (עד כמה שניתן). השימוש ב-BW כשער גישה לנתונים הוגדר כ- Best practice. גם במקרה של ניתוח הנתונים שלא באמצעות כלי האחזור של BW, עדיין משתמשים ב-BW כמעין ETL מובנה. כמה ארגונים סיפרו כי הם מוציאים מידע מה-BW החוצה (באמצעות שימוש בכלי מובנה ב-SAP בשם Open Hub) בצורת קבצים שטוחים לדטהבייס חיצוני (אורקל, טרהדטה...) על מנת לנתח נתונים שם עם כלי אחזור שונים אליהם הארגון רגיל.
• סוגיה מרכזית שעלתה: היכן לבצע ניתוחים משולבים המשלבים בין נתוני SAP ונתוני Non-SAP? בשנים האחרונות מגמת שילוב כלי BI / DW / ETL מובנים בתוך חבילות אפליקטיביות (ERP, CRM, ניהול קמפיינים, תכנון תקציב וכד') הולכת וגדלה, מה שמכתיב ארכיטקטורת DW יותר מבוזרת (על פי סקר שערכנו, לכ75% מהארגונים קיים DW מרכזי, ולצידו – מספר דטה מרטים ייעודיים ל ERP וכד'). אולם מה קורה כאשר צריך לבצע ניתוחים משולבים, תוך שימוש בנתונים המגיעים מהDW המרכזי והן מהדטה מרטים הייעודיים? במפגש עלתה שאלה זו כסוגיה מרכזית – היכן מבצעים ניתוחים משולבים? שתי הדרכים האפשריות לניתוח משולב של נתוני SAP בשילוב עם נתונים ממערכות תפעוליות אחרות: העברת נתוני NON SAP ל BW; והעברת נתוני SAP ל-DW הארגוני. במפגש עלו דוגמאות לכאן ולכאן ולא הייתה המלצה חותכת לדרך נכונה אחת, משום שהדבר תלוי בארגון, באופן יישום ה-SAP ובמידת מרכזיותו בארגון. שני פרמטרים עיקריים היוו קוים מנחים לבחירה:
  1. המידה בה הארגון מבוסס SAP (בארגונים מבוססי SAP בהם % הכיסוי של האפליקציות על ידי SAP היה גבוה, הנתונים הועברו ל-BW). אם ה-SAP מהווה רק סביבה לניהול תהליכים אדמיניסטרטיביים ומכסה רק עשרות % בודדים מתהליכי הארגון, בדר"כ בארגונים אלה קיים DW אחר, ולרוב - ביצוע ניתוחים 'משולבים' יבוצעו שם (למעט מקרי קצה בודדים בהם ה-BW מהווה המרכיב העיקרי בניתוח).
  2. שיקול נוסף מוביל – היכן המסה העיקרית של הנתונים? אם רוב הנתונים לצורך הניתוח המשולב נמצאים ב-SAP ורק מעט מגיעים מה-DW הארגוני, הם יועברו ל-BW ושם ייעשה הדיווח, ולהיפך. איפה שהמסה של הנתונים יותר גדולה – שם הם יישארו ויתוחקרו.
  אם אין צורך לניתוחים משולבים, משאירים את נתוני SAP ב-BW (משתדלים לא לשכפל).

נושאים נוספים שעלו:

• ארגונים סיפרו ניסיונות לשימוש בכלי אחזור צד-שלישי מעל סביבת ה-BW.
• במפגש עלו כמה טיפים ושיטות עבודה עליהן ארגונים המליצו. בין ההמלצות שעלו: שימוש ב SAP Portal ושימוש בסביבות עבודה מוכנות (Business packages) של SAP.
• במפגש עלו גם יחסי כ"א ומיקומם הארגוני של אנשי הBW / SAP BI.

רשמים ממפגש שולחן עגול - SAP

מפגש זה היווה גיבוש של קבוצת עניין אשר בעתיד תיפגש בנושאים שונים שמנהלי אפליקציות בסביבת SAP נתקלים בהם. הנושאים העיקריים שעלו במפגש ראשון זה:

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

גודל מחלקת ה-ERP SAP
לרוב הארגונים מחלקות ERP די גדולות לצורך תמיכה שוטפת ב-SAP. מבין משתתפי הדיון, מס' אנשי מחלקת SAP נע בין 10 ל-100, ובממוצע 30 איש. החלוקה לתפקידים השונים:

מיישמים: 60%

מפתחים: 17%

BASIS: כ10%

אחר: 13%

רוב המאמץ מוקדם לחידושים ופיתוחים (כשני שליש) והשאר לתחזוקה. לדוגמה, באחד הארגונים מחזיקים מיישם לכל מודול רק לעניין תחזוקה, ופי שניים לחידושים ופיתוחים.
בארגון אחר 70% שו"שים ו-%30 תחזוקה (שזה הרבה פעמים גם הדרכה). לגבי התחזוקה, בארגון אחד צוין כי מאמץ התחזוקה הרבה יותר קטן - על 3 מודולים מחזיקים מיישם שלהם + חלקיקי משרות מבחוץ.

יחס ERP Staffing למספר המשתמשים
מספר המשתמשים ב-SAP בארגון בממוצע עמד על 1800 משתמשים (נע בין 200 ל 6000). יחס אנשי ה-SAP בארגון (כולל מיישמים, מפתחים תמיכה basis וכד') למס' המשתמשים בממוצע עמד על 1:66 (איש SAP אחד על כל 66 משתמשים ב-SAP), אך הייתה שונות גדולה מאוד מארגון לארגון במדד זה (לדוגמה, ארגון עם יחס של 1:10 לעומת ארגון עם יחס של 1:110).

המודולים שארגונים מתכננים ליישם ב-SAP
צוינו מספר יוזמות שונות שהם מתכננים להיכנס אליהם:
· שדרוגים: ECC, CRM
· איחוד דוחות
· העמקת כניסה לפורטל כולל ESS
· PLM
· SRM ניהול ספקים
· PM מודול אחזקה
· APO – על מנת לעבור לניהול מלאי גלובלי
· העמקת יישומי SOA ויישומי אינטרנט
· שיפור ממשק המשתמש (כיום מסורבל ולא נוח)
· מתכוונים להעמיק שימוש בפורטלים כדי לחזק את ההטמעה

SAP Portal
75% ממשתתפי הדיון כבר עושים שימוש כיום ב- SAP EP, רובם עושים בו שימוש כפורטל תהליכי (שכבת פורטל מעל תהליכים המנוהלים בסביבת ה-SAP), אחד מהמשתתפים עושה בו שימוש כפורטל ארגוני "רוחבי" (מעין אינטרה-נט) בלבד, רק מספר בודד של ארגונים משתמשים בו הן כפורטל ארגוני רוחבי, והן כפורטל תהליכי מעל SAP.

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

• ניהול HD יותר חכם – אחד הארגונים ציין כי את כל ניהול הקריאות עושים כעת דרך ה solution manager, מה שצפוי להוריד את כמות הטלפונים כי התהליך הוא אינטראקטיבי. חלק מהמשתתפים בדיון העלו הסתייגויות לגבי מוכנות המשתמשים לפתוח משם קריאות? עקרונית זה לא צריך לשנות למשתמש. היתרון הוא שהמשתמש מקבל את כל הנתונים של התקלה, השאלה היא אם הוא יאמין בזה ויתמיד בשיטה.
  מערך התמיכה – Help Desk
  קיימות בין 2-3 רמות: 1st, 2nd ולעתים גם 3rd level support:
  · 1st level support (לדוגמה, סיסמה, הרשאות) ניתן על ידי ה-HD, לרוב ה-HD הכללי של ה-IT.
  · 2nd level support - אנשי מפתח במחלקות עסקיות. עשוי להיות יותר מאדם אחד בכל תחום עסקי.
  · 3rd level support – מיישמים. נותנים מענה לתקלות יותר גדולות.
  אחד המשתתפים ציין כי בארגונו בנו מחלקת תמיכה ייעודית ל-SAP שבה יושבים משתמשי מפתח שהועברו למעשה לשבת תחת חסות ה-IT. לא אצל כל המשתתפים הופיעו 3 רמות אלה, בחלקם קיימת ה 1st level support ואחריה ישנם מומחי יישום – שעדיף שיבואו מהמחלקות עצמן. בכל אופן, ברור כי לצורך התמיכה המעמיקה יותר יש צורך להבין תהליכים עסקיים.

שימוש בכ"א חיצוני
בדיון עלתה הסוגיה של שימוש בחברת יישום גדולה לעומת שימוש פרטני ביועצים עצמאיים.
כשעובדים עם חברה גדולה עם חלקי משרות יש יתרון (אם חולה יגיע מישהו אחר) החיסרון – האפשרות שחברה גדולה תשלח כ"א לא מיומן שהחברה מרוויחה עליו עשרות אחוזים.
הצעות שעלו במידה ומשתמשים בחברה גדולה: אם מחליפים מיישם זה צריך להיות בהסכמה, וכן לבדוק אפשרות של קבלת מיישם "JUNIOR" במחיר מופחת/חינם לתקופה מוגבלת של למידה, ולאחר תום תקופת הלמידה לעבור לתשלום רגיל.
לגבי השימוש במיישמים עצמאיים – צויין כי שימוש בכ"א זה בפירוש כרוך בעלויות לא זולות אבל יש אפשרות לקבל כ"א טוב ביותר עם 10-15 שנות ניסיון. הבעייתיות כאן היא השאלה עד כמה ניתן וצריך לסמוך עליהם בזמנים בעייתיים. בחברות הגדולות מרגישים קצת יותר בטוחים במובן זה.
צויין כי ישנם אנשים טובים גם בחברות גדולות ובסה"כ אם משלמים את התעריפים המבוקשים - יקבלו כ"א איכותי בחברות הגדולות גם כן.
האנשים הטובים באמת שווים את התוספת במחיר במיוחד לתחומים בהם חסר ידע. אחד המשתתפים סבר כי לתחומים הפשוטים כמו פיננסי FI MM חבל לקחת חברות גדולות, משום שזה commodity. באזורים של פחות ידע אין ברירה וצריך וכדאי לקחת כ"א יותר טוב גם אם זה אומר שימוש ביועצים פרטיים.
ההבדל בין מיישם טוב למצויין יכול להיות 30% ו 300% בתפוקה בתנאי שיודעים להפעיל אותו נכון. מיישם של 280 ₪ - אפשר להביא אותו פעם בשבוע ולתת לו רשימת X בעיות והוא עשוי לפתור תוך רבע שעה בעיה שאחרים אמרו שתיקח שבועיים. יש תשומת ניהול במקרה ולוקחים יועצים פרטיים, אבל התארגנות נכונה יוצרת ניהול טבעי. אחד הארגונים המשתתפים בדיון סיפר כי בארגונו כך עובדים, והם מזמינים פרילנסרים כאלה שבאים והולכים.
נקודה חשובה שצוינה - שווה לשלם את ה 300 ₪ לאותם אנשים שלעתים מכונים "כוכבים" אבל בתנאי שהיועץ השאיר לא רק את הפיתרון אלא גם את הידע על הפיתרון. כלומר, המצב הרצוי הוא לא רק שיבוא ויפתור את הבעיה, אלא שיהיו איתו אנשים מהארגון שילמדו מה הוא עושה.

BW - BI
אחד הנושאים שעלו בדיון הנו נושא ה-BW. הבעיות שצוינו - זמני גזירות ארוכים מדי ל-BW מאוד גדול (יחד עם זאת, צוין כי לא ייכנסו ל BIA – BI Accelerator בגלל שיקולי עלויות), שני ארגונים העריכו גם כי רמת השירות/יישום של BCS ו-BW בארץ עדיין די נמוכה.
תוארו מקרים של עבודת עלי BI צד שלישי מעל סביבת ה-SAP BW: באחד הארגונים הוטמע כלי BI של qlikview מעל סביבת ה-BW (צוין כי בארגון זה זהו לא כלי אונליין ולא תחליף לדוחות ב SAP), ובשני הוטמעה סביבת Cognos מעל BW (כולל נושא של מדדים KPIs). בשני הארגונים ישנה שביעות רצון די גבוהה.
מוצרים משלימים:
אחד הנושאים שעלו בדיון הנו נושא המוצרים המשלימים לסביבת SAP שיכולים לעזור בעבודה יותר יעילה, לקצר זמני תחזוקה והדרכה. הכלים שצויינו:
· Epiuse (נציגה בישראל: נס) מסייע בתהליכי גזירה סלקטיבית, שולפים אוכלוסיה ספציפית מה-SAP.
· קוגנוס – צויין שימוש בקוגנוס מעל תשתית ה-BW בשילוב עם תשתית נתונים אחרת לצורך BI, וכן KPIs, BSC - מפה אסטרטגית עם מדדים מקושרים. צוין כי החיבור ל-SAP היה קל.
· Itemfield כמיפוי לטובת ה-XI.
· IXOS (Open Text) - לארכוב מסמכים.
· Zoptions (בייצוג נס) לקליטה של פקודות יומן (יכול להוציא מהאקסל לפקודות יומן).
· זירוקס - OCR עם תמיכה בעברית.
· Printboss – לעיצוב פלטים וגם צוין שימוש בכלי לצורך תרגום שפות (מחזיקים ב SAP רק באנגלית).
· בבילון – ככלי שחוסך זמן ומעלה רמת אפקטיביות ארגונית

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

מודול אחזקה - PM
בדיון דובר ספציפית על מודול אחזקה (הן לצורך אחזקה מתוכננת והן לאחזקת שבר) ומידת בשלותו, ותהליך ההטמעה שלו. רוב הארגונים תיארו כי לפני השימוש במודול זה נעשה שימוש בעוצמה 10 (מוצר בתחום האחזקה).
מספר ארגונים סיפרו כי מודול ה- PM נותן להם מענה טוב לצרכים (הן תחזוקת שבר והן מתוכננת) וכי הדבר החשוב ביותר היא מיהו המיישם ומשתמש המפתח – צריך שיהיה אחד שמבין את הראש של SAP ויודע מה התהליכים העסקיים. צוין שימוש בPM גם לספירת ציוד (שכבר הופחת אבל קיים). בחלק מהארגונים לא כל נושא התחזוקה עבר ל-PM (לדוגמה, תחזוקת IT) אך ברובו כן.
היתרון שצוין לשימוש במודול PM הנו האינטגרציה עם המודולים הפיננסים, כמו כן צוין כי ניהול סריאלי – נוח ב PM, וסוכם כי זהו מודול פשוט יחסית ולא מורכב. שימושים שצוינו במודול זה (לדוגמה):
· ניהול צי רכב של רכבים כבדים – אחזקת שבר ומונעת: הפעילו מוקד מנהלות, כל הקריאות מנוהלות, כולל שליחת SMSים. הפעילו PM על ניהול עבודה דיווח פרויקטים ותחזוקה.
· ניהול מלאי של רכיבים וברגים.
· חיבור למערכת ייצורית (פתיחת פקודת אחזקה כאשר יש בעיה במכונה)
· הכנסת PM לניהול מתקני הרמה (בשל רגולציה). היישום התנהל ללא קשיים ובכ"א מינימלי (מיישם אחד עם יועץ junior) הלכו על הסטנדרט (לא עשו פיתוחים).

לצפייה/הורדת סיכום הדיון המלא לחצו כאן.

ארכיטקט ERP – תפקיד חדש בארגון?

הארגונים העוסקים ב ERP לרוב מכירים את המונח (ERP COE (Center of Excellence שמהווה מרכז ההתמחות של ERP בארגון. זה הפך להיות best practice לארגונים העוסקים ב ERP (ובמיוחד אלה המשלבים את ה ERP בפעילויות הליבה שלהם) להקים COE שמעבר למתן שירותי תמיכה "סטנדרטיים" גוף זה מתווה מפת דרכים להתפתחות ה ERP בעתיד, נמצא עם יד על הדופק בנוגע להתפתחויות עסקיות חדשות, בוחן את אופן ההטמעה, וחלק מתפקידו של ה-COE הנו גם התעדכנות לגבי ה roadmap העתידי של ספק ה ERP, מה שנעשה לרוב על ידי קשר הדוק עם הספק עצמו, התעדכנות על ידי אנליסטים ויועצים, וכן שותפות בקהילות משתמשים שונות.

יחד עם זאת, בארגונים לאחרונה צומחת פונקציה חדשה שנראה שרק תלך ותהפוך ליותר ויותר חשובה הן בעולם ERP והן בעולם הIT הקלאסי – Enterprise Architect (לעתים מתייחסים לתפקיד זה בתור ה CTO החדש, בניגוד ל CTO שאנו מכירים כיום שמרוכז בעיקר סביב נושאים תשתיתיים). תפקידו של הארכיטקט הנו להוות תווך בין הצרכים העסקיים המשתנים של הארגון ובין אופן התפתחות ה-IT, כולל התוויית תכנית עתידית וגיבוש ארכיטקטורה. כמו כן, חלק מתפקיד הארכיטקט/CTO הנו לבחון טכנולוגיות חדשות, כאשר היתרון העיקרי הוא שלפונקציה זו יש מידע עדכני לגבי הצרכים העסקיים של הארגון – לאן הארגון רוצה להגיע, אילו שירותים המחלקות העסקיות צריכות, סדרי עדיפויות בין הצרכים השונים. פונקציה זו – הארכיטקט – לרוב כפופה למנמ"ר.
תיאור תפקידי ארכיטקט הERP (לקוח מתוך אתר של קהילת Netweaver) ניתן למצוא כאן.

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

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

• הגדרה של פונקצית ה-CTO/ארכיטקט – ישנם ארגונים בהם ישנה הגדרה ברורה של CTO וארכיטקט, כאשר בד"כ הפונקציה של CTO הנה ותיקה יותר ובכירה יותר. באופן כללי, ה- CTO אחראי על בחירת טכנולוגיות בארגון באופן כללי (מהו הסטנדרט שיהיה מקובל בארגון ?) והארכיטקט אחראי על בחירת טכנולוגיות ספציפיות לפרויקט (באיזה שרתים ואחסון ישתמשו לפרויקט ספציפי- ERP? האם יהיה שימוש ב- CLUSTER? וכו'). ישנם ארגונים בהם התפקידים של CTO וארכיטקט הנם תפקידים מקבילים, כאשר ה- CTO עוסק בתשתיות והארכיטקט עוסק באפליקציות\תוכנה. ישנם גם ארגונים בהם תפקודי ה- CTO או הארכיטקט מהווים חלק מתפקידו של מנהל התשתיות.
• מעורבות הארכיטקט\CTO בפרויקטים חדשים – ישנם ארגונים בהם ישנו תהליך מובנה וברור של התנעת פרויקטים חדשים בהשתתפות נציגי גוף ה- CTO\ארכיטקט. לעיתים ההתנעה מלווה בהליך של Architecture Review ולאחר מכן בתהליכים של Design Review. מצד שני, ישנם ארגונים בהם תהליך זה לא קיים כלל או שלחילופין, השתתפות נציגי גוף ה- CTO\ארכיטקט הנה וולונטרית – כלומר, על פי הצורך. אז מתגלה לעיתים שישנה בחירה בטכנולוגיה לא מתאימה או פיתוח של פונקציונאליות שכבר קיימת בארגון. ברוב המקרים פרויקטים גדולים זוכים במלוא תשומת הלב, אולם פרויקטים קטנים או לחילופין פרויקטים דחופים לא עוברים במסלול המלא וגם אז מתגלות בעיות – כשהפרויקט נמצא כבר בייצור\תחזוקה ואז כמובן עלות התיקונים גבוהה. כלומר, ישנה חשיבות גדולה לעובדה שה- CTO\ארכיטקט יהיה דמות שרוצים להתייעץ איתה ולא מאוימים על ידה. הערה חשובה: אין ספק שתהליך מסודר ומובנה של התנעת פרויקטים מעכב את הפרויקט ויוצר תקורות. אכן, נציג אחד הארגונים היעילים בתחומו (לעומת ארגוני IT מקבילים בתעשייה) ציין שבארגונו לא קיים תהליך מובנה וכבד. חשוב לציין שבפורום זה של CTO וארכיטקטים לא נשמע קולם של מנהלי הפרויקטים שעשויים להתלונן על "בירוקרטיה" באישור הפרויקט...
• אכיפה – רוב הארגונים ציינו שבכל מקרה לא מדובר באכיפה קפדנית של החלטות (והסטנדרטים) של ה- CTO\ארכיטקט. הסיבה לכך היא קיומה של דילמה בין האכיפה של סטנדרטים והמלצות של גוף ה- CTO\ארכיטקט לבין האינדיבידואליזם של הפרוייקטור\מפתח. ברור שלא רוצים "לדרוס לגמרי" את האינדיבידואליזם.

מה קורה כשספק פתאום מעלה את אחוזי התחזוקה?

SAP הודיעה בחודשים האחרונים שהיא תעביר באופן הדרגתי את לקוחותיה למדרגת תחזוקה יותר גבוהה, מה שאומר שהיא תעלה הדרגתית את עלויות התחזוקה שלה מ 17% (לארגונים שהשתמשו בחבילת התמיכה הבסיסית) ל-22% עד 2012.

מאז הידיעה שיצאה בחו"ל, יצאו עוד כמה ידיעות שמראות שארגוני משתמשי SAP מאוד לא מרוצים מהמהלך.

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

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

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



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

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