- בתור תשתית לפרויקט יש לבנות סביבת 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 שאליו הוא רגיל
