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