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

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

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

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

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

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.

BPM בישראל – תמונת מצב ב-2010

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

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

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

שאלות והתלבטויות שעלו בדיון:

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

טיפים ותובנות:

• ניטור עסקי Business Activity Monitoring – לעלות לאוויר מערכת מסוג זה בלי כלי שמאפשר ניטור עסקי ותשתיתי זה לא נכון, כי אין שום דרך לראות באיזה מצב נמצא התהליך. חייב להיות מפותח יחד עם התהליך עצמו. זוהי נקודה חשובה שלרוב, ארגונים נוטים להתעלם ממנה. אנו ממליצים להתחיל עם רכיב ה-BAM ורכיב השו"ב התשתיתי כבר בשלבים ההתחלתיים הן מסיבה "שו"בית" של היכולת לנטר את התהליך, והן מבחינה עסקית – שקיפות של התהליך ומה קורה איתו על מנת לשפר אותו
• יש לזכור כי BPM הנה סביבה חדשה ולא מוכרת למפתחים – לתכניתן ייקח זמן עד שיידע איך נכון לפתח ב BPM
• יש סכנה שתמיד צריך להיזהר ממנה - לעשות משהו ב BPM שיביא לתפעול מאוד קשה בארגון. לכן חשוב לרוץ עם פיילוט שניתן ללמוד ממנו כמה שיותר, ולהשקיע (בדר"כ כשנה) בבנייה מתאימה של ארכיטקטורה ותשתיות – בניית שכבת SOA, מיפוי ממשקים שנצרכים לצורך אותה מערכת ראשונה וחשיפתם, מינוי ארכיטקט ועוד
• לשנות כמה שפחות את סביבת העבודה של המשתמש – אחת מהאפשרויות היא שה BPM יעשה את ניהול התהליכים העסקיים ברקע, והמשתמש ימשיך לעבוד ב UI שאליו הוא רגיל