מה ה ROI של BPM?

לא כל תהליך ממוכן מצריך BPM.

הפוסט הבא ב JargonSpy משווה בין BPM ל WIKI – השוואה שעל פניו נראית מאוד משונה – הטענה היא שכשם ש ערך WIKI בנוי מהרבה תתי-ערכים שחלקם מוגדרים וחלקם יוגדרו בהמשך, תהליך ב BPM מסתכל על אוסף של תהליכים אחרים, וחלקי תהליכים שכולם מגדירים תהליך עסקי כולל, כאשר את "אבני הבניין" (=הערכים) ניתן יהיה לבנות אחר כך בהדרגה. אבל יש הסתכלות כוללת על תהליך-על.

לקוח שאל אותי לאחרונה מתי נכון לעשות שימוש בחבילת BPM לעומת שימוש ביכולות הWF שבמערכת תפעולית, לעומת פיתוח סטנדרטי?

להלן כמה תנאים שצריכים להתקיים לדעתי, כדי שההשקעה בנושא ה BPM תשתלם לעומת פיתוח רגיל/שימוש בWF של מערכות תפעוליות:

• תהליך גמיש אל מול תהליך נוקשה
  ב BPM יש פוטנציאל בשיפור מתמיד של התהליך. אם התהליך הוא די סטטי, אשר לא אמור להשתנות עם הזמן, ואין פוטנציאל לתועלת משמעותית בשיפור התהליך, אזי הרבה פחות מעניין להשתמש בBPM לצורך "מיכון" של אותו תהליך ועדיף לקודד. כאשר מדובר בתהליך שיש לו חשיבות עסקית יחסית גבוהה לארגון, ששיפור שלו יכול לשנות משמעותית (וכמובן גם ליצור אפקט שיווקי מצוין ליוזמת ה BPM באותה ההזדמנות), זהו תהליך מתאים לBPM. לרוע המזל, תהליכים מסוג זה הם גם אלה שהנם בעלי סיכון גבוה יותר, בדר"כ לא ממש מוגדרים והגדרתם אינה עוברת בצורה הכי "חלקה", חוצי מחלקות/תחומים (ואז גם ישנה שאלה מי מנהל אותו), וקשור למספר מערכות שונות. שיפור תהליכים בעלי פוטנציאל ROI גבוה הנו בדר"כ גם יקר יותר למימוש באמצעות BPM וייארך זמן רב.
• תהליך בעל השפעה עסקית גדולה מול תהליך אדמיניסטרטיבי ששיפורו אינו משמעותי
  כלי BPM עוזרים לקשר בין צרכי המשתמש העסקי לתוצרים הטכנולוגיים, וזה לא רק ברמת הססמה. זה נשמע, כמובן, מצוין ודבר שכל ארגון היה רוצה, אבל לקשר הזה יש מחיר. לדוגמה, אם בעבר לכל שיינוי/תקלה שהייתה מתגלה בתהליך באפליקציה הפיתרון היה ברמה הטכנולוגית, מערכות BPM "מכריחות" לבצע שינוי עסקי לפני השינוי הטכנולוגי. זה יכול בהחלט להציק/להפריע לצד הטכנולוגי של העניין, אך משמר את אותו קשר חשוב בין ביזנס לטכנולוגיה. לדוגמה, BPMN – Business-process-modeling notation - השפה ה"גרפית" לתיאור תהליכים משמשת הן את המשתמש העסקי לצורך תכנון ומידול התהליך והן את המשתמש הטכנולוגי לתרגום אותו תכנון לתהליך ממוכן.
  כלי ה BPM, ובתוכם רכיב הניטור והאנליזה (ה-BAM) מאפשרים למנהל העסקי של התהליך לבחון באופן שוטף את התהליך, לאתר בעיות בזרימתו, לתכנן ולבצע סימולציות כדי לשפרו.

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

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