"הארגון החכם"? אולי....

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

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

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

ארגונים רבים מתהדרים בתואר ארגונים חכמים - ארגונים שיודעים מה הם עושים.
אבל הנה שלוש מלכודות שבהם יכולים ליפול (ולצערי נופלים) ארגונים מודרניים רבים:

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

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

2 - שימוש מוגזם ושגוי בחברות ייעוץ
אני בעד רעיונות שמגיעים מבחוץ בכלל, ובעד חברות ייעוץ חיצוניות בפרט. תהליכי החשיבה וקבלת ההחלטות יכולים ליפול גם הם למלכודת הניסיון המעשי. במקום לחשוב חכם נכנסים לתבניות וקונספציות. מאמצים את מה שעבד בעבר ומדכאים חדשנות ויצירתיות.
אחת הדרכים הטובות להתגבר על המלכודת הזו היא לאתגר את תהליך קבלת ההחלטות באמצעות גופי ידע חיצוניים. מעולה!

אבל כאשר מתייחסים אל הידע החיצוני כאל "כזה ראה וקדש" יש לנו בעיה. שוב אנחנו משאירים מאחור את הניסיון והידע רבי הערך שנצברו בארגון. כמו כן, את החשיבה מותירים בידי מומחה חיצוני, ומדכאים את כישורי הלמידה והחשיבה הקיימים בארגון.
ממליץ מאוד על גיליון 63 של מגזין "ארץ אחרת" כדי להבין יותר את הבעיה.

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

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

והנה מגיע הרעיון המבריק להוציא את תפקיד המפתח הזה מחוץ לארגון.

אותי מעניין האם בתנאים כאלו משרד החינוך יוכל ללמוד...

הדור הבא של התוכנה הארגונית

לאראל מרגלית ממפלגת "העבודה" יש תכנית יפה לעידוד תעשיית ההייטק הישראלית תוך חיזוק הפריפריה. בין השאר ממליץ מרגלית על הקמת מרכז הייטק מתמחה בתחום התוכנה הארגונית.
אני מאמין שישראל צריכה לעבור עוד קפיצת מדרגה כדי להביא בשורה אמיתית לעולם המערכות הארגוניות הנשלטת על ידי יצרניות הERP הגדולות. לא מדובר בקפיצת מדרגה טכנולוגית, אלא בקפיצת מדרגה ארגונית/ניהולית.

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

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

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

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

זו קפיצת הדרך שאנחנו צריכים לעבור אם נרצה להוביל את הדור הבא של מערכות המחשוב הארגוניות...

צר עולמי כעולם תהליך - חלק ג'

תקציר הפרקים הקודמים:

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

הבה נבחן לרגע את התרשים הזה (מתוך אתר immigrationroad.com). ולא, אין לי שום כוונה לרדת מהארץ. התרשים הזה פשוט מצא חן בעייני...

בלי לחפור יותר מדי לעומק, אפשר להבחין בכמה דברים בתרשים הזה. 

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

את החלק התהליכי בתרשים ניתן לזהות לפי סמל השעון (הלא סטנדרטי) שמראה שקיים זמן המתנה בין בדיקה לבדיקה.

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

ולמה אני מתעכב על התרשים היפה הזה?

מכיוון שלמרות שהוא תרשים עסקי לחלוטין, אין מצב שהוא יכול להיחשב לניתוח עסקי טוב של התהליך!

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

אבל רגע, אולי לתרשים הזה יש ערך עסקי אחר? אולי זה תרשים לניתוח לוגיקה עסקית?

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

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

לסעיף האחרון יש המון משמעות. השוו בבקשה את

"האם החייל ביצע מעל 42 ימי מילואים השנה? אם לא אז בסדר, ואם כן אז האם יש לו אישור לחרוג ממכסת ימי המילואים השנתית? אם כן אז בסדר, ואם לא אסור לזמנו למילואים". 

ואת

"אין לזמן חייל למעל 42 ימי מילואים בשנה, למעט אם התקבל אישור לכך".

הגרסא הראשונה אולי מובנת לבעלי חשיבה תכנותית/הנדסית. הגרסא השנייה היא בעלת ערך בדיון עסקי.

ולמה אני כותב את כל זה? 

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

את שני האלמנטים האלו יש להפריד. ניתוח כללים עסקיים לא אמור להיות חלק מניתוח תהליכים או ניתוח אירועים. הוא צריך להיות רכיב מהותי ומובחן בכל ניתוח עסקי איכותי.

ולסיום - עוד תרשים זרימה רב מעויינים ומשעשע מהבלוג The Systems Engineer Scholar.

צר עולמי כעולם תהליך - חלק ב'

תקציר הפרקים הקודמים - כשמנתחים "תהליך" שהו  לא תהליך, לא נכון לנתח אותו כתהליך כי הוא בעצם לא תהליך.
הבנתם?

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

אבל רגע, מה קורה אם הלקוח מבקש לבטל את ההזמנה? איך מנתחים את החלק הזה בתהליך?
זה יכול להראות ככה:

אפילו ראיתי תרשימים חסרי פשר כאלה:

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

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

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

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

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

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

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

צר עולמי כעולם תהליך - חלק א'

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

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

תהליכים. תהליכים. תהליכים.

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

הראשון הוא שלפעמים ה"תהליך" הוא בעצם לא תהליך.
ניקח לדוגמה מוסד אקדמי שרוצה לנתח "תהליך" של תיאום קורס במערכת השעות. נניח שכדי לקבוע את הקורס צריך לבצע ארבע פעולות:
א. לתאם יום ושעה עם המדריך
ב. לתאם כיתה פנויה
ג. לפרסם את הקורס בידיעון
ד. להכין חומרי לימוד לסטודנטים

אל דאגה, תרשים הזרימה כבר בדרך:

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

התרשים הזה מתאר סדר הגיוני (אם כי לא ממש מחייב) של פעולות. הוא לא מתאר תהליך כי לא מדובר בתהליך. אני הייתי מעדיף לקרוא לו "אירוע קלנדרי"* (להבדיל מאירוע רגיל, שבו משתמשים למשל בEVENT PROCESSING ). ומדוע זה לא תהליך?

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

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

אז אולי במכרז כתוב "תהליך", אבל לפני שמתחילים לטפל ב"תהליך", בואו נבדוק קודם אם מדובר בתהליך...

בפרסום הבא - גם כשה"תהליך" הוא תהליך, הסתכלות תהליכית היא מוגבלת מדי מנקודת מבט עסקית

* תודה לדני שמילה ולדני דוד שעזרו לי להגיע לחלק מהתובנות האלו לפני כמה שנים.

ידע מעשי לא נופל מהשמים

טוב, לפחות לא מאז לוחות הברית.

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

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

“There are right and wrong ways to use a screwdriver,” he said, “but there isn’t a rule for using
 a screwdriver.”

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

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

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

ומה המטרה של כל החפירה הפילוסופית הזו? 

כמובן - ידע ארגוני. 

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

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

*הציטוט לקוח מכאן : 

 Putnam Hilary. 2001. "Rules, Attunement, and ‘Applying Words to the World’" in  Deconstruction and Pragmatism. 

Edited by Mouffe C., Nagl L. New York : Peter Lang Press

מי שמתעניין בנושא מוזמן לפנות אלי ולקבל המלצות מעניינות לספרים בנושא. 

על מערכות טובות ומערכות מצוינות

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

זה טוב, אבל זה לא מצוין...

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

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

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

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

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


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

המערכת המושלמת היא מערכת שבה חלקים נרחבים מהמודל העסקי מנוהלים בתוך המערכת ומכווינים את פעילותה. שינוי במודל התהליך העסקי גורר שינוי בהתנהלות המערכת, שינוי במודל הארגוני משפיע על מערכת האבטחה, ושינוי בכלל עסקי משנה את הלוגיקה שהמערכת מפעילה.
אנחנו עוד לא שם, אבל ההתקדמות בתחומי BPM, BRM וניהול ישויות היא בהחלט מבטיחה.

בעולם אידאלי המנתח העסקי בכבודו ובעצמו יוכל לפרוס פתרונות עסקיים בלחיצת כפתור.