בואו נניח לרגע שאנחנו צריכים לקנות/לפתח מערכת ארגונית חדשה. נניח גם שקראנו את הפרסומים הקודמים בבלוג, הבאנו מנתח עסקי שעשה עבודה משובחת במיוחד ואנחנו יודעים בדיוק איזו מערכת אנחנו צריכים. אנחנו לא נבזבז משאבים על פיתוח מיותר... מה תחשב בעייננו כמערכת טובה? כנראה שהתשובה היא - מערכת שעונה לכל הדרישות שהכין המנתח העסקי.
זה טוב, אבל זה לא מצוין...
בשנייה שהמערכת תעלה לאוויר (אם לא חודשיים לפני העלייה לאוויר) יתחילו להגיע השינויים. ולא להתבלבל, אני לא מדבר על באגים (שכנראה גם יהיו). אני מדבר על שינויים עסקיים במבנה הארגוני, בתהליכי העבודה, והכי סביר, בכללים העסקיים. אנשי IT נוטים להתלונן על כמות העבודה שמושקעת ב"רדיפה" אחרי היחידות העסקיות ש"לא מתאפסים על עצמם" וגוזלים משאבים שהיו יכולים להיות מושקעים ביכולות חדשות. זאת טעות חמורה. השינויים האלו הם חלק בלתי נפרד מהלמידה הארגונית, מתגובה לשינויים חיצוניים, ומשיפורים טקטיים ואסטרטגיים של הנהלת הארגון.
(כן, גם כאן אני יכול להעמיק עוד ועוד אבל זה לא יקדם את הפרסום הזה).
מערכת מידע מצוינת, אם כן, היא מערכת שעונה לדרישות, אבל גם כזו שמסוגלת להתאים את עצמה בקלות, והכי חשוב, בזול לשינויים ארגוניים. אחרת גם מערכת שעזרה לארגון לזנק קדימה, תהפוך בתוך זמן לא ממושך למשקולת שקשורה לו לרגל.
הבסיס למערכת מידע מצוינת הוא בדמיון ועקיבות בין המודל העסקי ובין המבנה הלוגי והפיסי של המערכת. שימו לב לציור החביב של פרופ' ג'ון זקמן (הוספתי קישור בטבלת הקישורים לאתר שלו. מאוד מומלץ):
שני דברים אפשר ללמוד מהמודל הזה. על האחד כבר כתבתי - רמת העסק (מנתח עסקי מול יחידות עסקיות), רמת המערכת (מנתח מערכות) ורמת הטכנולוגיה הן שונות לחלוטין. לא מדברות באותה שפה, יש להם כלים ושיקולים שונים.
הדבר השני הוא שבכל זאת, יש משמעות לעמודות. מילון המונחים העסקי הוא בסיס לניתוח הישויות ברמת המערכת ולERD ולמימוש הטבלאות ברמה הטכנית. המבנה הארגוני הוא הבסיס למודל ההרשאות שהוא בסיס למימוש ההרשאות במערכת.
כל רמה היא שונה, אבל אם נשמור על המבנה הלוגי ועל העקיבות בין הרמות נקבל מערכת "דומה" במידה מסוימת למבנה העסקי. ולמה זה טוב? יעיד כל איש BI שניסה לקחת בקשה עסקית פשוטה בסגנון "תציג לי כמה לקוחות מועדפים נטשו את החברה בפילוח לפי היקף הפעילות שלהם" ולחלץ את הנתונים מבסיסי נתונים תפעוליים שמחביאים אותם טוב טוב. (אגב, הבעיה בד"כ היא לא בנתונים. DB בנוי היטב (או מערכת BI טובה)אמורים להחזיק מעמד הרבה זמן)
במערכת שממומשת באופן כזה, שינוי במודל העסקי אמור לעבור תרגום בקלות יחסית לשינוי במערכת עצמה.
המערכת המושלמת היא מערכת שבה חלקים נרחבים מהמודל העסקי מנוהלים בתוך המערכת ומכווינים את פעילותה. שינוי במודל התהליך העסקי גורר שינוי בהתנהלות המערכת, שינוי במודל הארגוני משפיע על מערכת האבטחה, ושינוי בכלל עסקי משנה את הלוגיקה שהמערכת מפעילה.
אנחנו עוד לא שם, אבל ההתקדמות בתחומי BPM, BRM וניהול ישויות היא בהחלט מבטיחה.
בעולם אידאלי המנתח העסקי בכבודו ובעצמו יוכל לפרוס פתרונות עסקיים בלחיצת כפתור.
זה טוב, אבל זה לא מצוין...
בשנייה שהמערכת תעלה לאוויר (אם לא חודשיים לפני העלייה לאוויר) יתחילו להגיע השינויים. ולא להתבלבל, אני לא מדבר על באגים (שכנראה גם יהיו). אני מדבר על שינויים עסקיים במבנה הארגוני, בתהליכי העבודה, והכי סביר, בכללים העסקיים. אנשי IT נוטים להתלונן על כמות העבודה שמושקעת ב"רדיפה" אחרי היחידות העסקיות ש"לא מתאפסים על עצמם" וגוזלים משאבים שהיו יכולים להיות מושקעים ביכולות חדשות. זאת טעות חמורה. השינויים האלו הם חלק בלתי נפרד מהלמידה הארגונית, מתגובה לשינויים חיצוניים, ומשיפורים טקטיים ואסטרטגיים של הנהלת הארגון.
(כן, גם כאן אני יכול להעמיק עוד ועוד אבל זה לא יקדם את הפרסום הזה).
מערכת מידע מצוינת, אם כן, היא מערכת שעונה לדרישות, אבל גם כזו שמסוגלת להתאים את עצמה בקלות, והכי חשוב, בזול לשינויים ארגוניים. אחרת גם מערכת שעזרה לארגון לזנק קדימה, תהפוך בתוך זמן לא ממושך למשקולת שקשורה לו לרגל.
הבסיס למערכת מידע מצוינת הוא בדמיון ועקיבות בין המודל העסקי ובין המבנה הלוגי והפיסי של המערכת. שימו לב לציור החביב של פרופ' ג'ון זקמן (הוספתי קישור בטבלת הקישורים לאתר שלו. מאוד מומלץ):
שני דברים אפשר ללמוד מהמודל הזה. על האחד כבר כתבתי - רמת העסק (מנתח עסקי מול יחידות עסקיות), רמת המערכת (מנתח מערכות) ורמת הטכנולוגיה הן שונות לחלוטין. לא מדברות באותה שפה, יש להם כלים ושיקולים שונים.
הדבר השני הוא שבכל זאת, יש משמעות לעמודות. מילון המונחים העסקי הוא בסיס לניתוח הישויות ברמת המערכת ולERD ולמימוש הטבלאות ברמה הטכנית. המבנה הארגוני הוא הבסיס למודל ההרשאות שהוא בסיס למימוש ההרשאות במערכת.
כל רמה היא שונה, אבל אם נשמור על המבנה הלוגי ועל העקיבות בין הרמות נקבל מערכת "דומה" במידה מסוימת למבנה העסקי. ולמה זה טוב? יעיד כל איש BI שניסה לקחת בקשה עסקית פשוטה בסגנון "תציג לי כמה לקוחות מועדפים נטשו את החברה בפילוח לפי היקף הפעילות שלהם" ולחלץ את הנתונים מבסיסי נתונים תפעוליים שמחביאים אותם טוב טוב. (אגב, הבעיה בד"כ היא לא בנתונים. DB בנוי היטב (או מערכת BI טובה)אמורים להחזיק מעמד הרבה זמן)
במערכת שממומשת באופן כזה, שינוי במודל העסקי אמור לעבור תרגום בקלות יחסית לשינוי במערכת עצמה.
המערכת המושלמת היא מערכת שבה חלקים נרחבים מהמודל העסקי מנוהלים בתוך המערכת ומכווינים את פעילותה. שינוי במודל התהליך העסקי גורר שינוי בהתנהלות המערכת, שינוי במודל הארגוני משפיע על מערכת האבטחה, ושינוי בכלל עסקי משנה את הלוגיקה שהמערכת מפעילה.
אנחנו עוד לא שם, אבל ההתקדמות בתחומי BPM, BRM וניהול ישויות היא בהחלט מבטיחה.
בעולם אידאלי המנתח העסקי בכבודו ובעצמו יוכל לפרוס פתרונות עסקיים בלחיצת כפתור.
הי אמיר,
השבמחקמה דעתך על שימוש בטכנולוגיית process mining בהקשר של ניתוח עסקי?
זוהי בעצם גישת bottom-up.
מבחינתי, "חוויה מתקנת" לאחר התנסות ב-BPM (מהיבט המידול).
ראה גם מידע על פתרון חדשני (גילוי נאות -אני משתמשת בו):
http://fluxicon.com/disco/
דפנה
האמת שעדיין לא נתקלתי במוצר הזה והוא עושה רושם מעניין. מוצרים שממנפים טכנולוגיות חדשניות לטובת הניתוח העסקי מאוד מלהיבים. אני בכלל חושב שזה כיוון מרכזי שיתפוס תאוצה בשנים הקרובות בעולם הIT.
מחקולגבי process mining, עדיין לא יצא לי להתנסות בפרויקט רלוונטי לגישה הזו. לי זה נשמע מאוד מסקרן. בייחוד כיוון שהשיטה ה"רגילה" נוטה לפעמים לפשטנות יתר מצד אחד, או לפירוט יתר ואובדן שליטה מהצד השני. בשני המקרים הBPM לא יוצא משהו...
העניין הוא שהתפיסה שלי של ניתוח עסקי שמה קצת פחות דגש על תהליכים בכלל, ויותר על רכיבים אחרים. אני חושב שהדגש על תהליכים הוא לפעמים קצת מופרז, ומגביל את נקודת המבט.
בדיוק התכוונתי לכתוב על זה בסוף השבוע. אשמח לשמוע מה דעתך
הי עמיר,
מחקבעצם מערכות BPM אמורות לתמוך באילוצים שתארת בבלוג זה. אולם, ההיבט של מדידה ובקרה עדיין לא ממש חזק. לא בגלל הטכנולוגיה (שכבר קיימת כמובן), אלא, לדעתי לפחות, בגלל חוסר עניין של מנהלים.
באותה מערכת שתארת, Process Mining יכול לשמש למשל, ככלי עזר לניתוח האופן בו משתמשים במערכת (בהנחה שנרשמים בה Event logs), וגם כדי למדוד ביצועים. התוצאות יכולות לשמש הן לאיתור בעיות בביצוע התהליכים, והן להגדרת KPIs, אותם ניתן ליישם באמצעות רכיבי BI.
הגישה היותר הוליסטית של Process Intelligence נראית לי מעניינת (ויותר מורכבת), מאחר והיא כורכת ניתוח של מימד ארגוני, תהליכי ועסקי, אשר מתבסס על נתונים ממערכות מידע. יש גם חלוקה של הגדרת יעדים ומדדים לפי הרמות: אסטרטגי, טקטי ותפעולי.
תוכל למצוא מימוש טכנולוגי בפתרון של Software AG, למשל.
http://www.process-intelligence.com/en/Solution/176659.html
לגבי פרוייקטי process mining, יש כבר נסיון מצטבר, יותר בחו"ל.
בקישור הבא ניתן למצוא דוגמה לתוצרים אפשריים המתבססת על ניתוח שביצעתי עם פריוריטי (מע' ERP):
http://bpmintro.files.wordpress.com/2012/08/process-mining-service-deliverables-pi1.pdf
אשמח להעביר לך מידע נוסף ואף לשתף איתך פעולה בביצוע פיילוט.
דפנה