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

יום רביעי, 23 ביוני 2010

רשמים ראשוניים ממפגש סיעור מוחות בנושא Mobile

מדי פעם אנו עורכים מפגשי סיעור מוחות - מפגשים בנושאים חדשים יחסית בהם אין best practices מוכחים וארגונים רק מתחילים ללמוד את התחום (בשונה מהשולחנות העגולים הרבים אותם אנו עורכים על נושאים בשלים/ שהנם ב mainstream). נושאים בהם ערכנו בעבר מפגשים כאלה לדוגמה – Cloud, קוד פתוח.

במפגשי סיעור המוחות משתתפים מנהלי תחומי מערכות מידע שונים, ארכיטקטים, יועצים, מובילי דעה, מנהלים טכנולוגיים בתחומים שונים בארגוני משתמשים ואנליסטים של STKI. שלא כמו במפגשי שולחן עגול שלנו, המיועדים לארגוני משתמשים בלבד, במפגשי סיעור מוחות משתתפים הן ספקי IT והן ארגוני משתמשים בתחום ה-IT.
במפגש סיעור מוחות שערכנו בנושא מובייל, עלו כמה נושאים מהותיים:
  • אחד המאפיינים הבולטים בדיון היה ההסכמה הגורפת כי עולם המובייל מאוד דינמי ולא יציב. לא ברור איזה סוגי מכשירים ואיזה טכנולוגיות יתפסו לטווח הארוך. אופק התכנון ה"ריאלי" עליו דברו רוב המשתתפים כאופק זמן אליו ארגון יכול לשאוף הנו שנתיים ולא יותר. בתהליך התכנון האסטרטגי של מדיניות מובייל, צריך להבין שחלק מההשקעות היום עשויות לרדת לטמיון בהמשך, ויש לקחת זאת בחשבון. יש למצוא את האיזון בין כניסה מוקדמת ומסוכנת לתחום חדש מאוד, ובין כניסה מאוחרת מדי כאשר שאר השוק כבר מזמן שם.
  • נקודה נוספת שעלתה בצורה נרחבת היא שימוש באפליקציה המותקנת על המכשיר החכם מול גלישה וובית. למרות שלא הייתה כל הסכמה גורפת ודעות מאוד שונות הושמעו במפגש, באופן כללי, לדעת משתתפים רבים בעתיד הקרוב עיקר השימוש יהיה באפליקציות המותקנות על המכשיר עצמו (Native application), כאשר בטווח הארוך יותר (בעקבות הבשלת סטנדרטים כדוגמת HTML5 וכד'...) הנושא ייבחן מחדש וייתכן שה"משחק" יחזור לסביבת הגלישה\WEB. אפילו אם נניח שאנו מסכימים על סוגיה זו, נותר סימן שאלה גדול סביב הדילמה – מה לעשות כרגע? האם להיכנס כבר עתה להשקעות באפליקציות WEB תוך ויתור על אלמנטים בחוויית המשתמש אותם ניתן לקבל כרגע באמצעות אפליקציית NATIVE, או לפתח אפליקציות NATIVE מתוך מחשבה שהן ישרתו את הלקוחות לזמן מוגבל, ובבוא העת לבחון את הסוגיה שנית?
  • במפגש הייתה הסכמה די גורפת להבדל הגדול שקיים בין אפליקציות פנימיות (למשתמשים פנימיים) לבין אפליקציות חיצוניות, עד כדי כך שבתהליך התכנון האסטרטגי כדאי לגבש שתי אסטרטגיות שונות – האחת למובייל פנים ארגוני, והשנייה לשירותי מובייל ללקוחות החיצוניים. באפליקציות מובייל פנים ארגוניות הפרויקטים מתבצעים לפי ROI כלכלי ככל פרויקט (אין את המניע השיווקי שנוכחותו כ"כ מורגשת באפליקציות החיצוניות). בפרויקטי מובייל פנים ארגוניים יש שליטה טובה פחות או יותר על המכשירים ועל צורת השימוש בו וכן על נושא אבטחת המידע על המכשירים, ושליטה יותר גדולה על הטכנולוגיות המועדפות. לעומת זאת, באפליקציות חיצוניות ללקוחות חיצוניים שוררת אי ודאות גבוהה וגיוון במכשירים ובמערכות ההפעלה שלא ניתן לשלוט בו כלל. אבטחת המידע בעולם זה שונה מאוד במהותה מאבטחת מידע בפרויקטים של מובייל לעובדים. המניע לפרויקט מובייל ללקוחות הנו הרבה פעמים לא כלכלי במהותו, כאשר המטרה הראשונית הנה "להיות שם".
  • ההרגשה הכללית במפגש הייתה של קושי גדול בלקיחת החלטה לטווח ארוך בשוק זה, ומצד שני חשש להיכנס לפרויקטים קצרי טווח ש"יסבכו" את הארגון מבחינת תחזוקתם השוטפת לאורך זמן. בארגונים הפועלים בשווקים מאוד תחרותיים מונעי לקוחות נושא הערוצים מול הלקוחות ובתוך כך המובייל מהווה מבדל תחרותי של ממש, בארגונים אלה יש לחץ חזק מכיוון מחלקות השיווק לבצע פרויקטי מובייל (בדר"כ – כמעט תמיד – בצורת אפליקציות מובייל) כבר היום, ומצד שני יש רצון של מחלקת ה-IT לגבש אסטרטגיה לתחום זה על מנת להוריד מורכבות של תחזוקה ותמיכה שוטפת ביוזמות אלו. המפגש נגע בשיווי משקל עדין זה והוצגו בו דעות שונות באשר לאסטרטגיה המומלצת לארגונים כיום.
  • אחד הקשיים של ארגונים עם תחום המובייל נובע מהעובדה שמדובר בתחום חדש. הנטייה הטבעית היא לנסות לעשות אותם דברים שעושים בערוצים אחרים (לדוגמה, באתר האינטרנט) גם דרך המובייל. אחד הספקים שהשתתף במפגש התייחס לסוגיה זו והמליץ להסתכל על ערוץ זה כערוץ חדש לגמרי בו הלקוחות משתמשים בדרך שונה לצריכת מידע ושירותים, ולא לנסות לדוגמה להלביש את אתר האינטרנט הרגיל על המובייל.

לסיכום, התובנות העיקריות שעלו מהמפגש:
• כדאי להסתכל על ערוץ המובייל כאל ערוץ חדש לגמרי בו הלקוחות משתמשים בדרך שונה לצריכת מידע ושירותים, ולא לנסות לדוגמה להלביש את אתר האינטרנט הרגיל על המובייל.
• ישנם 3 סוגים של פתרונות מובייל (SMS, WAP, פיתוח אפליקציות) כאשר שלושתם עשויים להיות רלוונטיים לארגון בהתאם לקהל היעד ו/או לשירות שיסופק באמצעותם. יש לבחון את התהליך שהארגון רוצה להציע, ומיהו קהל היעד שיצרוך אותו, ובהתאם לכך להחליט על סוג פיתרון המובייל המתאים ביותר.
• מהמפגש עלה כי במקומות בהם הצורך הנו שיווקי הארגון הולך לכיוון אפליקציות (כיום בעיקר iPhone כאשר ארגונים מתחילים לחשוב על Android).
• יש להפריד בין אסטרטגיה פנים ארגונית לחוץ ארגונית (במובייל פנים ארגוני הרבה יותר קל לבצע סטנדרטיזציה ולגבש מדיניות).
• יש לבצע תכנון מחדש לכל אסטרטגיה שתיבחר כל שנה – שנתיים בערך.

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

BAM (Business Activity Monitoring) state of the market

We received a question recently from an organization that doesn't have a BPM infrastructure but would like to apply a BAM product that will monitor business events in its operational applications. Here is a Definition of BAM (from Wikipedia).

BAM products are built to work as stand-alone tools that monitor events data regardless of where that data resides (whether the source for this data is BPM, ERP, DW, legacy application or any other sources).

The field of BAM holds a great promise – it can tell us what is going on with our organizational processes (which is one of our more important assets and differentiator). This area has many names – business process intelligence (BPI), some call it operational BI, BAM etc.
However, despite the high potential for business value, only about 30% of organizations who have entered BPM (more "natural" candidates for BAM) have actually implemented the BAM module. In Israel, this percentage is much lower. Organizations who have entered BPM did not include BAM as part of the project, but in a round table we held on BPM, these organizations actually recommended other organizations not to wait with BAM and implement it in the first stage.

The BAM vendor landscape changed dramatically in the past years. Just 5 years ago, the BAM market was dominated by best of breed vendors. Over the years, BAM vendors were acquired by BPM suite vendors. Today, BAM is considered more a part of BPM suite or a BI module than an independent stand alone market. A recent trend is the combination of BAM capabilities with packaged application to increase visibility to processes that are managed in these applications (For example, Pegasystem's [BPM vendor] acquisition of Chordiant [customer experience vendor] will enable ongoing monitoring and improvements of organizations' interactions with customers).

To summarize, BAM can provide high business returns. Organizations entering BPM should consider using BAM in the early stages of the project and not wait for the 2nd phase. Other organizations will find the market vendors map confusing, the main "decision" for these organization would be to decide between BPM vendors that provide BAM module and BI vendors that provide process intelligence capabilities.