יום חמישי, 2 בדצמבר 2010

קפיטליזם חברתי - כמה "שווה" הערך החברתי שלכם?

מאמר שגלית פיין ואני כתבנו על ה"קפיטליזם החברתי" החדש התפרסם בדה-מרקר:

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

כמה שווה ה"ערך החברתי" שלי?

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

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


הכותבות הינן אנליסטיות בחברת הייעוץ והמחקר STKI

יום שלישי, 19 באוקטובר 2010

Back to the Future ... Back to the box!

Oracle's recent announcement of its "Cloud Box" package, as well as IBM's announcement of NETEZZA acquisition and other announcements, are all related to the trend that surely will be one of the most important events in the near future of information technology: the inclusion of various technological elements under a single "umbrella" (or, in other words, back to the Main-Frame era). Many enterprises' CIOs we have talked to recently report that they engage with over 200 (!) IT vendors annually. And this number is only growing year-by-year.
For example, a typical ERP project in an enterprise organization- the organization should get in touch with about 20 different vendors (if not more) to get "One ERP solution" that includes infrastructure support, databases, operating systems, different application providers for each category. Keeping this in mind, the option of receiving an "ERP solution" within one packaged box while working with a single supplier seems very appealing for CIOs who are looking for simplicity and a single "partner" to work with.

So how did we end up getting back to the same architecture we had "ran away" from just recently? Are we not going to encounter the same problems that pushed us to decide to decentralize our computing, and consequently work with different suppliers in each category? A decision that is reflected in the separation we have made between the layers of hardware, storage, operating systems, Data, applications, management, connectivity? Why do we, all of a sudden, want to get the whole stack in one single box, even if this box is now very nicely packaged and wrapped in nice words like "internal cloud" or "Industry in a box"?
Is it really possible to return to a model in which we have one provider that provides us all the services under its responsibility?

The real reason behind this trend is that CIOs are fed up with the high complexity of managing IT and the search for simplicity (even if that means less choice and less open standards). Business have simply become too complex to manage. CIOs are tired of constantly dealing with optimization issues, the endless worry that the new package will not work properly (for one thousand and one reasons), dreading thoese "middle of the night" phone calls that the servers have crashed again /, the site is not in the air / the organization's main application is not functioning, and the engagement with so many different suppliers.

But before we announce the death of the era of decentralization and the return of the
centralized era, is it also well worth exploring the pitfalls and potential risks of this model:
  • Creating a dependency on the IT vendor. Just ask your procurement manager how they feel about working with a single vendor instead of an "open market" with many different options of vendors to chose in each category. The "industry in a box" model means that the organization will work with one major supplier or at least one major supplier for each category. For the procurement manager this trend is a real negotiation problem, since the power now moves to the vendor.
  • Connectivity and Integration issues. Most organizations have a heterogeneous application environment with 3-4 major applications vendors. The "boxed" model means that each technological environment will now be more closed off, more proprietary in nature, and less open. This means – connectivity issues. Each environment will be optimized and adapted for the application's main purpose, regardless of other applications' need to connect with it. The supplier will want to give the organization with a box that works flawlessly, with all the different parts "talking" to each other in harmony and are controlled best by a single management tool. What will happen when you try to add a new element into that box? Connectivity problems will appear both on the level of business processes and the Data level.
  • Difficulty in achieving an overall monitoring and management view. This will also be a challenge because the "box" providers will include complete solutions with a monitoring tool tailored to the application's specific need. Each solution will include, among other things, a security solution, backup solution, a DRP solution and so forth. This means that receiving information about the organization's overall threat situation will be much harder than before, since there will be a need to synchronize with different information security solutions in order to get to this situation.
  • Risk of harming the organization's level of flexibility. If there is a need which has not been addressed in advance by the manufacturer of the packaged solution, the organization can't answer this need (it will require greater efforts to address it). In today's reality, there are many cases in which there are non-standard needs that off the shelf packages do not include. In these cases, organizations can and are doing things that are considered non-standard (adding to the system's components, programming in a way that is not 100% recommended by the vendor etc.). This is almost impossible in the "Industry in a box" model. Boxes manufacturers will not allow to perform actions that do not receive prior approval or "certification" which takes a long time. This means that the level of IT's flexibility in tailoring for the organization's needs will be reduced.
  • Significant changes in the status of the IT department as we know it today. The traditional structure of IT organizations' infrastructure department currently includes three separate sections – Network, Storage and Servers. The technological change which we have described (inclusion of all these elements under one box) will require a different structure of the IT Infrastructure unit – from 3 different departments to a unified one. This change will also apply to application teams, and their relationship with Infrastructure teams. If the organization acquires a "CRM box", that also includes infrastructure components, who in the organization will be responsible for the operation and maintenance of the entire box? This is not necessarily a disadvantage, but this is a significant change, and any major change is difficult to cope with.

Vendor's perspective:
IT providers will also experience quite a few changes, some are positive but some are very disruptive and will require a change in the overall vendor's business model.

  • Change in the vendor's sales processes. The 'cost of selling' for suppliers in various categories (hardware, software etc.) is a fixed cost. If the supplier will now sell the customer "one solution" which includes the same components inside, rather than selling them individually, the relative cost of selling per each component will fall significantly. The expected cost of selling for suppliers will drop (an advantage that we hope will lead to increased profitability as well as reduced pricing for enterprises).
  • Should we expect a decrease in revenues for service providers? It remains unclear whether service providers will experience a decrease in revenues from the sale of services as a result of this trend. If we take as an example the SAAS (software as a service) model, then in this field we can clearly see that services revenue for Integrators have indeed decreased significantly compared with the "classic" model in which an organization actually buys the software and customized according to its needs. A SAAS solution implementation project typically takes between several weeks to two months, almost never includes customizationsm and focuses mainly on training and assimilation. As mentioned above, it is still unclear how this field will affect the overall revenue structure of suppliers.

Who are these providers "Industry in a box"?
NCR have provided a boxed solution long before we called it "Computing in a box" with Teraedta. Among other prominent major manufacturers already offer solutions for Industry in a box we can mention IBM, HP, Oracle, EMC, CISCO, Apple and more. SAP made a major step toward this model recently by acquiring SYBASE.
Take Apple for example. The iphone / ipad industry are actually industries in a box - a box that contains applications, operating system, and hardware. All these parts belong to and are in full control of Apple, which enables it to provide a machine that provides an excellent user experience, optimal performance for applications running on it. But there's no choice, and no openness. The equilibrium exists as long as the box remains closed. Try to open the box and put in elements from the outside - and the balance will be violated.
This example can illustrate pretty well what is expected to happen - as long as consume technology "in the box", we can provide good value. As soon as we try to go out, for example to replace the infrastructure and applications in the box, problems will begin.
This example illustrates one of our essential questions in this area have not yet received an answer: Will manufacturers prefer boxes proprietary technologies, or will they try to adapt to open and common standards?


Recommendations:

  • Due to the expected lock-in effect, make an effort to preserve procurement conditions for future deals as well as current deals.
  • Organizations should deploy general and flexible monitoring and management consuls that will enable the future connection of "industry in a box" solutions.
  • Organizations should start to prepare for the expected organizational changes. For example, measurement of the degree of cooperation between teams and not measurement of each team's performance separately (DBA performance evaluation will be based not by a specific DBMS availability, but according to the overall ERP system availability and performance).

בחזרה לעתיד... חוזרים לקופסה!

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

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

  • יצירת תלות בספק. אם עד כה, ה-ERP של החברה הורכב מספקים נפרדים לאפליקציה, מערכת הפעלה, בסיס נתונים, תקשורת וחומרה, עם אפשרות לבחירה והחלפה, הרי שבקרוב נקבל מאותו הספק קופסה אחת שלמה, שמכילה אפליקציה המותאמת לחומרה ולבסיס הנתונים שעובדים באופטימיזציה מלאה. התוצאה: ביצועים טובים בהרבה ופחות כאב ראש בהעלאת הפרויקט. אך החיסרון טמון בגזרת מנהלי הרכש, שיהיו כבולים מול ספק יחיד בעל כוח עצום. שיקול זה עלול לגרום לגפי רכש לעכב קבלת טכנולוגיות חדשות משיקולים פוליטיים פנימיים.
  • צרות של קישוריות. מרבית הארגונים מנהלים את היישומים שלהם בשיטה של ריבוי ספקי אפליקציות תוך קישור מתמיד ביניהם. על פי חזון ה"קופסאות" אליו אנחנו צועדים, שיטה זו תהיה קשה הרבה יותר ליישום. כל סביבה תותאם לצורך העיקרי של כל אפליקציה, ללא התחשבות באפליקציות האחרות שנדרשות להתחבר אליה. הספק מעוניין ליצור קופסה שפועלת בהרמוניה ונשלטת בצורה מיטבית על ידי גוף ניהול יחיד. כשננסה להכניס לקופסה מרכיב שלא שייך אליה, נסיט את רוב מאמצי המנמ"רים להתעסקות בקישוריות בין הקופסאות השונות וניסיון ליצור מכנה משותף ל-DATA.
  • פגיעה ביכולת הניטור והניהול הכולל של מערכות המידע. כיוון שיצרני ה"קופסאות" יגישו פתרונות מלאים וכוללים, כל פתרון יכלול פתרון אבטחת מידע, פתרון גיבוי, ופתרון DRP משלו. קופסה A תכיל פתרון אבטחת מידע שונה מזה של קופסה B. המשמעות היא קושי לקבל מידע על מצב האיומים הכולל בארגון, בשל הצורך להסתנכרן מול כמה פתרונות אבטחת מידע שונים.
  • פגיעה בגמישות של ארגון המערכות. במצב בו מתעורר צורך שלא הוגדר מראש על ידי יצרן ה"קופסה", הארגון ייאלץ להשקיע מאמצים רבים יותר כדי לספקו. בקופסאות המוכנות מראש, הארגון לא מורשה לבצע פעולות שלא קיבלו אישור מראש"certificiation” . תהליך אישור זה אורך זמן רב, מה שעלול לפגוע בגמישות ארגון מערכות המידע ובמענה לצרכי הארגון.
  • שינוי משמעותי במבנה ומעמד מחלקת מערכות המידע כפי שאנו מכירים אותה כיום. מבנה מסורתי של גוף תשתיות בארגונים גדולים כולל כיום שלושה מדורים נפרדים לתקשורת, אחסון ושרתים. שינוי התפיסה הטכנולוגית יחייב גם שינוי במבנה הארגוני. כמו כן, אם "קופסת CRM" אחת כוללת בתוכה גם את הרכיבים התשתיתיים, מי בארגון יהא אחראי על תפעולה ותחזוקתה? הקו בין המחלקות האפליקטיביות לתשתיתיות יילך וייטשטש. זהו לא בהכרח חיסרון, אבל מדובר בשינוי משמעותי שיחייב התמודדות שונה לחלוטין.

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

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

מיהם אותם ספקי "Industry in a box"?
על היצרנים שכבר מציעים פתרונות Industry in a box ניתן למצוא את הספקית הוותיקה NCR/ טרהדטה (שכבר הייתה שם מזמן, עוד לפני שתיארנו את התחום בבאזוורדים יפים), IBM, HP, אורקל, EMC, CISCO, Apple ו-SAP שעשתה צעד משמעותי בכיוון כאשר רכשה את SYBASE.

אם ניקח את Apple כדוגמה, ה iphone / ipad הנם למעשה industry in a box – קופסה שמכילה אפליקציות, מערכת הפעלה וחומרה. כל החלקים האלה מצויים בשליטה מלאה של אפל, מה שמאפשר לה לספק ביצועים אופטימליים. אולם שיווי המשקל מתקיים כל עוד הקופסה נשארת סגורה. נסה לפתוח את הקופסה ולהכניס פנימה רכיבים מבחוץ – ושיווי המשקל יופר. דוגמא זו יכולה להמחיש מה צפוי לנו במקרים אחרים של ספקי-על שיציעו תעשייה בקופסה. כל עוד נצרוך טכנולוגיה "בתחומי הקופסה", נקבל תמורה מספקת וטובה. כשננסה להחליף את האפליקציה מעל התשתית הקופסתית, ניתקל בבעיה
.
האם יצרני קופסאות יעדיפו עבודה בטכנולוגיות קנייניות או שישמרו על סטנדרטים משותפים?

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

המלצות לארגונים:
1. כל כניסה לטכנולוגיית מחשוב מבוסס-קופסה מחייבת התייחסות משמעותית לסוגיית הרכש, ודגש על קיבוע אחוזי הנחה ממחיר רכש לקניות עתידיות ולפריטים שייווצרו בעתיד. כלומר, לנסות להפחית את רמת ה lock-in לספק עד כמה שניתן מראש.
2. ארגונים צריכים להטמיע כבר כעת קונסולות כלליות וגמישות של ניטור וניהול, כדי שיוכלו לחבר בעתיד קופסאות “industry in a box” שונות.
3. ארגונים צריכים להתכונן כבר כעת לתמורות הצפויות בארגון; התייחסות ומדידה של מידת שיתוף הפעולה בין הצוותים ולהנהיג תגמול DBA לא לפי זמינות DBMS ספציפי, אלא לפי זמינות וביצועי כלל מערכת ה- ERP."

יום חמישי, 23 בספטמבר 2010

רשמים ממרתון של חברת לוטם בנושא ווב2

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

הנה סיכום ההרצאה שלי מתוך הבלוג (שהייתה יותר טכנולוגית באופייה):

"עינת שמעוני, אנליסטית מחברת STKI בהרצאה על יישומי ווב 2.0 בארגונים: ויקי, רשתות חברתיות ארגוניות, בלוגים, טוויטר, social bookmarking, RSS, תגיות, יישומים מבוססי מקום (למשל Four square)

כמה תובנות מההרצאה:


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

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

מה המוטיבציה של עובדים לעשות שימוש בכלי ווב 2.0? קודם כל צריך להבחין בין משתמשים שונים, ולתת במה לאילו שרוצים לשתף במידע, לבין אילו שמעדיפים רק להגיב (כפתורי Like למשל)

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

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

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

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

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


הפוסט המלא באתר של לוטם - כאן.

יום שבת, 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: