איך להחזיר חוב (טכנולוגי)

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

איך חוב נולד

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

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

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

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

החזר חובות 101

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

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

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

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

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

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

3 מחשבות על “איך להחזיר חוב (טכנולוגי)

  1. שלום – פוסט מאוד מאוד מעניין. יחד עם זאת בראש הארגון עומד בהמון מקרים יזם שעשה סיבוב כזה או אחר והפוסט לא מדבר בשפה שלו. איך מגשרים על הפער? 0 תמשיך לפרסם פווסטים מעניינים!!!!!!

    • תודה ג'ף,

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

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

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s