תפריט נגישות

IT איטי

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


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

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

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

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

והסיבות כרוכות בין היתר בבזבוז עצום הכרוך בשיטות העבודה שאימצנו במשך השנים :

1. מורכבות מיותרת : מנסיוננו כמנהלים וכיועצים , וממחקרים שעורכים גופים שונים לאורך השנים עולה כי במערכות תוכנה ייעודיות, לא יותר מ- 2/3 מה- Features אכן דרושים , ומביאים ערך בתהליך העסקי בו הם תומכים. לעיתים קרובות Feature –ים שפותחו לא רק שלא מביאים ערך אלא גם לא נמצאים בשימוש. המורכבות המיותרת מונעת שימוש יעיל במערכות, ומגדילה את הצורך בהדרכה והטמעה. זאת בנוסף למאמץ המיותר בתכנון, פיתוח ותחזוקה, מאמצים שניתן היה להשקיע בפעילות אחרת המביאה ערך. במונחי לין זהו בזבוז המזוהה כ- Overprocessing – לעשות יותר מאשר נדרש להבאת ערך ללקוח. יש סיבות מדוע זה קורה ולא נדון בהן כאן.

2. איכות : שגיאות תכנון ותכנות מהוות בזבוז. לפי מחקר שנערך ע"י אוניברסיטת קרנגי מלון בקרב 13,000 מפתחי תוכנה, מפתח מנוסה ומקצועי מייצר מעל 100 שגיאות תכנות בכל אלף שורות קוד. כתוצאה מכך חלק ניכר מתקציבי הפרויקטים ומהזמן המושקע בהם – מוקצים לטיפול בתקלות שהם עצמם ייצרו . בנוסף לכמות האדירה של Rework , הולך לאיבוד זמן רב, נוצרים תסכולים ושחיקה, הפרעה ללקוחות ול- Business וכמובן מאמץ משמעותי מאוד לספק תמיכה טכנית כשמתגלה תקלה. לא רק שחשוב מאוד לגלות ולתקן שגיאות קרוב ככל האפשר למקום היווצרותן, אלא שעלינו למנוע את היווצרותן של שגיאות ואת כניסתן לקוד, כמו גם למנוע את כניסת Features מיותרים לקוד לכתחילה. התופעות האלה ניתנות לטיפול ולצמצום תוך שימוש באחד העקרונות של Lean - Quality at the Source .

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

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

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

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

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

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

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

במונחי Lean Software Development מערכת כזאת צברה "חוב טכני" : זהו סוג של משא או עול של חומר מורכב ולא עדכני (אפיונים מפורטים שאינם עדכניים עוד, תוכנה שפותחה ולא נעשה בה שימוש) שיום אחד, כאשר יהיה צורך לבצע שינויים, יהיה צורך לשלם בגינו . בקונטקסט רחב יותר של Lean Enterprise Transformation , פיתוח תוכנה בפרקטיקה כזאת עוצר מאמצים לשיפור בתהליך העסקי, שלעיתים קרובות תלוי בשינויים קטנים ותכופים.

Lean-IT ובכלל זה Lean Software Development מציעים כלים מעשיים להתמודד עם המצב הזה ולשנותו.

כותבת המאמר: עדה מרקמן, מנכ"לית משותפת ב-BDA
ליצירת קשר: ada@bda-projects.co.il