‏הצגת רשומות עם תוויות enterprise resource management. הצג את כל הרשומות
‏הצגת רשומות עם תוויות enterprise resource management. הצג את כל הרשומות

יום שבת, 4 בספטמבר 2010

Vanilla - with chocolate chips - an article from Oren Teich

Here is an interesting analysis written not by myself - but by Oren Teich, AVP Application Manager in Comverse, about the "Vanilla versus Tailored" dilemma. I have written and talked about this issue for several times. In this analysis, Oren adressed this dilema and offered an intermediate approach - Vanilla with chocolate chips (but chocolate chips should be used wisely, only when needed and not extensively):

"For years, IT organizations have operated under the assumption that they should develop information systems based only on the requests given by internal customers and believed that this approach will best serve the organization's needs. Companies whose business processes and work-practices are based on non-standard approaches and the whims of managers quickly find themselves developing non-standard enterprise information systems. This approach has led IT organizations into managing Application Portfolios comprising dozens of proprietary systems that contain millions of lines of proprietary code that is based on the wide use of proprietary interfaces.
Many challenges and difficulties have brought IT professionals to look for new strategies that will serve today’s dynamic, global organization in ways that are more extensible, cheaper and less dependent on a specific manager and that will produce higher quality solutions in less time and with less effort. Among those challenges are the high development costs followed by growing support costs of proprietary solutions. Moreover, it takes a long time for organizations to implement changes (Time to Market) in today's dynamic business environment. IT is unable in this complex situation to easily interface to external systems. More and more this situation forces IT to be dependent on specific knowledge and unique resources.
One strategy that addresses these problems is the Vanilla approach. This approach is based on the view that dedicated companies in their respective areas of expertise represent the best practice of their industry and what's good for the entire industry is a good match for any other organization. The Vanilla approach is executed by implementing platforms and systems that provide the organization with a very high percentage of the company’s requirements. This is done without the need to heavily customize the software or engage in massive R&D projects.
These platforms and applications are implemented by field experts that help the IT organization to align with industry standards. Vendors, each in his respective area of expertise, continue to evolve their solutions and their underlying infrastructure while adapting to ever changing technologies. Therefore they reduce the organization's dependence on constantly “running” after issues that are not the organization’s core activity. Implementing these standard solutions significantly reduces the time it takes the IT organization to provide solutions to the business. It reduces support costs, allows flexibility with resources and provides long-term support and up-to-date solutions in each business process area.

The research company “Computer Economics” published a study in 2008 showing that the ratio of support staff for ERP systems versus business customers is 1:28 for environments categorized as “Many/Extensive Customization”. The ratio significantly grows to 1:36 in “None/Low Customized (Vanilla)” ERP implementations. It can be concluded from this study that there is a positive impact on other areas such as infrastructure, quality and availability, and therefore ROI improves respectively. Thereby we can see a significant reduction in the solution’s total cost of ownership (TCO).
The most difficult challenges to implementing enterprise systems based on this Vanilla approach are customer “buy-in” and the acceptance of this approach when the “off-the-shelf” solution does not exactly meet all of the customer's wishes. Moreover, organizations are challenged to overtake new business processes and adopt them as they come with the platform. In order to minimize the risks inherent in these strategic challenges strong support is needed from the organization's management. This should be done by emphasizing the many benefits of this approach vis a vis the approach based on developing and supporting proprietary solutions.
Given all the above, there are some exceptions ("The Chocolate Chips") to the Vanilla approach. The organization should not give up on customization in the areas where such customization provides a significant competitive advantage. “Chocolate Chips” may be added to the Vanilla approach in small and significant areas. “Chocolate Chips” should be used only when they provide significant added-value, are relatively inexpensive to “acquire” and they will not incur disproportional costs as the business processes evolve.
Another "flavor" of the Vanilla approach is the combination of SAAS (“Software As A Service”) solutions and Cloud solutions. These solutions are managed outside the organization by sharing software and hardware resources with many other customers around the world. This makes it difficult (and in some cases impossible) to add. “Chocolate Chips,” i.e., implement enhancements in the application to meet unique requirements.
To conclude, the “Vanilla with Chocolate Chips” approach is an administrative guideline supporting IT’s strategic decision-making process in managing an IT organizations’ application portfolio. This approach counters the "we do things differently here…" and provides solutions with a lower TCO and higher ROI than the current proprietary approach deploying applications. Organizations are learning to live with “out-of-the-box” solutions and on the other hand they are profiting from the many advantages that come with this “Vanilla with Chocolate Chips” approach. "

יום שני, 5 ביולי 2010

ERP Trends

חלק מהמצגת שהעברתי בכנס השנתי שלנו לגבי מגמות ERP:

יום שני, 11 בינואר 2010

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.

יום שני, 14 בדצמבר 2009

What's next for SAAS after CRM? HR related functions

The Israeli market was slow to adopt SaaS solutions. Slowly but surely, there are several hundred organizations now using SaaS solutions in areas such as CRM, Web 2.0 (Wikis, blogs), and ERP.
So what's the next solution organizations will be willing to consider in SaaS delivery model? I think HR-related processes are a good candidate. The (slow) adoption process taking place in Israel is actually quite similar to the U.S market just a couple of years ago.
Looking at the worldwide market, SaaS or on-demand HR solutions were typically implemented in Small-medium sized organizations (in the past these were more of an ASP model) but are also starting to make an impact in large organizations.
HR functions are often "outsourced" functions, sometimes even used in a BPO model. This is one of the reasons the SaaS delivery model for HR software is appealing even for larger organizations.
At the moment it seems that certain HR functions in particular are being used in the SaaS model (for example, e-recruitement, payroll, employees performance management, e-Learning) as opposed to outsourcing the full set of HR functions.

Traditional HCM vendors are moving more and more into the on-demand space and offering a choice between on and off premise models.
Cutter Consortium's recent SaaS survey clearly shows that organizations of all sizes are taking advantage of a wide array of horizontal (i.e., functional) and vertical (i.e., industry-specific) SaaS applications. The growing interest and adoption of SaaS by corporate users is encouraging SaaS alternatives to traditional packaged applications to emerge in virtually every software category. In this survey, most organizations that were asked what type of horizontal apps they're considering using or already using in the SaaS delivery model, HR functions were quite common (right after CRM, Content Management & collaboration).

Here are some examples of several prominent worldwide SaaS HR vendors (or vendors that most of their income comes from the saas model):

Workday - a relatively new provider of ERP-like on demand solutions, centered around HR, payroll and financials. It's founder was Peoplesoft's leader so this created a "buzz" in the HR space...
Kenexa - e-recruitement and employee performance management
Ultimate Software - is doing well in the large organizations' space, offers both on and off premise models.
Salary.com - for talent management, compensation, payroll
Cornerstone - on demand HCM and Talent management, compliance is considered a strong point in this solution.
Learn.com - mainly SaaS. Learning management and HCM.
Nuview - Not a pure Saas solution but now about half the revenues come from the saas model, mainly aimed at midsized companies
Skillroad - recruitement and skills management, mainlly targeted at midsized organizations
Successfacors - employee performance management in SaaS, have some presence in Israel.
Taleo - erecruitement and talent management, have some presence in Israel.
Authoria - erecruitement, assessment and performance management.
How will these solutions be accepted in Israel? What will be the adoption level? my guess is that the same type of clients that adopted CRM Saas solutions - technological/ global companies and also SMBs will be the more natural candidates. Most companies have "some sort of HR system" in place but the implementation is usually very basic, and doesn't include things like recruitement, incentives management, performance, skills and talent management. So there is a lot of potential for this type of solutions in Israel. Many other factors will affect the Israeli's CIO decision: Hebrew support, localization, price, local support (viable integrators that can support the product for the long run) are just a few of these factors.

יום רביעי, 30 בספטמבר 2009

To ERP or not to ERP?

בכמה שיחות עם ארגונים שעדיין לא נכנסו לERP ושוקלים את צעדיהם בתחום עלתה השאלה – האם כיוון הERP הוא כיוון שכדאי לקחת היום, לאור הניסיון הרב הנצבר, או שכדאי להשקיע בתחומים אחרים שיניבו ערך עסקי גבוה יותר?
במקביל, בשנה האחרונה שוחחתי עם שני ארגונים שכבר יישמו ומפעילים מערכות ERP, ושוקלים האם בדיעבד הכניסה של הארגון לתחום ה ERP הייתה כדאית (שאלה שמחלקת הIT קיבלה מההנהלה הבכירה)? מהן התועלות שהתקבלו?

אני מחלקת את פרויקטי ה ERP לשני סוגים (חלוקה הכרחית כדי לענות על שאלות אלה):
ERP 1: זהו הERP הקלאסי שכולל את התחום הפיננסי, הלוגיסטי ומשאבי אנוש. בתחום זה ארגונים מעוניינים להיות "סטנדרטים" ולעבוד בצורה דומה לזו שארגונים אחרים עובדים. עוד לא פגשתי ארגון שראה תועלת בפיתוח של מערכת הנהלת חשבונות ייעודית לצרכיו הספציפיים. להערכתי, כאן אין שאלה וברור שיישום ERP הנו הצעד הנכון – תחום ה ERP מספק את ה best practices / התהליכים הארוזים הג'נריים, שדומים וצריכים להיות דומים לאלו שמנוהלים בחברות אחרות. קטלוג סוג התועלת העסקית המתקבלת ממערכות ERP תחת קטגוריה זו, לדעתי, אינה צריכה להיות "חיסכון בעלויות פיתוח המערכות", או חיסכון בעלות הממשקים בין מערכות שונות, וגם לא בכיוון של התייעלות הארגון וחיסכון בעלויות, אלא לדעתי צריך להסתכל על מערכות ה ERP כמערכות תשתית לכל דבר – תשתית אפליקטיבית הכרחית. לאחר יש פה גם את האלמנט של "יישור קו" עם התעשייה. לדעתי, הערך העסקי עליו ארגונים דיברו בכניסה לפרויקטי ה ERP מגיע אח"כ, בשלבי ה ERP הבאים... אבל כדי להגיע אליהם צריך ליישם את אותה תשתית אפליקטיבית – ה ERP 1 – זהו הבסיס ממנו ניתן לצמוח הלאה.וכאן אני רוצה להדגיש את ההמלצה שכבר הפכה להיות שחוקה, אבל היא כ"כ נכונה, במיוחד לאור זאת שמדובר על תשתית אפליקטיבית שאמורה להיות די דומה מארגון לארגון – להיצמד עד כמה שניתן לחבילה. בישראל אנו נוטים לבצע שינויים רבים בחבילות מדף, ובתוכן גם חבילות ERP (עפ"י נתון באדיבות NessPro– המתבסס על מוצר בשם Intellicorp אותו היא מייצגת בישראל, ארגונים משתמשי SAP מפתחים כ-30% קוד מקוסטם לעומת סטנדרטי! זהו נתון מדהים כשלוקחים בחשבון שההמלצה היא לשקול פיתוח אם מדובר על שינוי של מעבר ל10-15% בחבילת המדף). מבדיקות שעשיתי לאחרונה על יחסי כוח אדם במחלקות ERP ראיתי קשר ברור בין רמת הקיסטום של הERP לגודל מחלקת הERP שתומכת בו לאורך זמן. אין ספק שארגונים שנצמדו לסטנדרט הרבה יותר יעילים ביחסי כ"א שלהם לעומת ארגונים שפיתחו דברים ייחודיים, וגם הרבה יותר גמישים "לשחק" עם נושא ה sourcing (להשתמש בחלקי משרות חיצוניות במקום להחזיק אדם פנימי במשרה מלאה לנושא מסוים פשוט כי הוא "מכיר את הייחודיות של הארגון שלנו").

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

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

יום שני, 7 בספטמבר 2009

טיפים ליישום פרויקט ERP

להלן כמה טיפים שנלמדו כתוצאה מפרויקטי ERP רבים שהתבצעו בישראל:
  • לבחור היטב את אנשי היישום של הספק (לבדוק המלצות ויישומים קודמים), הדבר במיוחד נחוץ כאשר סוגרים פרויקט ב “Fixed". לדרוש אנשים ספציפיים עד כמה שניתן, גם אם זה אומר עלות גבוהה יותר. ארגונים רבים הדגישו כי איכות וניסיון אנשי היישום מהווים גורם מכריע בהצלחת היישום, ועמידה בלו"ז.
  • מה שכבר נשמע כמו המלצה שחוקה לחלוטין מוכיח את עצמו - השלב הראשון של היישום צריך להיות כמה שיותר "סטנדרטי" (לנסות להיצמד לחבילה ולא לבצע שינויים רבים). לאחר שימוש של 2-3 שנים במערכת, המשתמשים הרבה יותר יודעים להגיד מה הם רוצים ואיך הם רוצים וצריכים לעבוד. ארגונים רבים נמצאים כעת בשלב זה.
    כמו כן, יישום סטנדרטי יסייע משמעותית בהמשך הדרך להוריד עלויות תחזוקה ותמיכה שוטפות. מסקר יחסי כוח אדם שביצענו בישראל עלה בצורה ברורה כי בארגונים בהם נצמדו יותר לסטנדרט, מחלקת ה ERP משמעותית קטנה יותר מארגונים בהם פותחו שינויים רבים והמערכת הותאמה משמעותית לצרכי הארגון. אין זה מפתיע, שכן הדבר משפיע ישירות על יכולת הארגון לעבוד מול ספקי תחזוקה חיצוניים. כשהיישום הנו סטנדרטי אפשר להיעזר בכ"א חיצוני בצורה יותר תכופה, מה שיכול לסייע בעבודה במודל של חלקי משרות במקום החזקת אדם במשרה מלאה לתפקיד ייעודי. בארגונים בהם היישום כ"כ ספציפי לאותו ארגון, אין ברירה אלא להחזיק אדם שמכיר את היישום והארגון ולא ניתן להחזיק אותו ב"רבע / חצי משרה". נציין כי בישראל רמת השינויים שארגונים מבצעים במערכות הERP (ובכלל) הנה גבוהה משמעותית מזו המקבילה בחו"ל. בהמשך אקדיש לכך פוסט מפורט.
  • תמיכה לאחר עלייה לאוויר – משתמשים ציינו כי זהו נושא בעייתי שלרוב אינו מתוקצב / מוערך באופן מספק. תמיכה של חודש לאחר עלייה לאוויר לא מספיקה! זוהי התקופה שהארגון מתחיל לעכל "מה נחת עליו", משתמשים רק מתחילים להשתמש, ורק אחר כך מתחילות הבעיות והבדיקה בפועל של כל התהליכים שתוכננו. כל דבר שעושים בפעם הראשונה צריך ללוות את המשתמש. למודולים הקשים היו לקוחות שציינו כי היו צריכים ליווי של 4-6 חודשים.
  • בפרויקטים כיום אני ממליצה בחום לבחון שימוש בכלי EPSS – Electronic performance support system או כלים אחרים המסייעים בתחום של הטמעה ולמידה מתמשכת. כלים אלה יכולים לסייע בהפחתת עלויות הדרכה ראשוניות ושוטפות, והנם כלים יעילים להדרכת והנחיית המשתמשים תוך כדי ביצוע הפעולות ברמה תפעולית.
  • לתקצב ו/או לפרט בחוזה באופן פרטני את נושא ההדרכה –במיוחד בעייתי כשמדובר במספר גדול של משתמשים. אנחנו כל הזמן שומעים מלקוחות שתקציב ההדרכה היה נמוך מדי ולא נלקח בחשבון. היו מקרים בהם הספקים "ספגו" את רוב הפער אבל לעתים הארגונים עצמם. ישנם לקוחות שציינו כי הם לא חשבו לתקצב דברים כגון עזרים טכניים, הדפסת חומרי הדרכה... ארגונים אחרים הניחו ששיטת ה Train the Trainers תספק אותם ובפועל זה לא הספיק.
  • ארגונים עמם שוחחתי המליצו כי אותם אנשים שמשמשים חלק מצוות היישום הפנימי בשלב הקמת הפרויקט ישמשו חלק מצוות ה- Center of Excellence של הפרויקט לאחר עלייתו לאוויר.
  • נושאים שבעבר לא תוקצבו וכיום מקבלים יותר חשיבות: הסבת נתונים, טיוב נתונים ובדיקות. אלה פרויקטים חשובים בפני עצמם.
  • המלצה חשובה אשר לפני כמה שנים לא ממש הייתה רלוונטית: להתחיל מראש, כבר בשלב הראשוני, עם BI ופורטל. לא לחכות ל"שלב ב". שילוב ה-BI כבר בשלב הראשוני מאפשר לקבל "תוצרים" מהיישום באופן מהיר, והפורטל צריך להיבחן ככלי המאפשר סביבת עבודה יותר נוחה למשתמשים. יש לבדוק אילו רכיבים פורטלים קיימים ניתן לקבל מראש מהספק (לדוגמה, בתחום הרכש וה HR לרוב ישנם "פורטלטים" מוכנים/סביבות עבודה מוכנות). מניסיון לקוחותינו, סביבת פורטל מעל ERP משפרת משמעותית את יכולת העבודה מול המערכת ומקצרת תהליכים "מסורבלים".

המלצות שונות נוספות ניתן למצוא:

1. כאן

2. כאן

3. כאן

יום שלישי, 31 במרץ 2009

ERP בשנת 2009

ב"גרף הבשלות הטכנולוגית" שלנו ניתן לראות קטלוג רמת הבשלות של הכלים בישראל (ציר X), ומצד שני קטלוג התועלת בעיני המנהלים העסקיים של הארגון מאותם פרויקטים (ציר ה Y). ניתן לראות שבתחום ה-ERP, הפרויקט שאנו מגדירים אותו כERP1 נתפס בעיני מנהלים עסקיים כשירותי - commodity שעל הארגון לספק לו, סוג של תשתית שצריך שתהיה. הערך העסקי הישיר אינו ברור. להערכתנו, מעל 85% מארגוני enterprises בישראל כבר עושים שימוש בחבילות ERP לצרכים גנריים - הנהלת חשבונות, לוגיסטיקה, כוח אדם ("ERP 1"). אולם "פרויקט" ERP אף פעם למעשה לא מסתיים, ולאחר ייצוב המערכת ארגונים בדרך כלל נכנסים ל"שלב ב" (ERP 2). שלב זה של היישום כולל אחד או כמה מהמאמצים הבאים:


  • שימוש במודולים "מתמחים" / "מתקדמים" – בעוד שבעבר ניתן היה לתחום ביתר קלות את התחום בו מפסיק ה-ERP ומתחילות מערכות ליבה ומערכות אחרות, כיום חבילות ה-ERP כוללות (גם אם לא תמיד באופן המיטבי) יכולות שקשורות לעסק הליבה של הארגון, יכולות CRM, יכולות סביב ניהול שרשרת האספקה, וכן כל מיני מודולים "מיוחדים" שבעבר ארגונים לא שיערו שיוכלו לקבל ממערכות ה ERP, כגון: ניהול נכסים, ניהול פרויקטים וכד'. כאן אנו רואים כוונה של ארגונים להמשיך יישום של מודולים שתוכננו לשלב ב (כל אחד עם תוכנית משלו, לא ראינו מודול ספציפי עליו רוב הארגונים דיברו כשלב ב). תכניות להכנסת מודולים ורטיקלים המטפלים בליבה של הארגון יהיו הרבה פחות נפוצים בשנה בה ארגונים נמנעים מפרויקטים בעלי סיכון גבוה.
  • שילוב רכיבי תשתית בERP – השימוש ברכיבים אלה (DW משולב, פורטל, מנוע אינטגרציה משולב) הולך וגדל אולם מציב לא מעט שאלות ארכיטקטוריות, כגון: ה-DW הארגוני אל מול ה-DW של ה-ERP? הפורטל הארגוני אל מול פורטל ה-ERP? רוב הארגונים בוחנים (או כבר בחנו) שאלות ארכיטקטוריות אלה, ולרוב התשובה תהיה: גם וגם. ארגונים אלה מנסים לתכנן את הארכיטקטורה הארגונית בהתאם, ולקבוע את ה"גבולות" בין הרכיבים השונים.
  • ניסיון לייעל תהליכים האופרציית ה-ERP. מחלקות ה ERP הגדולות בקרב ארגונים המשתמשים בחבילות הגדולות (SAP / אורקל) מונות בממוצע 15-20 איש, וארגונים מספרים כי עם העלייה לאוויר וכניסה לשלבים המתקדמים מס' אנשי התמיכה לא יורד ולעתים להיפך. ארגונים כיום מנסים למצוא כל דרך לצמצם עלות התחזוקה, הדרכה, שינויים, להכניס יותר "סדר" בתהליכי הפיתוח, וגם בוחנים כלי צד ג' שיכולים לעזור לעשות כך. ארגונים ציינו כי ככל שהם נכנסים יותר ויותר לארכיטקטורת SOA ולרכיבים חדשים של מערכות ה-ERP (מודולים הכוללים רכיבים תשתיתיים מובנים כגון פורטל כשכבת התצוגה, מנוע BPM מובנים, שירותי BI משולבים) נדרשת עלייה בכוח האדם התומך ומתחזק את המוצר, וגם נדרש כוח אדם ספציפי המתמחה ברכיבים חדשים-יחסית אלה.
    ארגונים מנסים לבחון כיום דרכים חדשות לצמצום כ"א הנדרש לתחזוקה השוטפת של ה-ERP, ושוקלים יותר בימים אלה שימוש בכ"א חיצוני מאשר בעבר. שימוש בכ"א חיצוני לתחזוקת ERP נשקל יותר על ידי ארגונים שצריכים "חלקי משרות" ולכן לא שווה להן להחזיק משרה מלאה בשביל כמה שעות בשבוע, וכן על ידי ארגונים בהם היישום די סטטי (לא משתנה בתדירות גבוהה מאוד ולכן גם היישום די סטנדרטי ולא דורש היכרות מוקדמת מעמיקה עם הארגון).



ב-2009 ארגונים ינסו לייעל את התמיכה ולמזער עלויות סביב ה-ERP הקיים, וכן להעמיק את יישום ה ERP לתחומים נוספים בארגון (שכן ברוב הארגונים "תשתית ה ERP" קיימת).

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

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

יום רביעי, 25 בפברואר 2009

רשמים ממפגש שולחן עגול - 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) הלכו על הסטנדרט (לא עשו פיתוחים).

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

יום שני, 16 בפברואר 2009

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

בדר"כ מפגשי שולחנות עגולים שאנחנו עושים סובבים סביב תחום טכנולוגי - ניהול מסמכים, BI, ERP, CRM, ולא סביב סביבה טכנולוגית ספציפית (אורקל/סאפ/מיקרוסופט...). החלטנו לחרוג ממנהגנו ולערוך 2 מפגשים מקבילים:
  • מפגש למנהלי אפליקציות בסביבת Oracle Applications
  • ובמקביל - מפגש למנהלי SAP
במפגש הראשון (מסדרת מפגשים צפויים עתידיים) שנערך בנושא Oracle Apps, נושאי הדיון שעלו: סוגיות סביב מחלקת ה-ERP, סוגיות תמיכה במשתמשים, מדיניות שדרוגים, ניהול תצורה וגרסאות - עלה כנושא חשוב ביותר, תהליך טיפול בדרישות לשינויים, תחזוקה, כלים משלימים מספקים אחרים. את סיכום המפגש המלא תוכלו למצוא כאן.

הנה מידע (חלקי) לגבי כמה מהנושאים שעלו:

מבנה מחלקת ה-ERP - Oracle
בארגון ה IT לרוב קיימות מספר מחלקות פיתוח ומחלקת הERP מהווה רק אחת מהן, לצד מחלקות CRM, ליבה/בילינג/בנקאית, BI (וזה במקרה בו ה ERP מהווה "עוד מערכת" ולא המערכת העיקרית). לעתים קיימות מחלקות "רוחביות" נוספות (לדוגמה, מנהלי פרויקטים רוחביים).
בתוך מחלקת הERP, ישנה חלוקת תפקידים ל:
1. מיישמים (לרוב מתפקדים גם כתומכים),
2. תכניתנים (ERP ו CRM – צוותים שונים),
3. אנשי "תשתיות ייעודיות"/DBAs.
חלוקה נוספת הנה מקצועית - אנשי לוגיסטי, פיננסי, HR.


יחסי כוח אדם
אחוז אנשי מחלקת הERP מכלל אנשי ה-IT נע בין 3% (בארגון בעל יחידת IT מאוד גדולה ובו ה-ERP אינו מנהל את ליבת הארגון) ל-20% (בארגון בעל יחידת IT קטנה יחסית וERP שמנהל את ליבת הארגון).
מתוך צוות הERP: 65% אנשי יישום ותמיכה, 35% אנשי פיתוח ו-DBA
יחס של בין 1:20 ל1:50 (על כל אדם אחד במחלקת ה ERP יש 50 משתמשים בERP)

שימוש בכ"א חיצוני
רוב משתתפי הארגון משתמשים בכ"א חיצוני במידה מינורית. בין היתרונות שצוינו – כוח האדם החיצוני מקדם מבחינה מקצועית את צוותי הפיתוח.


ניהול תצורה וגרסאות
צוין כי נושא ניהול השינויים קיים באופן מאוד חלקי באורקל, הנושא שחסר באופן מיוחד הנו נושא העברת גרסאות. בארגונים שונים פותחו יכולות סביב זה או שמשתמשים במוצרי צד שלישי (כמו לדוגמה מוצר של חברת Unitask). בגרסאות הבאות לאורקל יהיה כלי לניהול enterprise manager. יהיה סוג של addon שם לאורקל APPS.
מספר הקסטומיזציות שארגונים היותר גדולים במפגש ביצעו נע בין 900 ל 1900. אופן
ניהול שינויים אצל אחד מהמשתתפים – כל פיתוח מנוהל כקסטומיזציה, כל קסטומיזציה באיפיון "מתגלגל" (מתקדם בגרסאות). יש להם מערכת ניהול תצורה Starteam שבה הם מנהלים את הקסטומיזציות.
כל כמה זמן מעבירים שינויים לפרודקשן? בארגון בו ל IT יש יותר כוח אל מול הארגון שינויי ה ERP מועלים במסגרת "גרסת IT" כל 3 חודשים (כלומר, כל המערכות עולות באותו יום, ה ERP לא עולה בנפרד). ארגונים אחרים ציינו שדבר זה לא יתקבל בארגונם וכי לוחצים עליהם לשחרר גרסאות יותר מוקדם.
רוב המשתתפים עובדים ב 4 גרסאות שנתיות. אצל אחד מהם משתדלים בכל חודש להעלות מיני גרסה ופעם ברבעון להעלות גרסה גדולה. משתמשים ב HARVEST לאריזה (העברה של תכנה). אם יש setups שניתן להעביר דרך תשתית אורקל.

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

בהמשך אעלה גם את סיכום השולחן העגול בנושא SAP.

יום חמישי, 12 בפברואר 2009

Is the Enterprise ERP market entering a "freeze" period?

I recently talked to organizations on their next ERP initiatives, and have also checked with IT vendors about their plans for ERP in 2009. Here's what I'm hearing from both sides:
From the user perspective:
  • Maintaining the ERP and keeping it going costs a lot. The typical israeli ERP department (this mainly refers to SAP and Oracle shops) includes 10-20 people, and getting these numbers down is very hard. If anything, I think this number increases as these packages spread into more functional areas (more modules) and technological areas (Portal, BI, EAI etc) since the complexity is growing.
  • Most organizations prefer to stretch the need to upgrade, I think we will see less upgrades in the coming year (unless the vendor announces end of standard support for older versions). This is inline with the common trend these days for enterprise apps - if there' no clear ROI, we won't do it.
  • More opennes to ideas, 3rd party tools and delivery models that can help them keep maintenance/training/development/support costs down.
From the vendor perspective:
  • Not many "new" large scale projects planned for 2009
  • Vendors are counting on the fact that some users will have to upgrade to newer versions... I think some will rethink this decision.
  • New modules that haven't yet made the big break: compliance/GRC, financial planning, vertical modules (core banking, core insurance) etc.
  • Vendors are trying to find ways to help organizations be more effecient in their ongoing ERP operations.
So what is happening?
This will probably be a slow ERP period. Some organizations' I've talked to were planning to start they're ERP projects this year but some say they might need to push it back because of limited resources and a difficulty in proving a valid ROI.
The main challenge for user organizations in 2009 will be balancing the need to keep and maintain existing applications ("keep the lights on") but also providing services that help the organizations change (in order to survive) and grow. As a result, they will look for practical ways to help reduce ERP maintenance and support costs and this will include using 3rd party tools and using various sourcing models.

יום שלישי, 13 בינואר 2009

כיצד צריכה להיראות ארכיטקטורת ERP בארגון גלובלי?

ארגונים גלובליים נקראים לבחור בין 3 גישות אפשריות לארכיטקטורת ERP:

  • ארכיטקטורה ריכוזית לחלוטין - Single Instance, מערכת אחת, תהליכים אחידים, דטהבייס מרכזי. לרוב המשמעות הנה גם DW מרכזי אחיד.

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

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

רמת הריכוזיות בגישת הERP בחברות גלובליות תלויה באופן בלתי נפרד במספר גורמים:

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

  2. רמת גמישות ועצמאות נדרשת של החברות השונות. מעבר ל-ERP גלובלי משמעותו הפחתת גורמים אלה באופן משמעותי (פיתוחים נעשים / עוברים דרך גוף המרכז).

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

  4. שיקולי מערך תמיכה. לתמיכה מרכזית אפשרויות של חיסכון בעלויות (החיסכון במעבר לData Center מרכזי, לדוגמה, מוערך בכ-15%-20% לפי מס' מחקרים), יחד עם זאת חברות העוברות למודל זה יחוו ירידה ברמת השירות וההיענות.

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

  • EDW/BI מרכזי
    היתרון העיקרי של גישה זו הנו אחד העקרונות החשובים של עולם ה-DW: "גרסה אחת של האמת", במיוחד לאור יוזמות ניהול ביצועים ארגוניים/ SCORECARDS שהופכים להיות יותר רווחים לאחרונה. לרוב זוהי הגישה אליה ארגונים גלובליים שואפים בתחומי תוכן מסוימים (לדוגמה, ייתכן ובתחום הפיננסים ארגון גלובלי יקיים EDW ריכוזי ובתחומים שיווקיים יאפשר ביזוריות BI בארצות/חברות השונות). חסרונות עיקריים: אם לפני המעבר לאפליקציה ריכוזית היה קיים דטה מארט מקומי והחברה הלוקאלית עבדה עליו בצורה עצמאית, המעבר ל-BI ריכוזי עבור אותה חברה יהיה קשה במיוחד בשל הפגיעה בחופש ובעצמאות של החברה בקביעת מודל הנתונים וביצוע שינויים בצורה מהירה. ברוב המקרים המצב הקיים הנו עדיין מצב ביזורי שנובע מסיבות היסטוריות. הגישה הביזורית המשולבת מאפשרת לחברת הבת/מחלקה להחזיק אצלה Data Mart לוקאלי, ובמקביל להחזיק EDW גלובאלי מרכזי של החברה, שכולל נתונים המתקבלים מכל החברות/יחידות. בגישה זו, החברה הלוקאלית יכולה לגזור נתונים מה-EDW הארגוני הגלובאלי ל- Data Mart הלוקאלי שלה. בגישה זו מצד אחד ישנה עצמאות גדולה לאותה מחלקה/ חברה שהרבה פעמים תעדיף גישה זו, אבל החיסרון הבולט הוא ההבדל ב"גרסאות" הגזירה שעשוי להתרחש, וכן כל שינוי בלוגיקה של ה-EDW המרכזי גורר צורך בשינוי לוגיקה ב- Data Marts המקומיים, שלא בטוח שתמיד יתאפשר, כך שצורת עבודה זו מאיימת על קיום גרסה אחת של ה"אמת האחת בארגון". יש פה גם סוגיה בולטת של משקל – עד כמה רוב הנתונים מגיעים מהחברות המקומיות, או לחילופין מה-EDW המרכזי? (ראה נספח בעמ' 4 לדוגמאות של ארכיטקטורת DW בארגונים גלובליים בישראל)

  • MDM
    תפיסת MDM (Master Data Management) הופכת בשנים האחרונות להיות מקובלת יותר. התחום צמח בתחילה כמענה לצרכי שווקים המתאפיינים בקצב מיזוגים ורכישות גבוה (בתחילה תחום הטלקום ולאחר מכן גם שירותים פיננסיים, חב' תעשיה וכד'). כלי MDM מאפשר למזג את נתוני החברה הנרכשת במהירות הרבה יותר גבוהה מאשר ביצוע rollout או פיתוח תהליכים רוחביים, וכך לקבל ROI מהיר יותר מהמיזוג. תחום ה-MDM מאפשר לחברות לנהל נתוני לקוחות באופן מרכזי (CDI – Customer Data Integration), לנהל נתוני אב של מוצרים/פריטים קטלוגיים (PDI – Product Data Integration), נתונים פיננסיים בצורה מרכזית (Financial Data Integration), וזאת ברמה התפעולית – מערכות תפעוליות ייחשפו לנתוני MDM בזמן אמיתי, כלומר לא מדובר על תפיסת DW שמאפשר גרסה אחת של האמת שלא בזמן אמיתי.
    להערכתנו, תפיסת ה-MDM מאפשרת לחברות לעבוד בתצורה מבוזרת, ולשמור על תמונה אחידה (בהקשר של ישות מסוימת – לקוח/מוצר/נתונים פיננסיים) לכל רוחב הארגון.

מגמות והמלצות:
בחברות גלובליות שנכנסות כיום ליישום ERP (יש מעטים מאוד כאלה שכן רוב החברות הגדולות כבר בחרו ויישמו מערכות בתחום ה-ERP), רמת הכדאיות להיכנס לפרויקט ERP גלובלי "Single Instance, Single Application" הרבה יותר גבוהה מאשר בחברות שכיום נמצאות עם אוסף מערכות שונות ועובדות במודל מבוזר (מצב המאפיין אות רוב החברות כיום).
נכון להיום, רוב החברות הגלובליות נמצאות במצב (מסיבות היסטוריות) בו במדינות השונות אפליקציות תפעוליות שונות (כלומר, אין Single Instance אחד, למרות שב"חזון" ובשאיפה ארגונים גלובליים היו רוצים להיות במצב כזה). משמעויות המעבר לSingle Instance מהמצב הקיים גבוהות מאוד (מבחינת משאבים ועלויות משמעותיים, וכפי שראינו מניסיונן של חברות גלובליות בישראל – לא מצדיק את התועלת (שאין ספק שקיימת).
להערכתנו, ארגונים גלובליים כיום צריכים לשקול דרכים אחרות ליצירת תמונה אחידה ותהליכים אחידים, דרכים אשר לפני כמה שנים לא היוו אופציה ריאלית. בין דרכים אלה: MDM (ניהול נתוני אב מרכזי – מוצרים/ספקים/לקוחות), EDW – DW מרכזי אחיד עם תשתית נתונים אחידה וסטנדרטים מוגדרים, BPM – ניהול תהליכים רוחביים חוצי מערכות, והישענות על ארכיטקטורת SOA.

יום רביעי, 7 בינואר 2009

עלות פרויקט ERP - עד העלייה לאוויר?

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

אז "כמה עולה פרויקט ERP"? כדי לנסות לספק סדרי גודל של עלויות צריך להפריד בין 3 סוגים (שונים מאוד) של פרויקטים:

פרויקטי High End ERP - או במילים אחרות, פרויקטי ה"ענק". מדובר בחברות גדולות, בדר"כ חברות Enterprise כדוגמת ארגוני שירותים פיננסיים גדולים, וכן מדובר ביישום של החבילות הגדולות - כלומר, SAP או אורקל. כאן כלל האצבע ייראה בערך כך (עד העלייה לאוויר):



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




פרויקטי ERP SMB - משחק אחר לגמרי. בדר"כ עד 100 משתמשים (ולרוב, עשרות בודדות של משתמשים). השוק שונה, תמהיל השחקנים שונה, עלויות הרישוי נמוכות, ויחס השירותים לתוכנה שונה:






מה לא נכלל כאן (אבל מאוד חשוב לקחת בחשבון)? עלות של אחרי העלייה לאוויר. כיום ארגונים מתמודדים עם עלויות תחזוקה שוטפת של מערכות ERP גבוהות ומשמעותיות. כאשר מדובר ביישומי Enterprise אנו מצאנו כי מחלקות ה ERP בארגונים מונות בין 10 אנשים לעשרות רבות. בנוסף, יש לקחת בחשבון עלויות תחזוקה שוטפות (כ-22% מעלות הרישוי) בכל שנה, עלויות תחזוקת התוכנה שצוינו בכללי האצבע מתייחסים לתקופה של כ-3 שנים בלבד.


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



מאמר זה גם פורסם בדה-מרקר.

יום שני, 24 בנובמבר 2008

מהם הפתרונות שה-CFO צריך? רשמים משולחן עגול

לאחרונה קיימתי שולחן עגול בנושא פתרונות למנהל הפיננסי. למפגש הגיעו הן מנהלי מחלקות שונות ב-IT, והן CFOs (מנהלים פיננסיים) או נציגי המחלקות הפיננסיות ממגוון סקטורים: ארגונים תעשייתיים, היי-טק, שירותים פיננסיים, בריאות.
בדיון דובר על המצב הקיים לעומת המצב הרצוי מבחינת פתרונות למחלקה הפיננסית, נקודת המבט של מחלקת ה-IT, נקודת המבט של המחלקה הפיננסית, בעייתיות וחסמי, והתייחסות לנושא רגולציות:

המצב הקיים לעומת המצב הרצוי:

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

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


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

  • נושא תכנון תקציב (Budget Planning) כתחום אליו ארגונים כבר נכנסו או לחילופין מעוניינים להיכנס בקרוב. הכלים העיקריים שהוזכרו בהקשר זה: הייפריון, פתרונות SAP. כל הארגונים שהשתתפו בדיון סיפרו על רצונם להיכנס למערכות תכנון ובקרה (חלקם כבר עושים זאת כיום), ורובם הביעו רצון שמערכת זו תתממשק בצורה טובה עם מערכת ה-ERP שלהם. יש לציין כי למרות דרישת התממשקות זו, כמחצית ממשתתפי הדיון מסתכלים על הכלים בתחום זה ככלי best of breed (מה שאומר שאם המערכת המוצעת מספק הERP אינה מספיק טובה, הם יסתכלו על כלים אחרים). ארגונים מאוד מוטי מערכת ERP ספציפית סיפרו כי לא היה הרבה ספק בשלב בחירת המערכת שכן היא צריכה להתממשק בצורה הדוקה ל-ERP כדי לספק סגירות ותאימות חשבואנית, ולכן, גם אם המודול הרלוונטי אינו הטוב בשוק, הם יבחרו לעשות בו שימוש.
  • תחום נוסף שהוזכר כחשוב הנו תחום המדידה / Balanced Scorecard. במקרה זה, מעטים הם הארגונים שכבר מיישמים שיטות מדידה באמצעות כלי מדף, אך חלקם כבר עובדים בצורה כזו עם כלים בפיתוח עצמי, ואחרים הביעו רצון להיכנס לתחום.
  • מערכות המנהלות את תהליך הזמנת נסיעות – מערכות Travel שלכאורה אינה קשורה למחלקה הפיננסית, הנה מערכת שהוזכרה כמה פעמים בדיון, כאשר התועלת מהכנסת מערכת המנהלת את תהליך הזמנת הנסיעות של העובדים הנה כספית ודי ברורה – ארגונים שכבר יישמו מערכת זו סיפרו שחסכו חיסכון משמעותי והצליחו ליישם יותר בקלות מדיניות נסיעות באמצעות המערכת. המערכת מאפשרת בקרה על תהליך הנסיעות מבחינת התקציב, כולל התממשקות למערכת ה-ERP לצורך רישום חשבונאי.

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


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


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


עד כמה רגולציות דוחפות את התחום?
בתחום הרגולציות, הורגשה הפרדה ברורה בין ארגונים מהסקטור הפיננסי, בהם SOX, באזל II ורגולציות אחרות המחייבות בקרות חזקות על צד הדיווחים החשבונאיים כבר דוחפים יוזמות רבות כמה שנים, לבין ארגונים מסקטורים אחרים (ובהם גם אלה המחוייבים ל-SOX) שאינם מרגישים דחיפה חזקה מכיוון הרגולציות להיכנס לכלים ויוזמות חדשות. בעוד שבסקטור הפיננסי, התקציבים המוקדשים לתחום הרגולציות עולים בכל שנה, בשאר הארגונים לא מורגשת עלייה כזו.
מבחינת כלים ייעודיים ל-SOX, ארגונים שאינם מהסקטור הפיננסי ונדרשים לעמוד בתקנות SOX ציינו כי הליכה למוצר מדף בתחום SOX מספקת להם כלי תהליכי שחוסך להם את המצאת הגלגל מחדש, אך אינו מהווה קפיצת מדרגה או משהו תחרותי לארגון (מוגדר יותר כ nice to have). ניתן להגיע לאותן תוצאות (מיפוי נכון של תהליך) גם ללא כלים ארוזים אלה.

ניתן לצפות בסיכום הדיון המלא כאן.

יום שלישי, 18 בנובמבר 2008

ERP Lifecycles

The ERP lifecycle within Israeli enterprises is typically divided into 2 main phases:

ERP 1 – the first phase is getting the basic modules (Financials, logistics, and sometimes also HR) up and running, and also reaching stability of the system within the organization. This phase it rather complex, and takes several years to accomplish. The benefits derived from this phase are not entirely clear, but are usually referred to as operational benefits since an ERP 1 is essentially an operations support system. It is seen by most Israeli companies as a “must have” infrastructure that can help the organization in its future plans.



The 2nd phase, however, is meant to better align the ERP package with the business needs. ERP 2 includes implementation of more advanced and specialized modules (for example, project management, asset management, incentives management etc.), recently organizations have started implementing core vertical modules as the 2nd phase of their ERP lifecycle – loans management, core banking etc. Another characteristic of ERP 2 projects is the incorporation of infrastructure-type components that are becoming a part of the ERP’s technological architecture (for example, ERP-specific portals for dedicated ERP processes, DW/BI specific to the ERP data, internal BPM/Integration engine etc.). So ERP 2 is about making ERP work better and easier, and close to the business needs. Another focus point is upgrades to advanced versions. Most Israeli SAP customers have already upgraded or are in the process to upgrade to SAP’s ECC 6.0 version. On average, full upgrade takes 4-9 months and can cost up to $1M in a complex large implementation. Main reason for this upgrade is “staying in-line with vendor” in order to minimize future risk and avoid high maintenance costs (versus pure functional reasons). Oracle ERP shops have been less enthusiastic about upgrading to Oracle 12, most are planning to do so in the coming years but are not in a hurry to do so in the very near future.
But moving from ERP1 to ERP2 is sometimes tricky due to the "shock" that is caused to the organizations after ERP1; Some IT departments are complaining it's hard to get the support of the LOB managers although it's clear that ERP2 presents sibstantial potential benefits. The organization just "wants to relax" and have to stability, so getting on to the 2nd wave will not be so easy.

יום שלישי, 28 באוקטובר 2008

Supply Chain בישראל - סוף 2008

מתוך התחומים הרבים שאני מכסה תחת מושג המטרייה הרחב "חבילות אפליקציות", יש תחום אחד ספציפי עליו אני נשאלת רק לעתים רחוקות – חבילות בתחום Supply chain. זה לא משום שאין עניין או צורך בחבילות בתחום זה, נהפוך הוא. חברות רבות צריכות כלים אלה, יש פוטנציאל רב להתייעלות בתחום שרשרת האספקה, הכלים הטכנולוגיים מאוד מתקדמים וברוב הארגונים עדיין לא קיימים כלים העוזרים בתהליכי שרשרת אספקה רבים. העניין הוא שמחלקות ה-IT די מנותקות מיוזמות אלה, שלעתים נעשות באופן עצמאי לחלוטין.
יש פער גדול כיום בין מחלקות הIT לבין מחלקות עסקיות העוסקות בשרשרת האספקה בארגון. הפער מתבטא בכמה נקודות:
  • רוב פעילויות ההתקשרויות מול ספקים הנן ידניות, דברים רבים שיכלו להיות ממוכנים ולחסוך עלויות כוח אדם נכבדות אינם ממוחשבים. מיכון פעילויות אלה יכול לא רק לחסוך בעלויות כוח אדם אלא להוביל לשיפורים נוספים כגון חיזוק הקשר מול הספקים, יותר נתונים שיאפשרו ניתוח הספקים, רמת אמינותם, רמת השירות, וכד'.
  • ברוב הארגונים קיים טיפול (חלקי בלבד) בנושא ה Execution ולא בנושא ה Planning, ורוב ההתייחסות שמחלקות עסקיות מקבלות הנה במסגרת ה ERP + פתרונות משלימים קטנים אחרים. דווקא לחלק ה Planning שעוסק באופטימיזציה של תהליכים יש פוטנציאל עסקי גבוה ביותר, במיוחד כאשר ניתן לחבר אותו באופן הדוק לתהליכים השוטפים (Supply Chain Execution) כך שהתהליכים מושפעים מתובנות אנליטיות. כלומר, יישומי BI אקטיבי בתחום שרשרת אספקה מציעים ערך עסקי גבוה ביותר, כאמור, רוב הארגונים כלל אינם שם. רוב ניתוחי הBI הקיימים כיום מתרכזים סביב נתוני מכירות, פיננסים ולקוחות. יישומי BI אקטיבי שמשפיעים ישירות עם תהליכי ומערכות תפעוליות מתרכזים לרוב סביב איך להוציא יותר כסף מלקוחות. הם הרבה פחות מתרכזים בשאלה רלוונטית מאוד לעיתות משבר – איך נייעל את אופרציות הארגון: רכש יותר מושכל, רמות מלאי יותר מבוקרות, חיזוי דרישה וקישורו לפעילויות הארגון, איזה ספק לבחור לתהליך ספציפי וכד'.
  • מנהלים עסקיים לעתים מדברים ישירות מול ספקים בתחום הSupply Chain, כאשר לעתים ה IT כלל אינו מעורב. העסק בדר"כ מסתבך כשמערבים את ה IT לקראת סוף התהליך, באופן טבעי נוצרות התנגדויות והתהליך מסתבך. כמובן שאחת מהתוצאות היא שהIT נתפס כמעכב תהליכים עסקיים לארגון.
  • סינדרום ה-ERP. מנמ"רים רבים ציפו שמערכות ה-ERP ייתנו להם מענה לתהליכי שרשרת אספקה באופן די מקיף. פעמים רבות מסתבר שחבילות אלה לא מטפלות בתהליכים ספציפיים, או שהן מטפלות בו בצורה חלקית בלבד. פעמים רבות מתעורר הוויכוח הוותיק שבו ה IT לרוב יטען שכדאי להשתמש במה שיש בחבילת הERP ככיוון אסטרטגי מבחינתו. התוצאה היא ששוב מחלקת הIT נתפסת כגורם מעכב.
  • תדמית שלילית. מחלקות IT שכיום מתייעצות עמנו בנושא SCM שונים מביעים רתיעה מתחומים שונים שקיבלו מוניטין רע, ובמיוחד תחומי B2B, Ecommerce. קיים פחד להיכנס לנושא זה בשל זיכרון של כישלונות עבר בתחומי זירות מסחר ויוזמות שונות שהתפוצצו.


להערכתי, מחלקות IT כיום רחוקות מדי מצרכי שרשרת האספקה של הארגון. אין ספק שתחום ה Supply Chain Planning הולך להתפתח בצורה משמעותית ביותר, לכלים בתחום תכנון שרשרת האספקה יש פוטנציאל עסקי משמעותי ביותר עבור חברות שחלקו קשור להתייעלות וחיסכון כספי בסדרי גודל מרשימים ביותר, לא רע לתקופות משבר. התחום יתפתח, ולהערכתי זה יקרה עם או בלי מעורבות מחלקות הIT (מה גם שתחום ה SaaS צפוי לחדור משמעותית לשוק זה כך שחלק מהיוזמות ייעשו לעתים ללא ידיעת הIT כלל). לי נראה שלמחלקות הIT כדאי להיות חלק מהעניין, מה גם שפרויקטי ERP גל ראשון יוצבו ברובם, כך שיוזמות SCM יכולות למנף חלק מהתשתית האפליקטיבית שארגונים כל כך התאמצו להשיג. מהצד השני של המתרס, ספקי הIT צריכים להיכנס יותר לתחום (דבר זה ידרוש השגת יכולות והתמחויות חדשות מבחינתם), רוב הספקים הגדולים בישראל מחוץ למשחק זה כיום, ומשאירות את השוק לחברות יחסית קטנות שפועלות כחברות ייעוץ + יישום + מוצר. הן אלה שפיתחו קשרים טובים עם מחלקות עסקיות בתחום זה וכן לעתים מול מחלקות הIT.

יום ראשון, 26 באוקטובר 2008

Software Maintenance in "Post traumatic IT" times



I've been talking to organizations that heavily rely on packaged enterprise applications (SAP/Oracle/Siebel etc.) and are paying considerable annual maintenance fees (typically between 18% - 22% of the software license price). This means that within 5-6 years time the organization has paid the equivalent of a full software license.




On top of this expense, internal dedicated staff that support the ERP/CRM packages is a considerable expense and, meanwhile, it doesn't look like it's getting any smaller.


Enterprise applications have become what is sometimes called "Applistructures" – a combination of software and infrastructure components bundled together. This advent has an implication on the ERP support staff: it is becoming more diverse, more skills are required, and the packages are more difficult to maintain (one CIO told me that in the "good old days" when a specific model had performance issues they knew exactly what to do, nowadays you can never know if the problem is in the application level, portal server, web server etc. so the maintenance is getting more and more complicated as the packages vendors provide more "SOA" elements).


ERP staffing ratios in Israel
A survey we performed among large Israeli enterprises revealed that it takes 1 ERP professional to support 30-50 users (this is in organizations that are relying quite heavily on ERP for a large percent of their business operations); and it takes 1 ERP professional to support 80-100 ERP users in which ERP is "just another application", or, in other words, not a critical one. This means that ERP departments in organizations are quite large, and are usually above 10 people.


How much does it cost to run ERP after going live?
A general "rule of thumb" stated that the cost of maintaining ERP after going live is 1% of the organizations' revenues! This is a very disturbing figure, especially since most ERP packages are not helping companies grow or transform, they are usually helping companies to "keep the lights on" and continue operating pretty much the same way they did.


So - What can companies do to lower these maintenance costs in post traumatic IT times, such as the one we are most likely facing in 2009 and possibly beyond that?


New application packages maintenance models?

An interesting phenomenon (in the worldwide IT market) lately is the use of 3rd party vendors that are offering software maintenance services (for specific software packages such as Peoplesoft, Siebel etc.), for about 50% of the maintenance costs that are paid to the software provider. In exchange, these companies are offering Help Desk services, updates and fixes (at the application level, not technical level), and also tax and regulations updates. For example, Rimini St., (which also lately announced it will soon support SAP at a time when SAP shops are faced with maintenance fees increase from SAP). Another example which was actually founded by the same founder formerly is (was) TomorrowNow, it was acquired by SAP which was sued by Oracle and recently had to close these operations.


While this is a very interesting model that provides some alternative to CIOs, it is definitely not for everyone. It seems to me that a CIO would have to be quite brave to take on this adventure. Sure, it provides great savings each year and frees up much of the budget to be used for better purposes, but it also means that he doesn't have anyone to talk to if there are serious technical issues that can only be solved in the product technology level. The other big implication is that once a major release is out, and an organization has not paid maintenance fees to the vendor, he would have to buy the package all over again.


We have not seen any vendor try to offer this model in Israel, and I'm not sure that we will. It is not a very widespread trend abroad as well, but is definitely expanding. However, this model shows that there is an interest to decrease "keep the lights on" budgets to make more room for "grow" and even "transform" budgets. I think we are expected to see more models around the area of software maintenance that provide lower TCO in the next years.

יום חמישי, 16 באוקטובר 2008

אילו פתרונות מחלקת ה-IT מספקת למנהל הפיננסי?

במשך שנים התסמן פער ברור בין השוק הבינלאומי לשוק הישראלי בכל הנוגע לכלי תכנון פיננסי, או כאלה הנכללים תחת מונח המטריה: CPM - Corporate Performance Strategy. מונח זה כולל בתוכו תתי-תחומים רבים כגון תכנון תקציב, תמחיר, איחוד דוחות כספיים, Balanced Scorecards ועוד ובשנים האחרונות זוכה לעדנה בשוק הבינלאומי. אולם בישראל רוב הארגונים יישמו רק רכיב קטן מתוך מכלול זה, ורבים מהם מתחילים להתעניין בתחום לאחרונה בצורה יותר עמוקה. מעטים הארגונים בישראל שחיברו בין תהליך התכנון האסטרטגי והתכנון הפיננסי, לפעולתו השוטפת של הארגון כדוגמת יוזמות Balanced Scorecard חוצות ארגון.

כאמור, לאחרונה חלה התעוררות בקרב ארגונים ישראלים בכל הקשור לכלי תכנון ובקרה למנהל הפיננסי. בעוד שבעבר רוב הכלים אשר סופקו ל-CFO היו תפעוליים באופיים (כחלק משלב א' בפרויקטי ERP), כיום מנהלים פיננסים דורשים (וגם מקבלים) יותר כלי תכנון ובקרה.

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

במפגש נבדוק אילו כלים ופתרונות המנהל הפיננסי כיום צריך, וכיצד מחלקת ה-IT יכולה לתמוך בצרכים אלה? במפגש נעלה את השאלות הבאות (עד כמה שיאפשר הזמן):
· מה כבר נעשה בארגונים מבחינת פתרונות למנהל הפיננסי?
· מה יהיו הכלים הבאים אותן מחלקות IT תידרשנה לספק למנהלים פיננסים, במיוחד בתקופות של חוסר יציבות כלכלית? מהו הדגש בתוך מכלול כלים אלה (האם אנליטי? האם תפעולי?)
· מה בין ERP לפתרונות פיננסים? האם הפתרונות הפיננסים מגיעים מסביבות הERP או שיש להסתכל על תחום זה כייחודי, המצריך פתרונות Best of breed?
· המלצות וטיפים לארגונים הנכנסים לתחום

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

המפגש ייערך בתאריך 05.11 (יום רביעי) בין השעות 09:30 – 13:00 ויתקיים במשרדנו שבבני ציון. המפגש מיועד לארגוני משתמשים בלבד (ולא לספקים או יועצים). אם ברצונכם להירשם, אנא שלחו מייל לאתי etty@stki.info או שמרית shimrit@stki.info או טלפונית 09-7907000 (אתי או שמרית).

יום רביעי, 16 ביולי 2008

מה השלב הבא אחרי העלאת ERP לאוויר? מהו ERP 2?

ארגונים גדולים רבים בישראל כבר יישמו דור א' של חבילות ERP ומספקים כיום לארגוניהם תשתית ERP לניהול משאביהם הפנימיים, בדרך כלל סביב ניהול הפיננסים, הלוגיסטיקה ולעתים גם משאבי האנוש של הארגון.
אולם "פרויקט" ERP אף פעם למעשה לא מסתיים, ולאחר ייצוב המערכת ארגונים בדרך כלל נכנסים ל"שלב ב" של יוזמות ERP. שלב זה של היישום כולל אחד או כמה מהמאמצים הבאים:
  • שימוש במודולים "מתמחים" / "מתקדמים" – בעוד שבעבר ניתן היה לתחום ביתר קלות את התחום בו מפסיק ה-ERP ומתחילות מערכות ליבה ומערכות אחרות, כיום חבילות ה-ERP כוללות (גם אם לא תמיד באופן המיטבי) יכולות שקשורות לעסק הליבה של הארגון, יכולות CRM, יכולות סביב ניהול שרשרת האספקה, וכן כל מיני מודולים "מיוחדים" שבעבר ארגונים לא שיערו שיוכלו לקבל ממערכות ה ERP, כגון: ניהול נכסים, ניהול פרויקטים וכד'. במפגש נבדוק אילו מודולים מעניינים ארגונים כשלב ב' ליישומיהם; היכן לדעתם (אם בכלל) צריך לעבור הגבול בין הצרכים העסקיים המטופלים על ידי מערכות ה-ERP ובין אלה שמערכות אחרות BoB צריכות לטפל בהם?
  • שילוב רכיבי תשתית בERP – רוב הארגונים שכבר יישמו SAP כבר נכנסו, לרוב כשלב ב', ליישום רכיבים תשתיתיים של ה-Netweaver (XI, BW, פורטל וכד'). אנו רואים כי השימוש ברכיבים אלה הולך וגדל (BW, פורטל בעיקר) אולם מציב לא מעט שאלות "ארכיטקטורה" בארגון, כגון: ה-DW הארגוני אל מול ה-BW? הפורטל הארגוני אל מול פורטל SAP? שאלות אלה התחילו לאחרונה להתעורר גם בקרב ארגוני אורקל שמביעים עניין גדול בשכבת ה-Fusion שלה, במיוחד בתחום ה-BI וגם בתחומי BPM – BPEL. במפגש נדבר על האופן בו ארגונים תופסים רכיבים אלה, מקומם בארגון, והאופן בו ארגונים מתכננים את הארכיטקטורה הארגונית בהתאם.
  • שדרוג המערכות - חלק מארגוני אורקל ERP הגדולים שוקלים מעבר ל Oracle Applications גרסה 12, ורוב ארגוני SAP הגדולים עוסקים כיום בתכנון היערכות ותקצוב שדרוג לגרסת ECC 6.0 של SAP או במעבר בפועל לגרסה זו.

במפגש השולחן העגול דנו בנושאים אלה, וכן בנושאי בניית מערך התמיכה וה- Center of Excellence של הERP בארגון. כמו כן שוחחנו על גודל מחלקות אלה ביחס למספר משתמשי ה ERP בארגון.

לינק למאמר המלא - סיכום שולחן עגול בנושא ERP 2