כמה "עולה" לפתח תהליכי workflow?

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

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

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

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

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

The 'Israeli CIO' view on Cloud computing

I recently met with 2 CIOs (one of a large retail company and the other from a large financial services company) and discussed with them the cloud concepts. I wanted to hear their view on this very "hot" subject.

Now, usually these "innovative" (which is sometimes a nicer term than "immature") concepts wouldn't stand a chance with large Israeli enterprises. But CIOs today don't have much choice; they HAVE to consider alternative consumption models for applications in order to do more with much tighter budgets.

After weeks of reading about Cloud computing, SaaS, PaaS, Daas, IaaS and getting excited about the possibilities that these models bring, the reaction of these 2 CIOs showed me that hype can only get you so far. CIOs don't really care about it, if anything, they are deterred by it. The questions they raise are very practical, and if these questions aren't fully answered there is no way they would consider cloud-based models:

Question # 1: Where's the value?
This is a relatively easy question to answer in these difficult times. Moving IT investments from Non-discretionary ("I just HAVE to keep paying annual maintenance fees to my software vendors") to discretionary ("let's start a new project that will help increase internal efficiencies") is a main purpose for CIOs today. SaaS and cloud software can help in moving some of the non-discretionary spending to discretionary. There is no reason to go into long term commitments to support 10 servers, databases, DRP and maintenance just to get a sales configuration service up and running.
Another compelling reason is that SaaS apps are providing the long-tail of enterprise applications. Need a mini-app just to manage employee travels? Employee incentives? Recruitement? Mini content sharing applications for a specific project? These are all available in SaaS. The "nicher" the process, the more likely you will find it in a SaaS model.
The other benefits are: Scalability, faster time to market, moving spending to Opex budget, and lowering the "head-aches" associated with supporting the applications in-house.

Question # 2: Who will support it? And will provide me with an SLA?
Enterprises' CIOs will not buy ANYTHING unless there is a local company that not only supports it, but can also provide an SLA for its' support. There has to be someone "responsible" on the other end, and it has to be someone local, within my country, that I can talk to. This is a crucial condition. Without it, there is not much chance anything will happen with cloud in local (non-international) organizations.

Question # 3: Is it ok "regulation-wise"?
Organizations that are very regulated (for example, banks and insurance companies) are already saying an automatic "no" in Israel to any model that means their data is kept outside of the organization. Unless it is made clear by the regulators when and how these "virtual" services can be used, CIOs will not take the risk. Another concern is more basic and has to do with using the internet to consume applications – many financial orgs. have to run 2 separate networks: an internal one, and an external – public one. This poses a huge question mark on the likelihood that these organizations will consider SaaS or any other cloud model.

Of course, there are a lot of other questions, most are somewhat psychological and will likely fade away at some time. But these are the 3 main questions and until these questions are answered don't expect Israeli CIOs to buy into these models because of the hype factor.

מצגת - מגמות ניהול ידע

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

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

במצגת ניתן לצפות כאן.

מצגת - חידושים באפליקציות הארגוניות

במצגת בתחומי אפליקציות ארגוניות שהעברתי בכנס שערכנו עבור מנמ"רים עלו הנושאים הבאים:

• השפעות המשבר הכלכלי על פרויקטי אפליקציות
• אילו אפליקציות ארגונים יידרשו לספק לאחר המשבר (ופרויקטים שכדאי להתחיל להיערך לקראתם כבר במהלך 2009)
• קטרוג אפליקציות ארגוניות ע"פי ערכן העסקי
• מודלים חדשים לצריכת "שירותי" אפליקציות: Cloud, SaaS, Open Source

במצגת ניתן לצפות כאן.

SaaS ואפליקציות ב-Cloud - רשמים ראשוניים משולחן עגול

לאחרונה ערכנו מפגש "סיעור מוחות" שכלל ארכיטקטים, יועצים, CTOs ואנשי חשיבה בתחום מערכות מידע, כדי לנסות להתרשם לאן הולך כיוון ה-Cloud בעולם ובישראל. בין השאר אחד הנושאים בהם דנו היה נושא האפליקציות ב-Cloud ו-SaaS (Software as a Service). הנה כמה רשמים ראשוניים שעלו ממפגש זה. סיכום מפורט יותר של הדברים יועלה בהקדם.

SaaS ואפליקציות ב-Cloud
משתתפי הדיון הגדירו אפליקציות SaaS כאפליקציות עסקיות ארוזות וגמורות. מבחינת הארגון שעושה שימוש ב-SaaS הוא רק מעביר נתונים ולא משנה שום דבר מהותי באפליקציות, אלא רק קסטומיזציה בסיסית ולא יותר (כדוגמת Salesforce בגלגול המסורתי שלו, כלומר – ללא ה Force.com).
במודל ה-SaaS רק ה UI שייך לארגון, כל השאר רץ ב CLOUD.

למי מתאים SaaS?
חשוב לזכור כי הלקוחות של SAAS הם ה"מתוסכלים של ה-IT" בארגון, ובדר"כ הם לא מתחת לרדאר של ה CIO. SaaS עובד בשיטת ה Long Tail ומספק אפליקציות נישה לצרכנים שבדר"כ לא קיבלו שירותים כאלה מה-IT.

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

האזורים שבהם SaaS יותר יתפוס:

• SaaS מתאים למצב בו יש צורך לפרוס אפליקציות מהר (Time to market מהיר)
• בארגונים גדולים אפליקציות שהן לא CORE יהיו קלאסיות ל-Cloud כי אין בעיה אמיתית לארגונים להוציא אותן החוצה. דוגמאות לאפליקציות כאלה שניתנו: הטבות לעובדים, אפליקציות סביב נושא ה-HR. כלומר, בשנים הראשונות לפחות (בתצורה הנוכחית של SaaS שבה אין שליטה אמיתית על data ואין אפשרות לביצוע שינויים בקוד התוכנה באופן משמעותי), האימוץ יהיה בעיקר ב"נישות". לכל ורטיקל יש את הנישות שלו. לדוגמה, הפצת דואר מאובטחת זהו תחום די נישתי שלא יעשה פריצת דרך לארגון טיפוסי ויש היגיון לשים אותו ב CLOUD. בתחומים כאלה התנגדות הארגונים ל-SaaS תהיה נמוכה.
• להערכת חלק ממשתתפי הדיון, רוב היישומים החדשים יהיו ב- Cloud בעוד היישומים הקיימים יישארו בתוך ה-DC הפיזי של הארגון. המשמעות היא שהרבה מהדברים החדשניים יהיו בחוץ. בנוסף לכך, משום שבדיון הועלתה האפשרות שה-Cloud יאפשר לחברות לבנות מודלים עסקיים חדשים (כדוגמת מפעיל וירטואלי שבנוי כולו משיתופי פעולה וצריכת משאבים מארגונים אחרים), המשמעות היא שייתכן שבסופו של דבר יהיה יותר "ביזנס" דווקא מחוץ לארגון.

האזורים שבהם SaaS לא יתפוס:

• בדברים שבהם כבר נעשתה ההשקעה (לדוגמה, SAP כבר יושם לפני שנים ולכן זה כבר Sunk cost) וכיום ההטמעה והשינויים מהווים את החלק הארי של ההשקעה, בתחומים אלה SaaS לא יתפוס כי אין מניע אמיתי להחליף את הדברים שכבר עובדים. במקרים אלה בהחלט ייתכן שארגונים ירצו בסופו של דבר לנהל "עננים פנימיים".
• אפליקציות שמאוד מקושרות למערכות אחרות בארגון הן לרוב לא אפליקציות שיוציאו החוצה ל-Cloud.
  

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

מה צפוי בעוד 5 שנים בתחום ה-SaaS?
בעוד 5 שנים רוב האפליקציות יהיו בתוך ה data center של הארגון. המצב הכלכלי הנוכחי יגרום לספקים הגדולים להתקשות לתת ללקוחות שלהם מה שהם צריכים (יבמ, אורקל, מיקרוסופט, SAP שצריכות להראות מספרים כלכליים). הספקים הגדולים יצטרכו לשנות את הקצב שבו הם נותנים פתרונות לארגונים וזה יהיה מניע כניסה ל-Cloud.
מבחינת ספקי אפליקציות – זה אומר שכבר כיום הם צריכים לייצר "אדישות" (indifference) ל CLOUD. ההשקעה באדישות למערכות הפעלה, מסדי נתונים, ווירטואליזציה תשתלם כי עם המעברים פנימה והחוצה זה לא ישנה יותר מדי. כמו כן, שימוש בסטנדרטים פתוחים (כמו WSI לדוגמה) זו ההגנה שאליה ספקיות התוכנה יידרשו כדי לשמור על תיק ההשקעות שלהן, כדי לא לגלות ששינוי תהליך קטן הופך להיות פתאום מאוד מסוכן, יקר ומורכב לתחזוקה.
גם ארגונים מבחינתם צריכים לעשות הכנות מסוג זה כדי לייצר בעתיד "אדישות" (דרך SOA, וירטואליזציה וכד').
בנוסף, אחד ממשתתפי הדיון צופה כי בעתיד יהיה חייב להיות Cloud search engine – באיזה cloud כדאי להשתמש לצורך מסוים?
תחזית נוספת דיברה על מודל תמחור אחר לתוכנה, כאשר ה- Pay per use יהיה המודל המוביל.
יהיה יותר open source גם בגלל שה-Cloud ידחוף את זה לתוך הארגונים וגם בגלל שמודל התמחור יהיה יותר ויותר אטרקטיבי. ספקי ה CLOUD בעצמם ישתמשו ב-OS, כבר כיום הרבה אפליקציות SaaS מבוססות Open source.
בסופו של דבר, בטווח הארוך (5-10 שנים), יותר SW ירוץ בחוץ מאשר בפנים בגלל הרצון להעביר את ה-overhead cost לספקים חיצוניים, ובטווח הארוך (ולא הקצר-בינוני), גם אפליקציות Mission critical ירוצו בחוץ.
לדעת אחד מהמשתתפים, בטווח הארוך יפתחו פחות בתוך הארגונים; יהיו יותר "שירותים" מוכנים בחוץ, והארגונים יסתכלו עליהם כשירותים שניתן לחבר. יש ארגונים שבכל זאת יתעקשו "להמציא את הגלגל" (דבר המאפיין ארגונים רבים בישראל). אבל בשביל שכל זה יקרה חייבים להתקיים סטנדרטים סמנטיים בתחום.

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

The "longtail" of enterprise applications

Enterprise software usually covers the operational and managerial aspects of the organization. Most organizations are currently using systems that help them support day to day operations (by using transactional applications, employee productivity applications, and other "special purpose" applications), and are also using systems that support management processes (analytical applications and decision support).

But what about all the "other" processes, the ones that aren't related directly to finance, logistics, customer support, manufacturing, budgeting...? What about thoese very "niche" specific and small processes that aren't currently managed in any system?

These needs are usually pushed to the back of the line and in most cases - aren't dealt with at all. Sometimes it's for the best, nobody just HAS to have an application that manages orders from the cafateria... But sometimes it's the important "little things" that can make all the difference. For example, little processes that support constant innovation.

Most organizations aren't using any tools that support innovation processes in the organization. There is no doubt about the importance of innovation to the organization, but innovation is a very slippery thing. The best new ideas are in the heads of the employees or the customers. Recently several companies (such as Dell, Starbucks) have launched initiatives that promote idea generation and ranking - they have built special-purpose websites that actively call out to their customers and employees to give them ideas and help them get better. Both of these initiatives are built using Salesforce.com "ideas" solution. Needless to say, tools can only SUPPORT innovation, they cannot create it.

I think there are two new developments in that provide much more options to cover the "longtail" of enterprise applications:

One of these developments is the Web 2.0. Web 2.0 concepts and techbnologies enable just the right "mix" of communication needed to generate ideas and create a great environment for brainstorming.

The second development is SaaS - this model enables rapid consumption and deployment of applications.

The current economic climate will (and is already) promote/ing these models because they can realy help IT organizations to deliver faster, more innovative applications, even in these very difficult times. The main impact will be in all these "other" applications (the longtail of the enterprise applications market) that are not realy handled within the traditional application packages, it will be in the newer and more innovative applications.

Organizations should try to take advatage of these new possibilities by trying the waters with 1 or 2 specific niche needs. This is a great time to do so.

כיצד צריכה להיראות ארכיטקטורת 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.

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



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

What's the difference between SaaS and Cloud software?

The line is somewhat blurred, but there is a line.

Would be best to describe it by looking a few years back, when we talked about ASP (and wondered why ASP never realy cought on).

ASP was about using an EXTERNAL package - this package included the hardware, database and application, all bundeled together as a package with maintenance services.

The advantages: outsource what you don't need inside. No need to manage hardware and maintain the application.

The drawbacks: TIMING (ASP came a bit too soon to the market), the core idea is good but inadequate security technologies and communication barriers (bandwidth) made it a risky choice for many organizations. Another main issue with ASP is that it's a single application that can be used by many, no customization, no changes, it's a "vanilla", take it or leave it package.

SaaS had much better timing. Everyone are now talking about it, it makes a lot of sense, and many of the technological barriers are gone. As organizations embrace new architectures such as SOA, it is becoming as a more viable option. But the more importnant thing is that while SaaS is a multi-tenant configuration, it does allow organizations to make SOME changes and customization. They don't have they're own specific application, but they can have an ISTANCE of their application, sharing the infrastructure, platform and application layer with other tenants.

Cloud software will be another development (we are now witnessing its growth). Cloud provides the "missing link" and it is the control of the data and of the application. In previous models - ASP and SaaS - organizations have no/limited control of their data. In SaaS they don't realy control the data or the application, they are consuming services and don't realy deal with the content of the services or how they are delivered. Cloud software brings the control back to the user organization, it can have it's own "cloud" (on or off premise). It can develop its own application from scratch (using PaaS - Platform as a service tools).

But cloud software will not eliminate the need for SaaS, both models will have a place: SaaS will become a model more suitable for commodity-type or lightweight processes, and Cloud will enable organizations to run heavier, core processes.

IaaS (Integration as a Service) is anothe piece of the architecture that will become more and more needed, as organizations adopt these solutions and will need to integrate them, as well as integrate them with internal, legacy, on-premise applications.

There is a very high chance that this is not the final phase of the evolution.

Enterprise Portals in Israel

Enterprise Portals are divided into 2 different types:

Gateway portals:

An “Intranet-type” portal that is used by the entire organization and includes general organizational information

Operational portals:

Point-specific portals that are used to a specific group of users for a specific process, for example: a portal for procurement processes, a portal for sales people, an HR portal etc.

The following radar shows which areas are being used by most Israeli enterprises today (for example, gateway portals are used by most), which are in implementation phases, and which are “of interest” – or in other words, are being examined (Wikis and Blogs):

Enterprise portal trends:

• Portal has become an “adjective” describing a work environment of a specific process, rather than a “noun”. In other words, building a portal is no longer the purpose, using a portal to improve collaboration processes or improve information access is the purpose.
• Most large/heterogeneous organizations have more than 1 portal: Usually 1 gateway portal and several operational portals for specific needs. Some of them are using several portals technologies, according to the specific needs.
• Portals have become the new “work environment” for KM needs, for a specific process need, or for a project need