- קיצור תהליכים בארגון
ארגונים הנמצאים בתחרות אינטנסיבית בשוק שלהם, מתמודדים עם סביבה עסקית המאופיינת בקצב שינויים גבוה, אמרו כי הארגון דורש גמישות עסקית גבוהה. בארגונים אלה, מחלקת ה-IT לא רוצה להיות צוואר הבקבוק בתהליך. אחד הארגונים תיאר מצב מתמיד של מיזוגים, רכישות ופיצולים עמם הארגון מתמודד. תהליכים ספציפיים שצוינו: קיצור זמן ההספקה (בעיקר נושא הרכש שמעכב את התהליך), קיצור זמן אישור דרישות רכש. - שיפור תהליכים קיימים
שיפור תהליכים קיימים תמיד היה מניע "קלאסי" לכניסה ל-BPM. אחד הארגונים אשר מתקדם בתחום ה-BPM סיפר על יוזמה לשיפור האיכות (עמידה בתקינה של איכות) אשר מומשה באמצעות BPM. ארגונים אחרים סיפרו שאחת התועלות הצפויות מתחום זה היא היכולת לנטר באופן שוטף תהליכים כדי לבחון כיצד אפשר לשפרם, לזהות צווארי בקבוק ולשפר את התהליך (לעומת תהליך פיתוח רגיל אשר אינו מאפשר זאת). - יכולת לתת מענה לתהליכים עסקיים רוחביים (כאלה שאינם מוגבלים למחלקה אחת אלא חוצי מחלקות).
- רגולציות SOX
למרות שזה לא עלה כמניע עיקרי, נושא הרגולציות הוזכר כעוד תועלת לה ניתן לצפות לאחר כניסה לתחום. בתחום ה-SOX צוין כי האינטרס של הארגון הוא לדעת שהארגון לא עובר "סף" כלשהוא שאסור לו לעבור. ארגון משקיע הרבה כסף כל שנה מחדש לנושא ה SOX (בחינה של איזה תהליכים עסקיים משפיעים על דיווח כספי), אח"כ בונים תכנית עבודה – על כל תהליך מהם הסיכונים, וגם הזנת התוצאות. נושא הSOX צריך להיות עוד פרמטר בכלי ה-BPM. - צוין כי המניע לא צריך להיות חיסכון בעלויות. המוטיבציה צריכה להיות מכיוון מדידת שיפור בביצועים (זיהוי צווארי בקבוק, היכן צריך לתגבר עובד, האם אנו מתאימים לתהליכי התקינה). הרווח לא מגיע בשנה הראשונה אלא לאורך זמן. ארגון שרואה לנגד עיניו מטרה של חיסכון בעלויות יתקשה לתת לזה כיסוי, בטח שלא בשנים הראשונות.
- תועלת נוספת שצוינה (לא ממש מניע, אלא תועלת נלווית) היא אלמנט ה"יוקרה" - משתמשי המערכת מרגישים שהם נמצאים ב"חזית הטכנולוגיה". פועל יוצא נוסף הוא כוח פוליטי בתוך הארגון. השקיפות שהכלי מייצג ש"איפה התהליכים תקועים" טומן בחובו חסרונות (התנגדויות בארגון) אך גם יתרונות (אם עד עכשיו האשימו מחלקה X בעיכוב תהליך מסוים, לאחר השימוש במערכת גילו כי התהליכים בכלל תקועים במחלקה Y).
תהליכים אדמיניסטרטיביים "קלים" לעומת תהליכים "כבדים"
במפגש נעשתה הבחנה בין שני סוגי תהליכים:
- תהליכים אדמיניסטרטיביים
תהליכים אלה, אשר בדר"כ ממכנים איזשהוא נוהל, ואינם מערבים אינטגרציה לאפליקציות רבות, נחשבים יותר קלים ליישום מצד אחד, אך אין להם תהודה עסקית מצד שני: לדוגמה, תהליכי סבבי חתימות, תהליך אישורי נסיעות לחו"ל צוין כתהליך קל "קלאסי"; קליטת עובד, ולרוב תהליכים סביב נושאי כוח אדם. כמו כן, אחד הארגונים כלל תחת קטגוריה זו תהליכים CRMים שאי אפשר לתת בזמן קצר במערכות CRM.
באחד הארגונים צוין כי בגלל הקושי לייצר תהליכי WF במערכת ה ERP, אנשים תמיד ימצאו את פתרונות אחרים (מיילים/ידני, באים ל-IT שיפתחו בפורטל מיני-WF), בארגון זה דווקא להכנסה של אלמנטים פשוטים היה impact גדול על המשתמש (לפני כן תהליך מתן הרשאות היה נתקע במייל שבועות וביום שתהליך זה מוכן ב-WF זה עשה שינוי גדול בחברה). - תהליכים "כבדים"/ליבתיים
רוב הארגונים שנכנסו לתחום ה-BPM לא מיכנו עדיין תהליכים ליבתיים. ארגון שכן עשה כך סיפר כי הייתה לכך השפעה גדולה בארגון, מה שעזר להמשיך ולהשקיע.
האם כדאי למכן תהליכים פשוטים אדמיניסטרטיביים או דווקא מורכבים וליבתיים? לא הייתה המלצה ברורה לכך. רוב המשתתפים הסכימו שכדאי להתחיל עם הפשוטים אך השאיפה צריכה להיות טיפול בתהליכים המורכבים, שכן הם גם היותר חשובים ולשיפור משמעותי בהם תהיה השפעה ממשית על הארגון. אחד הארגונים שמיכן הן תהליכים פשוטים והן מורכבים המליץ להתחיל עם תהליכים פשוטים כדי להוריד את הסיכון אבל לשאוף להגיע לתהליכים המורכבים, והמליץ שבמקרה שאכן ממכנים תהליכי כ"א אדמיניסטרטיביים פשוטים - מומלץ ללכת על תהליכים כאלה שבהם התועלת היא מדידה כדי להראות ערך ברור שהתקבל מהמערכת, אבל בסופו של דבר תהליכים "פשוטים" הם לא אלה שיביאו את ה-ROI האמיתי של המערכת. אלה הם תהליכים שכדאי להתחיל איתם כדי לצבור ידע, אך בסופו של דבר המטרה היא להגיע לתהליכים הליבתיים שמשפיעים רבות על הארגון (התהליכים שכדאי לשפר כל הזמן).
הבעיה עם גישה זו היא שעם המעבר לתהליכים יותר מורכבים פתאום אפשר לגלות שהארגון לקח החלטות מוטעות ושהוא אינו יכול לעבור לשלב הבא משום שהמוצר אינו מתאים, או שאין תמיכה תשתיתית מספיקה ועוד הפתעות לא נעימות.
אחד הארגונים סיפר כי בצעדי הכניסה של הארגון לתחום, כל הספקים המליצו להם שכדאי לעשות פיילוט לתהליך פשוט שניתן להרים בתוך 3 שבועות. אך ארגון זה החליט שלא להתחיל בדברים הקטנים, למרות שניתן היה בקלות להעביר תהליכים מצומצמים/נהלים פשוטים, מתוך חשש שכשהיו מגיעים לשלב מימוש תהליכים יותר כבדים הם היו מגלים שהכלי בעצם אינו מתאים.
מי אמור להיות המשתמש ב-BPM? מהן ההתמחויות הנדרשות?
רוב הארגונים סיפרו על שאיפה שהמשתמש העסקי (או"ש או key user) הוא זה שימדל תהליכים ישירות על הכלי מול סביבת מידול, סימולציה והפקת לקחים. יחד עם זאת, ארגונים שניסו לעשות כך סיפרו שזה די בלתי אפשרי, אפילו אם הכלים כוללים יכולות מידול וסימולציה שעל פניו אמורים לאפשר זאת.
סביבת ה-BPM היא סביבה מורכבת, מבוזרת, אסינכרונית, ואינטגרטיבית לסביבות אחרות. חיבור הכל ביחד זה לא עבודה לא של תכנת ולא של ניתוח מערכות. אין משתמש אחד שיכול להבין הכל. יש אנשי תשתיות BPM, יש מפתחי BPM (לאחר הקמת רכיבי תשתית בצורה נכונה מפתח BPM יכול להיות, כפי שהעיד שמתרחש בפועל אחד הארגונים, סטודנט ללא הכשרות פיתוח מיוחדות, שרק יידע להשתמש בויזארדים). כלומר, בשביל לעשות BPM צריך אנשים עם כמה ראיות שונות או צוות המורכב מאנשים עם התמחויות שונות.
הכל מתחיל בתכנון התהליך. החשיבה הניתוחית של מנתחי מערכות היא לא בהכרח BPMית. למנתחי מערכות של אחד הארגונים יש כיום checklist של שאלות שהמנתח צריך לענות עליהם.
בנושא אסקלציות: מתי שולחים אימיילים ואחרי כמה זמן צריך לשלוח לפני אסקלציות (מה הזמן המוגדר לאסקלציה על דרישת רכש שלא חתמו?) – זו חשיבה של ניתוח תהליך עסקי.
מהן הבעיות הצפויות בכניסה ל-BPM? כיצד להיערך אליהן מראש?
- ביצועים
צריך להיערך לנושא ביצועים, כדי שלא תהיה בעיה לעשות scaling בהמשך. ארגונים סיפרו ששיפור ביצועים ברמה תשתיתית ברגע שהתחום "מתרומם בתוך הארגון", דרש המון משאבים ברמה התשתיתית. יציבות מערכת היא issue. תהליכים שהסתיימו עושים לו archiving. יש לבצע הערכה נכונה של כמות התהליכים שתהיה בשטח. נאלצו לנסות לבנות בדיקה של SLA ברמת ה-activity הבודד בתוך תהליך. הומלץ לחזק נושא run time governance – להיות מסוגלים למדוד כמה ומי פונה לאיזה שירות. - תחזוקה
תחזוקה של תהליכי BPM שונה מתחזוקת מערכות רגילה. זו פלטפורמה עם הרבה ישויות שרצות באוויר, versioning. תהליך כבר רץ, מציאת ופתירת הבעיות הנה בעייתית. דרכי ההתמודדות הן גילוי של מה שקרה - איזה service נפל (לצורך זה נדרשים כלי מוניטורינג טובים), והדבר השני –אינטגרציה מערכתית טכנולוגית שמושתתת על patterns.
כדי לבצע תחזוקה בסביבת BPM צריך לבנות שכבה וירטואלית שתאפשר למדוד SLA. לא מספיק לבנות תווך טכנולוגי של איך השירות עובר ממקום למקום. לצורך זה, ESB יכול לעזור לפתור בעיות כשל. יש לבצע impact analysis - מה קורה אם אני משנה משהו? על מה זה משפיע?
נקודת מבט או"שית
מיפוי ותיעוד תהליכים - לדעת מה התהליכים שלי רק ברמת מידול (ויזיו או אקסל או כלים מתקדמים) זה צורך אמיתי מנקודת המבט האו"שית.
ההיבט האו"שי מתייחס ל BPM ככלי ניהול ידע/תוכן – אלה התהליכים העסקיים שלי והקשרים שלהם?
בעיה שצוינה היא שעדיין קיים נתק (ברוב הכלים) בין סביבת המידול לסביבת האקטיבציה כך שתיעודי תהליכים ראשוניים תמיד הופכים להיות לא רלוונטיים בשלב מסוים, שכן בינתיים הארגון התקדם ושינה תהליכים.
דילמה שעלתה היא עד כמה להשקיע בנושא תיעוד תהליכים קיימים? אנשי האו"ש ציינו כי מבחינתם יש לכך תועלת רבה, וזה למעשה מהווה בסיס הכרחי לעבודתם. אולם קיימת בעייתיות רבה במאמץ גדול שכזה, שכן עד שמסיימים לתעד, התהליכים בשטח השתנו, ואז התיעודים אינם אמינים.
אחד הארגונים סיפר על מאמץ או"שי שמתקיים כיום למיפוי תהליכים בתחומי תוכן ספציפיים בהם נדרש שיפור. התוצאה – ריפוזיטורי/ספר של תהליכים עסקיים, שיהווה בסיס לשיפור תהליכים.
שימוש ב-BPM לתהליכי IT
דוגמה שעלתה ליישום BPM הוא בתחום הפיתוח ב-IT בצורה של מיכון נוהל: מי שלא אמור לגעת ברכיב כלשהוא לא יכול לשנות אותו. כמו כן, אחד הארגונים ציין שאיפה לממש Enterprise Architecture באמצעות סביבת BPM, אולם צויין כי יישומים כאלה הנם די נדירים והכלים עדיין לא בשלים לכך. הטריגר באותו ארגון היה כניסה לפרויקט CMDB שמאפשר לאנשי התשתית לדעת ברמה התשתיתי מה יש להם, כך שאם הם עושים פעולה מסוימת על השרת הם מסוגלים לדעת על מה זה משפיע. החתיכה החסרה היא התהליכים העסקיים – על אילו תהליכים עסקיים זה משפיע, מה המשמעות העסקית?
זמני פיתוח תהליכים
תהליך פשוט (כמו אישור נסיעה לחו"ל) – מאמץ פיתוח התהליך ייקח בין שבועיים לחודש (קלנדרית בין חודש לחודשיים). פרויקט יותר גדול בין חודש לשלושה. לאחד הארגונים יש גם פרויקטים שלקחו חצי שנה.
במיוחד בתחילת הדרך, ארגונים שומעים רבות כי "אם היו עושים את זה בסביבות המוכרות היה לוקח פחות זמן", אבל צריך להבין שעל ידי שימוש בתשתית ה BPM, גם אם זה לוקח יותר זמן, מקבלים יותר, כי קיימת יכולת מדידה של התהליך ושיפורו באופן מתמיד. אבל זה לא פשוט להעביר את המסר בארגון, דורש פעילויות "PR" בתוך הארגון.
מהם הגורמים המסבכים ומאריכים פרויקטי פיתוח תהליכים באמצעות BPM? אינטגרציה, כשהנוהל לא סגור/ או כששינוי הנוהל הוא קשה (אוטומציה של נוהל בדר"כ משנה אותו בצורה מסוימת), ריבוי key users, המשתמש עצמו יכול להיות צוואר בקבוק (אם הוא לא גמיש מספיק).
צויין כי קיימת עקומת שיפור. אחד הארגונים המתקדמים יותר בתחום ה-BPM ציין כי כיום,במצב בו התשתיות כבר קיימות, פיתוח תהליך חדש פשוט נעשה על ידי סטודנט שה skiilset שלו מינימלי. אין שום צורך להכיר JAVA / דוט נט.
מה עם Reuse?
במהלך הדיון עלו נושאים ששייכים לתחום ה-SOA, כמו השאיפה לעשות Re-use של קומפוננטות (כלומר, תהליך שפותח למטרה א' יוכל לשמש גם למטרה ב'). אולם כדי להגיע למצב של Re-use צריך להסתכל על הדברים בצורה מרכזית.
ארגון יחסית מתקדם בתחום (עם עשרות תהליכים באוויר) סיפק כי השלב הבא הוא asset management , עם SLA, וrepository מרכזי. כשלב מקדים, נעשה ניסיון של מיפוי יכולות בסיסיות של השלמת חוסרים. כיום לאותו ארגון יש ארסנל של יכולות קיימות, כך שמפתח התהליכים משתמש ביכולות הקיימות ולא מפתח דברים חדשים.
מפת שוק הספקים – מה השתנה?
ארגונים סיפרו על הרגשת אי נוחות מסוימת, שבה הם אינם מרגישים שיש ספק מוביל ברור. רובם בחנו מספר כלים. ארגון שבחן כלים לפני כ-3 שנים סיפר כי בזמן זה רוב הספקים היו ספקי Workflow, וכיום ניתן למצוא ספקים הרבה יותר אינטגרטיביים הכוללים יכולות רבות תחת אותה חבילה. כמה ארגונים סיפרו על קושי במציאת כל הרכיבים הנדרשים תחת קורת גג אחת, מה שמחייב אוסף של כמה פתרונות (פיתרון BPM, פיתרון אינטגרציה, פורטל, ניהול מסמכים, ניהול טפסים, BAM, סביבת מידול). יחד עם זאת, צוין כי כיום הכלים כבר מגיעים הרב יותר אינטגרטיביים.
מה שמאפיין פרויקטי Human WF – תהליך עסקי שיש בו תחנה של משתמש. העובדה שצריך להציג ממשק למשתמש מחייב שבכלי הנבחר יהיה מסך שיבצע עדכון של נתונים, צריך לאפשר תור עבודה, אקסלציות ודלגציות. יש הרבה pre-requisites טכנולוגיים שצריך לעמוד בהם: לדוגמה, SSO Silent sign on (שלא דורש מהמשתמש להקיש יוזר וסיסמה).
פנימי או חיצוני?
הגישה הרווחת בדיון היא שBPM הנו תחום אסטרטגי וצריך להיות באחריות הפנימית של הארגון. במיוחד נושא מידול התהליכים. יחד עם זאת, מכיוון שמדובר בתחום חדש, נעזרים בכוח אדם חיצוני (יועצים), אך הניהול הוא של הארגון שמנהלים את כוח האדם.
בעיה נוספת של שימוש ביועצים היא שכל אחד מגיע עם דעה מאוד מגובשת משלו.
בקרה על תהליכים – BAM? BI?
בקרה על תהליכים – activity monitoring עלה כנושא חשוב ביותר שמספק את מירב הערך מהמאמץ. אולם ארגונים שכבר נכנסו לתחום ונכחו בדיון סיפרו כי כרגע הם עושים הכיוון כרגע רישום נתוני BPM איתם אפשר למדוד SLA של תהליך ומיישמים את ה BAM עם תשתית ה BI הקיימת של הארגון (היתרונות - חוסך skills נדרשים נוספים, ומנצל יכולות טבעיות של כלי ה BI הקיימים - תשתיות BI מספקת כלי אולטימטיבי לתת דשבורד שהוא MUST ב BAM).
עשו שימוש בתשתית ה-BI הקיימת בארגונם וחיברו אותה לנתונים המגיעים מה-BPM. ארגון אחד סיפר על בניית עולמות והגדרת אינדיקטורים / מדדים שעל בסיסם יוכלו לבדוק תהליך. הדברים שרוצים לבדוק הנם זמני סבב, צווארי בקבוק, מי מעכב מה, כמה תהליכים הלכו לערוץ מסוים, כמות התהליכים, זיהוי תהליכים שבהם ניתן לשפר (זיהוי קניין עם הזמנות חורגות, צווארי בקבוק טכנולוגיים, איפה המערכת לוקחת הרבה זמן). לתחום זה קראו המשתמשים BPI – business process intelligence (KPIS), "התוצר האמיתי של ה-BPM".
לקחים וטיפים לארגונים הנכנסים לתחום:
- פרויקט BPM מצריך עוד יכולות תשתיתיות שחשוב שיימצאו בארגון. ואם יכולות אלה חסרות, אין ברירה וצריך לקיים פרויקטים של הכנה תשתיתית לקראתו. אחד הארגונים סיפר על תקופת הכנת תשתיות מתאימות שארכה בין חצי שנה לשנה. יכולות אלה כוללות: תשתית ניהול מסמכים (באיזשהוא שלב חוסר קיום תשתית זו יהווה בעיה); סביבה מונחית שירותים ותשתית אינטגרציה. ברוב הארגונים לא קיימת סביבה כזו אך הרבה ארגונים גדולים נמצאים בשלבים התחלתיים.
- מפתח להצלחה - בניית תכנית ארוכת טווח שתכלול שלבים בביצוע, מה צריכים לעשות ולאן רוצים להגיע.
- מחזור איטרטיבי בפיתוח הוא הדבר הנכון (עוזר לא לגלות את הדברים בסוף המשחק).
- גיבוי הנהלה עוזר מאוד, במיוחד באותן נקודות (שצפוי שיופיעו) של הבעת התנגדויות
- הרבה ערך לרכיב ה-BAM. לשקול לשלב אותו כבר מהשלבים הראשונים, לבחון רכיב זה בכלים הנבחנים.
- אם לא קיים, להגדיר תפקיד "ארכיטקט" כבר בשלבים הראשונים, בשלבי ההגדרה של התועלות הצפויות מהפרויקט (לא משמש רק לצרכי BPM כמובן).
- חשוב לזהות את המקומות שמהווים את מנועי השינוי המשמעותיים, ובהם להשקיע.
- להגדיר מדדי KPI לכל פרויקט, מה ROI הצפוי לכל פרויקט (חיסכון בכ"א? קיצור זמן התהליך?)
- אחד הארגונים המליץ לשים את האחריות על אינטגרציה ו BPM ביחד, תחת אותו צוות. באותו ארגון זה היווה יתרון.
לסיכום, תחום ה-BPM הנו שונה למדי מכל תחום אחר שארגוני IT מכירים. פיתוח תהליכים בסביבת BPM שונה לגמרי מתהליך פיתוח רגיל אליו התרגלנו. ב BPM הכללים שונים, הראש שונה, השחקנים חדשים למדי, אין נקודת סיום ל"פרויקט"/תהליך המבוסס על BPM בגלל מודל העבודה האינטרטיבי והשאיפה לשיפור מתמיד של התהליך (לא רוצים להגיע למצב סטטי, אלא לשנות כל הזמן את התהליך). עלתה ההרגשה מדובר ב"הרפתקה" בעלת סיכון מסוים, ידע מועט ועלויות כניסה גבוהות, ומה שכונה על ידי כמה מהמשתתפים "הרגשת אי נוחות" בקפיצה למים.יחד עם זאת, מהדיון עלתה בהחלט ההרגשה שלתחום ישנה חשיבות אסטרטגית גבוהה באפשור גמישות עסקית גבוהה לארגון.
לצפייה בקובץ של סיכום השולחן העגול המלא לחץ כאן.
אין תגובות:
הוסף רשומת תגובה