מנמ"ר הולך לאיבוד

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

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

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

"זו הייתה דרישה של השיווק"

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

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

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

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

פיתוח תוכנה הוא בעיקר אפיון, תכנון ועצוב

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

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

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

ביצועיסט טכנולוגי או גורם מוביל

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

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

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