מבוא

מדוע עלויות ה-IT בחברות תפעול ממשיכות לעלות משנה לשנה? אפילו בתנאים כלכליים חלשים, תוכניות חדשות ממשיכות להופיע תחת תוויות כמו DX, אימוץ AI ורפורמה עסקית. כל יוזמה בודדת נראית לרוב סבירה. בדיוק בגלל זה קשה לעצור את המגמה הזו.

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

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

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


ראשית, הסר אי הבנה נפוצה

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

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


מה קורה בשטח

דפוס נפוץ הוא:

  1. הצעות חדשות נתפסות כחיוביות ומכוונות עתיד.
  2. קל יותר לאשר מערכות חדשות לפרודוקטיביות או לסטנדרטיזציה.
  3. בתרבות המדגישה יתר על המידה הרמוניה, קשה לבקר הצעות בעלות מראה חיובי.
  4. מספר המערכות עולה.
  5. עלויות הרישוי, התחזוקה, התפעול, הביקורת וההדרכה עולות יחדיו.
  6. ברגע שהיחידות העסקיות תלויות בהן, הפרישה הופכת לקשה מבחינה פוליטית.

מחזור זה חוזר ועלויות קבועות מצטברות.


מדוע העלויות ממשיכות לגדול גם כשהיוזמות נראות נכונות

1. השקות תגמולים לניהול ביצועים יותר מאשר פרישות

ארגונים רבים מעריכים:

  • מה הושק,
  • כמה פרויקטים הוצגו,
  • כמה אטרקטיבית נראית המצגת.

אך לעתים רחוקות הם מעריכים באופן שווה:

  • מה פרש בבטחה,
  • איזו חפיפה הוסרה,
  • כמה הופחתה העלות הקבועה העתידית.

2. “חיסכון ללא עימות” זוכים לשבחים; “חיסכון הליבה” נמנע

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

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

החיסכון היעיל ביותר יוצר לרוב את מירב החיכוכים, ולכן הם נמנעים.

3. בלבול תפקידים בין טרנספורמציה עסקית ל-IT

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

4. קריאה שגויה של בטיחות פסיכולוגית

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

5. הערכת מנהלים גולשת לעבר ערך המצגת

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


מדוע איחוד הוא דרך קוצנית

איחוד דורש הבנה טכנית ותפעולית מפורטת:

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

ללא יכולת זו, תוכניות פרישה נשארות סיסמאות.


משוואת העלות

משוואה פשוטה היא:

עלות IT לשנה הבאה = עלות קבועה בשנה שעברה + עלות קבועה שנוספה על ידי יוזמות חדשות - עלות הוסרה על ידי פרישה/איחוד

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


סיבות שורש

  1. מערכות הערכה מוטות לתוספות.
  2. הבעלות בין העסק ל-IT מטושטשת.
  3. בטיחות פסיכולוגית מיושמת לא נכון כהימנעות מקונפליקט.
  4. למקבלי החלטות אין לרוב חשיפה ישירה לחיכוכים בשטח ולחובות טכניים.

מה אפשר לעשות

אפשרות א’: התערבות חזקה לצמצום עלויות

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

אפשרות ב’: למנות מנהיגים שיכולים לקבל ולספוג החלטות כואבות

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

פעולות מעשיות:

  1. הקצה בעלים ברמה העליונה לקבלת החלטות פרישה ואיחוד.
  2. הוסף KPIs לפרישה (מערכות שיצאו לפועל, הסרת חפיפה, הפחתת עלות קבועה, ביטול תלות).
  3. לתת למנהיגות האדריכלות סמכות וטו וגיבוש פורמליים.
  4. איסור התנהגות פסיבית של “המתנה ל-EOL”; דורשים מפות דרכים של תלות-יציאה.
  5. העריכו את “מה הסתיים” באותו משקל כמו “מה התווסף”.
  6. הקצה בעלי צד עסקי לכל פרויקט איחוד.
  7. להכיר ולתגמל צוותים שטיפלו בחיכוך בלתי נמנע באחריות.

מציאות ביצוע

הבעיה האמיתית היא לא שרטוט מפות דרכים יפות. זה להחליט מי לוקח איזה כאב, מתי, ובאיזה אחריות.

ההנהלה הבכירה חייבת:

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

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


תגובות להתנגדויות נפוצות

“אבל אנחנו צריכים יוזמות חדשות”

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

“איחוד פוגע בפעילות”

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

“אין לנו מנהיגים מתאימים”

זו אולי הסיבה המדויקת שהעלויות ממשיכות לעלות.


סיכום

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

יכולת הניהול החיונית היא לא רק הכוח להוסיף. זה הכוח לסיים - בהגינות, בשקיפות ובאחריות.


מאמר קשור


הפניות

[1] מועצת ה-CIO האמריקאית, Application Rationalization Playbook. https://www.cio.gov/assets/files/Application-Rationalization-Playbook.pdf