מה אם לא היה לך מושג כמה חוב היה לך? זה יהיה מצב לא נוח להיות בו, לא לדעת כמה זה עולה או באיזו מידה הוא מונע מהחברה שלך לבצע שיפורים תפעוליים, להגיב לשינויים בשוק או אפילו להפוך את העסק לחלוטין.
יתר על כן, מה אם כמעט כל אחד בארגון שלך יכול להיכנס לחובות מבלי לבקש אישור? לדוגמא, ראש הנדל'ן שלך עלול להיכנס במהירות לחוזה שכירות רב שנתי עם שכר דירה נמוך לשנה אך עם דמי שכירות שהולכים ומחריפים בשנים האחרונות - מבלי שאיש יגלה זאת מלבד שיחה.
כל זה נשמע כמו ממשל לא נבון, אבל זה למעשה די נפוץ בעסקים. המלכוד הוא כי סוג זה של 'חוב' אינו מגיע בצורה של המכשירים הפיננסיים המסורתיים שכולנו מכירים כל כך טוב.
חוב טכני כולל את כל המאפיינים הללו.
חוב בצורתו הפשוטה ביותר הוא הלוואה כיום מתוך כוונה והבטחה להחזיר בעתיד. חוב הגיוני כאשר ההלוואות של היום יובילו למחר טוב יותר, למשל, הלוואה למכללה או רכישת בית. חוב בדרך כלל גרוע כאשר הלוואה היום תוביל למחר גרוע יותר, למשל, לצאת לארוחת ערב יקרה ולשים אותה על כרטיס אשראי שלא תשלם מיד.
במונחים ארגוניים, חובות יכולים להיות טובים כאשר הם נוצרים למימון השקעות שיספקו תשואה גדולה יותר מ- עלות החוב . זה עשוי להיות הגיוני גם אם אתם מתכננים למכור את העסק הרבה לפני פירעון החוב. החיסרון של החוב הוא שיש לו הוצאה ממשית מאוד שגוררת מזומנים ורווחים, מגבילה את הגמישות ויכולה להיות מכבידה עד כדי כך שהיא עלולה להוביל פְּשִׁיטַת רֶגֶל .
עד כה, המטאפורה שאליה אנו רומזים היא על חוב פיננסי, צורה אחרת של חוב - חוב טכני (או 'חוב טק') - היא בעלת מאפיינים דומים רבים ויש למדוד, לנהל ולהיכנס אליהם בצורה מכוונת. . אם זה מאפשר לחברה שלך להגיע לשוק לקראת התחרות, סביר מאוד שזה שווה את זה. באופן דומה, לקיחת חובות טכניים בכדי להקל על פגיעות ביטחונית שעלולה להיות חמורה היא כנראה שווה את זה.
עם זאת, לחוב הטכני יש חסרונות, מה שמוביל לחוסר יעילות ולאינרציה - כמו למשל כאשר מחלקה אחת לא רוצה להשתמש בתוכנה של אחרת, או אם מעכבים שדרוג מספר פעמים בכדי להגיע ליעדים פיננסיים קצרי טווח.
חוב טכני הוא מונח ששימש בעיקר בקהילה הטכנית מאז וורד קנינגהאם , מתכנת מחשבים, טבע את הביטוי בשנת 1992. השימוש בו המריא לאחרונה ותפס את מרכז הבמה עם ריבוי התכנות הזריז. החוב הטכני שנדון במאמר זה אינו עוסק במתודולוגיית תכנות אלא בהשלכות האסטרטגיות של קיומו.
במילים פשוטות, חוב טכני הוא העלות המצטברת ואובדן הזריזות לחברה שלך כתוצאה מהחלטות קודמות שהתקבלו כדי לחסוך זמן או כסף בעת יישום מערכות חדשות או שמירה על מערכות קיימות. זה קורה כאשר מערכות אינן משולבות כראוי או שהקוד מורכב מדי. הסיבה לכך היא מגוון סיבות, כגון חוסר יעילות, זמן לשיקולי שוק או הפעלת גרסאות מיושנות של תוכנה, בקרב רבים אחרים.
כמה דוגמאות ברורות יהיו:
התרשים שלהלן הוא גרפיקה שימושית למסגור כיצד חוב טכנולוגי שונה מיישומים טכנולוגיים אחרים שניתן לבצע במסגרת ערכת הטכנולוגיה של החברה. לעתים קרובות טועה בהיותו באג, חוב טכני שונה בהרבה מכיוון שנוכחותו עשויה להיות לא ברורה בעליל. בה טמונה הסכנה, ככל שככל שהיא לא נוגעת זמן רב יותר כך גודל ההשפעה יהיה גבוה יותר בעתיד.
כ מנהל כספים ראשי שעבד גם בתחום ה- IT וגם דיווח לי ב- IT בחברות ארגוניות ממונפות מאוד, זה הדהים אותי עד כמה החוב הטכני דומה לחובות המסורתיים. זה גם הדהים אותי עד כמה זה אטום ומסוכן. אלה מרקע פיננסי בקי במנגנוני החוב הפיננסי - זה מוחשי וקל לחישוב. אולם לא כך לגבי חובות טכניים, שלעיתים קרובות אינם מובנים בצורה מוטעית או מניחים בטעות שהם בעיה של מישהו אחר.
התשובה הקצרה היא שעלויות המזומן אמיתיות מאוד. יש גם כמה עלויות רכות חשובות שיש לזהות כמו גם למדוד ולנהל אותן בנפרד. בהמשך אפרט כמה דוגמאות לעלויות אלה:
חוב טכני אמיתי כמו תשלומי ריבית. עם זאת, בדרך כלל זה מתבטא ב- P&L באופן עקיף יותר מאשר הוצאה פשוטה של קו 'ריבית', כמו בדרכים הבאות:
ספירת ראשים
מעל
מכירות
הוֹן חוֹזֵר
בעוד שעלויות קשות קשורות אליהם סכומי דולרים בפועל, יש גם עלויות רכות שלמרות שקשה יותר לכמת ולממש חיסכון, יש להן גרור מוחלט לתוצאות העסקיות שלך. אלו כוללים:
מודיעין שוק
פִּריוֹן
אם מסתכלים על השוואה בין חוב טכני ופיננסי, אחד ההבדלים העיקריים הוא שלראשונה אין שליטה רשמית. עם חוב פיננסי, בדרך כלל יש ועדות אשראי, צוותים לניהול נכסים והתחייבויות, ואנשי משרד האוצר שעוקבים אחר רמות כמו נץ. עם זאת, עם חוב טכני, מעט מאוד מהבקרות הללו קיימות בעסקים מסורתיים.
עם חוב מסורתי, הדירקטוריון, יחד עם מנכ'ל וסמנכ'ל הכספים, בדרך כלל קבעו את מבנה ההון, כלומר, כמה הון עצמי, כמה חוב ואיזה סוג חוב (אקדח, מבוסס נכסים או וניל ללא אבטחה). טבלת המכסה אפילו מפורשת איזה חוב ישולם ומתי. לאחר שהכל יוחלט רשמית, מתחיל תהליך מובנה לגיוס החוב.
המלווים בוחנים את יכולתה של גוף להחזיר חוב באמצעות הערכות ההיסטוריה של החזר החוב, דירוג האשראי ואיכות הבטוחות המגובות אותו. עם זאת, אף אחד מהתהליך הפורמלי, הכימות וההחתמה אינו קורה כאשר נוצר חוב טכני. בואו נסתכל כיצד ומדוע מדובר בתהליכים בהם נוצר חוב טכני:
הזמן לשיווק הוא הכל בעסקים. יישום טכנולוגיה חדשה הוא הרבה יותר מהיר לעשות כאשר ניתן לעשות זאת על בסיס עצמאי. למרבה הצער, ההשלכות של זה הן שמערכות אחרות אינן מסונכרנות עם היישום. עבור ארגונים רזים עם מחסנית טכנולוגית פשוטה, זה אולי לא נראה כל כך רע.
זה הופך להיות בעייתי, כאשר תצורות המערכת מתרבות במורכבותן. בסופו של דבר, הטכנולוגיה אוטומטית של תהליכים ותופסת נתונים שהופכים למידע. טכנולוגיה שאינה משולבת מביאה לתהליכים עסקיים שאינם עובדים יחד ובמספר גרסאות של האמת.
כאשר מקריבים זמן על מהירות, ניתן להתעלם מפרוטוקולי בדיקה מבוססים או לתת להם ויתור. בדרך כלל זה גורם ל'באגים 'בהמשך הדרך שמתבטאים בצורה כלשהי של השפלה במערכת והסחת דעת של זמן המפתח לתיקונם.
אם נסתכל על ההשפעה של חובות טכניים לאורך זמן, ככל שהנושא נותר ללא פגע, כך גודל ההשפעה יהיה גבוה יותר. מה שמתחיל כתרגיל קטן לשיקום קוד יכול לכדור שלג למאמץ מודרניזציה והחלפה שלם בהמשך הדרך.
בואו נודה בזה - צוותי ההנהלה נמצאים בלחץ מתמיד לפגוע במספרים. עיכוב ההוצאות היום יכול לעזור לך לבצע את הרבעון, אך בדומה להלוואות, עליך להחזיר אותו בשלב מסוים. להלן מספר דרכים בהן חברות חוסכות כסף בטווח הקצר, אך בסופו של דבר נגרמות חוב טכני:
לעיתים העלות והבעיה ביישום עדכון תוכנה תקופתי עלולות לגרום לעיכובו. לפעמים זה נמשך שנים. כולנו אשמים בהפסקת כוח אוטומטית של מיקרוסופט עדכון כאשר זה מופיע בזמנים לא נוחים.
כאשר בסופו של דבר מערכות עומדות מאחורי הגרסה הנוכחית שלהן, תוכנות חדשות יותר שצריכות להשתלב בה פשוט לא יכולות. יתרה מכך, שדרוג של מספר גרסאות בו זמנית הוא בדרך כלל יקר יותר וכמעט תמיד יותר זמן מאשר לעמוד בקצב.
ככל שארגונים הולכים וגדלים במורכבותם, המאמץ העצום של סנכרון מחזורי עדכון חומרה יכול להיות מכריע ויקר. זה יכול לגרום למתיחת החומרה הנוכחית לפערים הקיצוניים והגדולים הקיימים בין איכות החומרה בקרב הצוותים. יש צוותים שמתוסכלים, קונים חומרה חדשה ופשוט מוציאים את זה באמצעות תקציב השולחן שלהם במקום לחכות ל- IT שיניע את השדרוגים.
לפער זה השלכות על פרודוקטיביות ותאימות חומרה / קבצים לתרגילים משותפים.
במקום רק לדבר על בעיות, בואו נפעיל קצת יוזמה ונקבע כמה פתרונות לפתרון חובות טכניים.
לשם כך אנו יכולים להיעזר בטכניקות המשמשות לניהול חוב פיננסי. על מנת לנהל את ההתחייבויות שלך, ראשית עליך לדעת מהן, כמה הן ותנאי התשלום שלהן. בואו נעבור את זה למען חובות טכניים.
חוב פיננסי מגיע בחלקים אשר מוגדרים על ידי הוותק של כל חלק (למשל, בכיר, ביניים או אקדח), שמצידו מראה מי מקבל את התשלום הראשון. לחוב טכני דפוס ותק דומה; ראשית, עליך להתחיל במערכות קריטיות למשימה שלך. איזה חוב טכני יש להם? ואז הסתכל על המערכת האקולוגית הרחבה יותר - ליתר דיוק, איזה חוב טכני בֵּין המערכות שלך גורמות להוצאות?
אל תסבך יותר מדי את התהליך הזה. בשלב מסוים, אתה רוצה להגיע להערכה מלמעלה למטה, אבל אתה לא צריך להתחיל שם. שאל את ראש ה- IT למשוך את צוות הניהול שלך יחד עם שיעורי הבית הבאים:
אם פינינו לחלוטין את כל החובות הטכניים שלנו לפני שנה, איך השנה (או השנה הקרובה) היו יכולים לשחק טוב יותר?
קבל את עשרת הרעיונות המובילים שלך והכנס אותם למטריצה של 2x2: קל / קשה לשלם על ציר אחד ומידת היתרונות על השני. אני מקווה שהוויזואליה תעזור לך להבין מאיפה להתחיל.
מטריקס סיעור מוחות ברזולוציית חובות טכניתהיתרונות של פתרון ► | חָזָק | ||
---|---|---|---|
חלש | |||
קָשֶׁה | קַל | ||
▲ מאמץ לשלם |
משם, תרגיל פנימה כדי לאמת את ההנחות שלך לגבי גודל הפרס והמאמץ. נייטרליות היא המפתח כאן, אז היזהרו מיצרני תוכנה שמציעים לבצע 'הערכה חינם'.
ברגע שאתה יודע איזה חוב טכני יש לך, עכשיו עליך להחליט איך להתמודד איתו. ישנן אפשרויות רבות לקחת.
בסופו של דבר זה הכי טוב שלא לעשות כלום. לגבי חובות המוערכים כ'קטנים 'או עם' ריבית נמוכה ', ייתכן שיהיה אופטימלי פשוט לעזוב אותו - כמו כן, אם יש' קנס של תשלום מראש 'של פירעון מוקדם. יכולים להיות גם יתרונות אסטרטגיים. להיות גרסה אחת מאחור ולהישאר שם זה בדרך כלל בסדר ולפעמים יש את היתרון בכך שקורצים מסתדרים בגרוש של מישהו אחר.
החזר כספי או צמצום חובות טכניים יכללו החלפת מערכות ולקיחת מכה בעלויות. ניתן לעשות זאת באופן מיידי, או לאורך זמן באמצעות תהליך של שיפורים הדרגתיים. כמו בחובות פיננסיים, ישנן דרכים יצירתיות בהן ניתן 'למחזר' חוב טכני, כאשר מיקור חוץ של תחזוקה הוא כזה. בסופו של דבר זה עשוי לעלות יותר לפתרון, אך ניתן לפרוס אותו כדי להוריד את פגיעת העלות המיידית, ובאמצעות עקרונות חלוקת העבודה, הוא מאציל את המשימה לגורם מיוחד יותר.
הופעתו של תוכנה מבוססת ענן ושירותי חומרה מביא גם השוואה לפופולריות של מימון מבוסס חכירה. שימוש בשירותי ענן הוא גם כלי יעיל להפחתת חובות טכניים, הן בהסרת דרישות CAPEX והן בהעברת מיקוד הפיתוח לספק הענן.
אל תציף את עלות הפחתת החוב הטכני שלך ואל תנסה לשלם אותו בבת אחת. זה יהיה תרגיל שאפתני שיכול להציף ארגון בכל גודל או מאזן.
שוב, אם נחזור להשוואות הכספיות, יש מנטליות של תשלום כרטיס האשראי עם הריבית הגבוהה ביותר תחילה. פירוש הדבר פשוט לתקוף תחילה פעילויות בעלות ערך / מאמץ נמוך.
בחלק הקודם דנתי בדרכים השונות להתמודד עם חובות טכניים. כאשר מעריכים את העלות של כל אחד מהם, עדיף לבצע תרגיל השוואה. דירוג עלות תזרים המזומנים של כל תוצאה פוטנציאלית יכול לאפשר לבעלי העניין לקבל מבט ברור על הפשרות והיתרונות של כל מסלול. דוגמה לוויזואליה כזו כלולה להלן.
השוואה זו מראה על הפשרה הקיימת בין פתרון תיאורטי לבין הניגוד הגמור בין פתרון הבעיה לבין עשיית דבר ('בסיס בסיס קיים'). בדוגמה זו, מעבר לענן, פתרון מבוסס SaaS יהיה האופציה החסכונית ביותר ללקיחת העסק.
לאחר שתקבע את קו הבסיס ואת תוכנית ההתקפה שלך, תרצה לשמר את הנראות ולמנוע זחילה של חוב חדש. חשוב על התרגיל כעל התחלה חדשה וסיכוי ליישם שיטות עבודה מומלצות כדי למנוע בעיות מעולם יעלה מדרגה בעתיד.
לרוב הפרויקטים הטכנולוגיים יש תהליך אישור רשמי עם חסות מנהלים, מטרה ברמה גבוהה, יתרונות צפויים, לוח זמנים וכמובן עלויות. זהו מקום נהדר לזרוק חוב טכני חדש שייווצר והצדקה לכך.
אל תתלהב יותר מדי בקביעת סטנדרטים חדשים. בדיוק כשאתה מנפיק כרטיסי אשראי ארגוניים עם מגבלות קבועות מראש, אינך רוצה לנהל יתר על המידה את החוב הטכני. הרבה חובות טכניים הם קטנים וקשורים לכתיבת קוד שישולמו במהירות. זה נכון במיוחד עם התפתחות זריזה. סמוך על ראש ה- IT שלך שיקבע את סף זה ויבקר אותו.
בחברות גדולות יותר, ל- IT יש תהליך שנקרא ' שינוי הנהלה . ” לפני שתוכנה חדשה מופעלת, היא עוברת בדרך כלל ניהול שינויים. במילים פשוטות, תפקידו של ניהול שינויים הוא להבטיח ששינויים חדשים במערכת הטכנולוגיה של החברה לא ישפיעו על מערכות אחרות. הם עושים זאת על ידי הקפדה על כך שהמערכת החדשה תואמת לשיטות ונהלים סטנדרטיים. שקול להשתמש בתהליך זה כדי למנוע או לפחות לזהות הכנסת חוב חדש.
חוב טכני הוא עלות אמיתית של עשיית עסקים וגורם אמיתי להפסקות מערכות ולגרור אחר זריזות החברה הכוללת. זה לא חייב להיות נטל מתמשך סמנכ'לי כספים חכמים יידע כמה חוב טכנולוגי יש לארגון שלהם ומה יידרש כדי לייעל אותו.
עלויות קשות מייצגות הוצאה מוחשית שנוצרה בדוח רווח והפסד. אלה יכולים לכלול מספר עובדים, שכירות וחומר. עלויות רכות הן עלויות בלתי מוחשיות שאינן הוצאות ישירות, המתייחסות לפיצויים ועלויות הזדמנות שקיימות - למשל, עבודה העובדת שעות ארוכות יותר עקב ציוד לא אופטימלי.