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

לאראל מרגלית ממפלגת "העבודה" יש תכנית יפה לעידוד תעשיית ההייטק הישראלית תוך חיזוק הפריפריה. בין השאר ממליץ מרגלית על הקמת מרכז הייטק מתמחה בתחום התוכנה הארגונית.
אני מאמין שישראל צריכה לעבור עוד קפיצת מדרגה כדי להביא בשורה אמיתית לעולם המערכות הארגוניות הנשלטת על ידי יצרניות ה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 וניהול ישויות היא בהחלט מבטיחה.

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

מנתח עסקי - החלק החסר בפאזל

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

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

בעייתי מאוד.

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

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

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

ומי אמור לטפל בעניין הזה?

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

בקיצור - החלק החסר בפאזל הוא המנתח העסקי. לכן אני מעדיף את ההגדרה של הIIBA (מתוך ויקיפדיה, שאגב, עוד אין בה ערך עברי לתחום) :  "a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals."

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

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

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

בשבוע הבא - מה זו מערכת מידע טובה באמת ולמה אין כל כך הרבה כאלו בסביבה.

האתגר הגדול הבא

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

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

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

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

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

אז מה האתגר הגדול הבא? של הארגונים הנ"ל?

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

דווקא שם יש לנו (וכמובן לא רק לנו) בעיה.



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

אל חדר הניתוח (העסקי)

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

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

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

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

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

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

בפרסום הבא אסביר למה בדיוק אני מתנגד ולמה לדעתי ניתוח עסקי הוא מקצוע העתיד (!!!) בארגונים


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

תחילת המסע - גאווה ודעה קדומה

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

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

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

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

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

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

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

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

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

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

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

אז בהצלחה למפתחים. מקווה להיות שם כשיגזרו את הסרט...