מרוב עצים לא רואים את היער - השפעת ריבוי כלים על הפרודקטיביות

כאשר גוף מערכות מידע או כל יחידת פיתוח מוצאת את עצמה עם המון כלים וללא יכולת תנועה... פתיח:

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

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

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

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

המשמעות היא שפרודקטיביות ה IT יורדת ככל שנישענים עליה... מדאיג, לא?  

"כל הטוב הזה", כל הפתרונות האידיאלים, כל הכלים החזקים, כל משפרי התפוקה ומקלי העבודה למיניהם, כל פריצות הדרך בבסיסי הנתונים, הגמישות במיקום (בענן ציבורי, היברידי, באתר הלקוח וכל הקומבינציות), בממשקי המשתמש, בכלי פיתוח משוכללים, ה Front-End, ב Back-End, בכלי ממשק קלים להגדרה, ב Low-Code, במתודולוגיות מדהימות, בחיזוקי האבטחה ו....חד גדיא - ייתכן שלא עושים לנו כל כך טוב? ייתכן שההיצף, שרק מתגבר, יכול להטביע אותנו?  

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

איך קורה שאנחנו צוברים כלים? 

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

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

• הרצון לפגוש את הלקוחות בכל המדיות שהם נמצאים.ות (Web, Mobile OS/Android, omnichannel,API) ובכל אחת מהן להתאים את סט הכלים המיטבי למדיה, לקהל היעד, למערכות חיצוניות מייצר מגוון רחב של כלים. והמדיות - מתרבות. 

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

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

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

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

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

• קורח ארגוני כמו רגולציה ואבטחת מידע. 

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

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

החסרונות בריבוי כלים: 

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

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

נעלה כמה נקודות המצביעות על הבעיה הנובעת מריבוי כלים: 

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

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

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

• בכל ארגון הכלים בד"כ מחוברים ביניהם, קרי -חייבים אינטגרציה. במקרה המירבי (שכל הכלים מחוברים לכלי האחרים) נניח שיש N כלים ופלטפורמות אז כמות החיבורים תהיה N*(N-1). נכון - בד"כ לא הכל מחובר להכל. מצד שני, לא תמיד הכלים מחוברים במיישרין, כלומר יש בינהם עוד שכבות (כמו FW , LB, Service Bus וכיוצא באלה) לכן עדיין סדר הגודל של כמות החיבורים נותרה N**2. המשמעות היא שלהוספת כל כלי, יש תקורות, מתחת לפני השטח, באינטגרציה, בדיווח (BI), בניטור ובאבטחת מידע, שכמעט אף פעם לא לוקחים בחשבון. על כך נוסיף את הצורך בסביבות פיתוח ובדיקות, גיבויים, שרידות, מה שמוריד מאוד את החשק להוסיף כלים. 

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

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

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

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

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

דגשים לניהול נכון של כמות הכלים בארגון

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

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

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

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

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

• לסרב לכלים שהערך המוסף שלהם קטן. 

• תזמון: לעיתים די ברור שטכנולוגיה מסויימת הולכת להיטמע בארגון. השאלה: מתי? הרעיון הוא לא להשקיע מראש ועל חשבון העתיד. אלא רק כשהוחלט שמיישמים. כאשר מיישמים - מיישמים בכל הכוח. 

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

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

לסיכום: 

ריבוי כלים מייקר את עלות הבעלות של כלל מערכות המידע, מייצרת מורכבות המורגשת בעיקר ב Time-To-Market של הפתרון הבא ובעת משבר (התאוששות מכשל) על כן, ארגון חכם, ידע להתנהל לפי עקורונות אלה:

1. פוקוס - זו מילת המפתח. כי ההפך זה: "תפסת מרובה - לא תפסת".  

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

3. אין כזה דבר "כלי חינמי". הכל עולה והרבה.

תפסת מרובה - לא תפסת

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

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