מה ה 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 יש להתייחס לנושאים איכותיים אלה, ופחות לחיסכון בעלויות ובזמני פיתוח.

רכישת SUN על ידי אורקל - משמעות נוספת

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

כבר כיום לאורקל יש אוסף גדול של מוצרי BPM בעלי יכולות חופפות, מה שיוצר מעט בלבול של הארגונים בהקשר למפת הדרכים שלה בתחום זה: מוצר הBPM של אורקל - BPEL, מוצרי BEA שנרכשה - WLI, כעת "BPM", וכעת עקב רכישת SUN - גם JCAPS - Java Composite Applications Platform Suite (מוצר BPM-SOA של SUN).
מכיוון שזהו חלק די "קטן" בתמהיל מוצריה של חברת SUN ובוודאי לא המרכיב העיקרי בהחלטה לרכישת SUN על ידי אורקל, יש להניח שגם ייקח זמן לא מבוטל עד אשר נדע מהו מיקומו של מוצר BPM נוסף זה באוסף כלי ה-BPM של אורקל. יש להניח שאורקל תפעל בתחום זה באופן דומה לפעילותה בסדרת רכישות האחרונות שביצעה בהן הבטיחה ללקוחותיה תמיכה "לכל החיים" במערכות שנרכשו. עדיין, ארגונים ירצו לדעת איזה מוצר מבין 3-4 המוצרים שכעת החברה מציעה בנישת הBPM יהיה המוצר היותר "אסטרטגי" ונדחף לאורך זמן, מתוך רצון להפחית סיכון והנחה שלא ניתן להשקיע באותה המידה בכל המוצרים וכי חלקם יזכו ליותר תשומת לב.
זהו חלק נוסף, קטן מאוד יחסית, ברכישה הגדולה והמשמעותית הזאת.

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

האם ארגונים כבר מוכנים לאמץ כלי Workflow?

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

יחד עם זאת, לאחרונה אנו רואים כי ארגונים מתחילים להביע יותר עניין ב Human oriented BPM – בתהליכים אשר יותר מכווני-אנשים (לעתים מכונים תהליכי person to person ). כלי Workflow מטפלים בתהליכי person to person , ולרוב מתלווים למסמך אלקטרוני/מסמך כלשהוא (לדוגמה, תהליך אישור נסיעת עובד לחו"ל, אישור בקשת רכש, תהליך קליטת עובד).

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

בין השאלות אותן נעלה בדיון:
· מה מצב שוק ה Workflow בישראל? האם ארגונים עושים שימוש בכלים אלה, ולאילו צרכים? האם לצרכים אדמיניסטרטיביים אשר אינם מטופלים על ידי מערכות אחרות, או האם גם לתהליכי ליבה?
· מה המאמץ הנדרש בכניסה לתחום זה? איך להיערך? מהי עקומת הלמידה?
· עד כמה אפשרי לתת למחלקות עסקיות/אנשי או"ש לתכנן תהליכים בעצמן באמצעות כלים אלה?
· עד כמה ארגונים מאמצים כלים למידול וניתוח תהליכים עסקיים ( Business process analysis, business process modeling tools )?
· כיצד מקשרים את סביבת המידול לסביבת האקטיבציה?
· איך מתמודדים עם מפת הספקים המבלבלת והעובדה שספקי Workflow מגיעים מכיוונים מאוד שונים (ספקי אפליקציות, ספקי WF ייעודיים, ספקי אינטגרציה ותשתיות, ספקי פלטפורמות, ספקי ניהול תוכן וכד')?

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

etty@stki.info ושמרית Shimrit@stki.info או טלפונית בטל': 09-7907000 (אתי או שמרית).
(המפגש מוגבל לארגוני משתתפים בלבד ולא לספקים או יועצים).

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

המפגש ייערך בתאריך 15.12 (יום שני) בין השעות 09:30 – 13:00 ויתקיים במשרדנו שבבני ציון.

מדוע שוק ה-BPM בארץ עדיין לא התרומם?

אם בחו"ל ארגונים מביעים הרבה עניין בחבילות ורובם מתכננים להרחיב פעילות, מסקר שערכנו עולה פער גדול בין ישראל לשוק הבינלאומי במובן זה. רק 10% מארגונים בישראל ציינו BPM בין הטכנולוגיות החשובות ל-2008 בעוד שסקר מקביל בחו"ל (שנעשה על ידי CIO Insight) גילה כי קרוב ל 40% הגדירו טכנולוגיה זו כעיקרית וחשובה ל-2008. הסכום אותו ארגונים מוכנים להשקיע בפרויקטי BPM גם כן מאוד שונה, בעוד שבחו"ל רף הכניסה לפרויקטים מתחיל מ $100K, בישראל בדרך כלל מתחילים מפרויקט נקודתי (מיכון תהליך או שניים) ורף הכניסה יהיה סביב כמה עשרות אלפי דולרים בודדים.

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

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

לצפייה בסיכום דיון שולחן עגול אשר ערכתי בנושא BPM.