ארגונים נוהגים לשאול מי אחראי על המערכת. זו שאלה חשובה, אבל היא אינה מספיקה.
האדם שמתחזק את המערכת או מכיר את פרטיה הטכניים אינו בהכרח האדם שיוודא שהיא ממשיכה לשרת את העבודה הניהולית. מבחינה טכנית, הכול עשוי להיראות תקין: הקישורים פועלים ואפשר להזין נתונים. בפועל, המידע כבר אינו מתעדכן, המשתמשים חוזרים להרגלים הקודמים והפתרון הולך ומאבד את ערכו.
לכן, בתחילת תהליך אני מחפש תשובה לשאלה אחרת:
אם המידע יפסיק להתעדכן מחר בבוקר — מי ירגיש זאת ראשון?
זה בדרך כלל האדם שהכי כואב לו כאשר הפתרון אינו עובד, או עובד באופן חלקי. הוא זקוק למידע כדי לבצע את תפקידו, לקבל החלטה, לעמוד בדרישה, למנוע תקלה או לתת דין וחשבון. לכן הוא גם המועמד הטבעי להיות נאמן הפתרון.
אבל כאן מתחילה בעיה ניהולית שכיחה: האדם שזקוק למידע אינו תמיד האדם שמייצר אותו, ולא תמיד יש לו סמכות לחייב אחרים ליצור אותו.
האחראי הטכני אינו בהכרח נאמן הפתרון
האחראי הטכני מטפל בכלי: בהרשאות, בתחזוקה, בתקינות ובקשר עם הספקים. נאמן הפתרון אחראי לכך שהמנגנון הניהולי שהכלי משרת ימשיך לפעול.
אלה שני תפקידים שונים.
נאמן הפתרון צריך לזהות כאשר איכות המידע נפגעת, כאשר כללי העדכון אינם ברורים או כאשר משתמשים מתחילים לעקוף את התהליך. הוא אינו חייב לבצע בעצמו את כל הבקרה והתחזוקה, אבל הוא צריך להיות האדם שאינו יכול להרשות לעצמו שהפתרון יתרוקן מתוכן.
לעיתים הוא מוסמך לעדכן את כללי העבודה בעצמו. במקרים אחרים הוא מרכז את הבעיות ומביא אותן להכרעת המנהל המוסמך. כך או כך, האחריות שלו אינה מסתיימת בשאלה אם המערכת פועלת. הוא שומר על הקשר שבין המערכת לבין הצורך הניהולי שלשמו נבנתה.
הבחנה זו חשובה במיוחד כאשר הכאב, האחריות, יצירת המידע והסמכות מפוזרים בין כמה אנשים.
כשהמידע נוצר במקום אחד והכאב נמצא במקום אחר
במערך של מעונות יום, המידע על העובדות ועל הכשרותיהן נוצר והתעדכן במעונות עצמם. מנהלות המעונות היו מחוללות המידע: הן הכירו את העובדות, קיבלו מסמכים, ידעו מי עברה הכשרה ומתי נדרש חידוש.
אבל הצורך בתמונה המלאה נמצא במטה.
מנהלת המטה נדרשה לאסוף את המידע, לבדוק את שלמותו, לעמוד בדרישות הדיווח ולבצע בקרה על פערי הכשרה. המנכ״לית נזקקה לתמונת כוח אדם חוצת־מעונות. למרות זאת, מנהלת המטה לא הייתה הממונה הישירה על מנהלות המעונות ולא יכלה לבסס את התהליך רק על דרישות שתעביר להן בעצמה.
זהו מבנה שחוזר בארגונים רבים:
- אדם אחד יוצר או מחזיק את המידע.
- אדם אחר זקוק לו כדי לנהל.
- הסמכות לחייב פעולה נמצאת אצל אדם שלישי.
אם מתעלמים מהפיצול הזה, בונים מערכת ומקווים שהארגון יסתדר סביבה. בפועל, נאמן הפתרון מתחיל לרדוף אחרי אנשים, להזכיר, לבקש טובות ולהשלים בעצמו מידע חסר. המערכת אמנם קיימת, אבל המנגנון הניהולי נשאר תלוי במאמץ אישי בלתי פוסק.
תנועת המלחציים
במצבים כאלה אני מפעיל מהלך משני כיוונים.
מלמעלה נדרשת הנחיה ברורה של בעל הסמכות. לא בקשה כללית „לשתף פעולה”, אלא קביעה שזהו תהליך העבודה הארגוני, מי מחויב לבצע אותו ומה מצופה ממנו.
מלמטה נדרשת יצירת ערך מוחשי עבור האנשים שצריכים לבצע את הפעולה. הם צריכים להבין כיצד התהליך מקל על עבודתם, מצמצם חיכוך, חוסך זמן, משפר את יכולתם המקצועית או מגן על אינטרס ממשי שלהם.
אני מכנה את המהלך הזה תנועת המלחציים.
אין כאן ניסיון לרכך כל דרישה עד שכל אדם יבחר בה מרצונו. לעובדים ולמנהלים יש מחויבות לתפקידם ולכללי הארגון. השאלה היא כיצד יוצרים נקודת שיווי משקל שבה המחויבות ברורה, ובמקביל השימוש פשוט, הגיוני ומועיל מספיק כדי שלא תיווצר התנגדות מוצדקת.
דרישה ללא ערך וללא יכולת ביצוע נחווית כהעמסה. תועלת ללא מחויבות ברורה נשארת בגדר אפשרות שאפשר לדחות. המימוש מתקדם כאשר שני הכוחות פועלים יחד.
תנועת המלחציים יכולה לחבר בין מחויבות, ערך ויכולת ביצוע. היא אינה מחליפה את ההכרעה הניהולית שנדרשת מבעל הסמכות.
כיצד זה עבד במערך המעונות
מלמעלה ניתנה הנחיה ארגונית ברורה של המנכ״לית: המערכת היא דרך העבודה שנבחרה, והמנהלות נדרשות להזין ולעדכן את הנתונים. מנהלת המטה קיבלה גיבוי מפורש לתהליך ולבקרה עליו.
מלמטה, העבודה עם המנהלות לא התחילה בהצגת מסכים ובהסבר על שדות. היא התחילה במשמעות של המהלך עבורן.
המערכת הוצגה ככלי שיאפשר לכל מנהלת לשלוט טוב יותר במצבת העובדות ובהכשרות במעון שלה, לזהות מועדי תפוגה מתקרבים ולצמצם את המרדף אחר מסמכים. לצד החובה הארגונית, הודגש גם הערך המקצועי: האחריות למידע אינה „העבודה של המטה”, אלא חלק מיכולתה של כל מנהלת לנהל את המעון שלה.
הפתרון עצמו תוכנן כך שכל מנהלת תראה סביבת עבודה ברורה השייכת למעון שלה. היא לא נדרשה להבין את מבנה המערכת הכולל או לברר אילו נתונים שייכים לה. המטה, לעומת זאת, קיבל תמונת אמת ניהולית מאוחדת של כלל המעונות.
בשלבי ההטמעה ניתן מענה מיידי לשאלות ולתקלות. לשם כך הוקמה קבוצה משותפת של המנהלות, מנהלת המטה והמנכ״לית. בשבועות הראשונים, כאשר מנהלת נתקלה בבעיה או שכחה כיצד לבצע פעולה, היא קיבלה מענה מיידי — לעיתים באמצעות התחברות מרחוק למחשב והובלה בצעדים הראשונים.
היה חשוב שלא תישאר תקלה קטנה שאפשר יהיה לייחס אחר כך למערכת או לתמיכה בה. כך לא נוצר מלאי של תסכולים קטנים שיכול היה להפוך לטענה שהמערכת אינה מתאימה לעבודה.
לאחר שהשימוש התייצב, הבקרה עברה באופן טבעי למנהלת המטה. היא ראתה את הנתונים, זיהתה מה חסר ופנתה באופן ענייני למנהלת המתאימה. במקום לרדוף אחר מידע מפוזר, היא פעלה מתוך תמונה קיימת.
זהו תפקידו של נאמן הפתרון: לא להזין במקום כולם ולא להחזיק לבדו את המערכת בחיים, אלא לוודא שמחוללי המידע, כללי העבודה והבקרה ממשיכים לפעול כמנגנון אחד.
לפעמים הארכיטקטורה עצמה מפחיתה את הצורך בהפעלת סמכות
במקרה אחר, מנהלת אגף פרסום הייתה צריכה לקבל מידע ממנהלי מרכזים קהילתיים כדי לנהל את משימות העיצוב ולהפיק תמונה עירונית של חוגים ואירועים. היא הייתה תלויה במידע שלהם, אך לא הייתה הממונה הישירה עליהם.
לפני השינוי, המנהלים מילאו טופס בסיסי. הנתונים נאספו בגיליון משותף, וכל מעצבת הייתה מאתרת את השורות הנוגעות לה ומעבירה אותן לקובץ עבודה פרטי. לא היה מקור אמת אחד שאפשר לראות בו מי מטפל בכל משימה, מה הועבר, מה חסר ומה מצב הביצוע.
אפשר היה לנסות לפתור את הבעיה באמצעות עוד הנחיות, תזכורות ופניות למנהלי המרכזים. במקום זאת, ארכיטקטורת הניהול שונתה כך שהמידע הנדרש נוצר בתוך פעולה שהם ממילא היו צריכים לבצע כדי לקבל שירות.
נבנה טופס מובנה ומהודק לכל אייטם פרסומי. הוא הגדיר את הנתונים הנדרשים, חייב מילוי של שדות מהותיים והעביר כל משימה אל סביבת העבודה של המעצבת המתאימה. שדה סטטוס אפשר לעקוב אחר הביצוע, ומנהלת האגף קיבלה יכולת לנטר, לנתב ולהעביר משימות לפי הצורך.
המידע לא נאסף כתוספת לעבודה. הוא נוצר במהלך העבודה.
זוהי המחשה ישירה לאחת השכבות של Management Architecture: תכנון נקודת היווצרות המידע בהתאם למסלול הטבעי של המשתמש. כאשר אדם מזין את המידע ברגע שבו הוא ממילא מבקש להניע פעולה שחשובה לו, קטן הצורך לרדוף אחריו ולדרוש ממנו דיווח נפרד.
במקרה הזה, הארכיטקטורה נשאה חלק מהעומס שבמקרה אחר היה נופל על סמכות פורמלית. היא לא ביטלה את הצורך בכללים או בבקרה, אבל הפכה את הפעולה הנכונה למסלול הפשוט והטבעי ביותר.
חמש שאלות לאיתור נאמן הפתרון
כאשר אני בוחן כיצד פתרון יחזיק מעמד לאחר ההקמה, אני מחפש תשובות לחמש שאלות:
- מי ירגיש ראשון שהמידע אינו מתעדכן?
- מי משלם בפועל את מחירו של מידע חסר או שגוי?
- מי מייצר את המידע, ומתי הוא פוגש אותו במהלך עבודתו?
- מי מוסמך לקבוע את כללי העבודה ולחייב ביצוע?
- מי יבדוק לאורך זמן שהמידע עדיין אמין ושהפתרון עדיין משרת את הצורך?
לא תמיד כל התשובות מובילות לאותו אדם. זו בדיוק הנקודה.
כאשר נאמן הפתרון חסר סמכות, הוא נאלץ לרדוף. כאשר קיימת סמכות ללא ערך ברור למשתמשים, נוצר ציות זמני. כאשר יש ערך ללא מחויבות, השימוש נשאר מקרי. וכאשר אין אדם שכואב לו שהפתרון נשחק, המערכת יכולה להמשיך לפעול מבחינה טכנית לאחר שהפסיקה לייצר ערך ניהולי.
המערכת אינה מחזיקה את עצמה בחיים
פתרון ניהולי דיגיטלי אינו מתקיים בזכות הקוד בלבד. הוא מתקיים משום שנוצרה ארכיטקטורה שמחברת בין מחוללי המידע, נאמן הפתרון, בעל הסמכות והאנשים שנדרשים לפעול.
לפעמים החיבור נבנה באמצעות תנועת מלחציים: דרישה ברורה מלמעלה וערך מוחשי מלמטה. לפעמים התהליך עצמו מתוכנן כך שהפעולה הרצויה היא גם המסלול הקל והטבעי ביותר. ובמקרים אחרים נדרשת הכרעה של בעל הסמכות להגן על הצורך הניהולי, גם כאשר נוח יותר לעבור לדיון על כלי אחר.
השאלה המכריעה אינה רק מי אחראי על המערכת.
השאלה היא מי ישמור שהארגון לא יאבד את הסיבה שבגללה המערכת נבנתה.