מערכת המידע "תקועה"? להחליף או לתחזק? ו...פרדוקס מערכות המידע.

"תקועה! מה זה תקועה? רק לעבור על רשימת התיקונים, השינויים והתוספות ייקח לנו שבועות..."

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

אין ארגון שלא חש את התסכול הנובע מהפער שבין הצורך העסקי והרווח המוחשי שמאחוריו, לבין ה Time To Market של הפתרון הכרוך בשינוי כלשהו במערכת הארגונית.

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

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

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

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

מערכת שלה משתמשים רבים, או אם נדייק - רוב המשתמשים השותפים בתהליכים אותם היא משרתת, ואשר על גבה מבוצעים התהליכים/משימות שלשמם יועדה.

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

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

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

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

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

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

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

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

העקרון הראשון והשני משולבים, קרי: יש הצלחה – אז גם יש לה מחיר.

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

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

זה נראה קל.

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

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

אם נתעלם ממערכות שהוטמעו באופן לא מוצלח - כגון:

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

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

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

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

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

1. מודולריות או תפיסת ה Web Services:

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

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

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

2. ניהול הדוק של רשימת השינויים/תוספות/תקלות במערכת:

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

3. הפחתת החוב הטכני:

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

4. בחירת מערכות ליבה אקסטנסביליות (ניתנות להרחבה):

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

5. צימצום מערכות וארכיטרטורה ארגונית חכמה:

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

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

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

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

6. הסכמי ספקים, ארוכי טווח התואמים את הצורך הארגוני האמיתי:

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

7. יישום תורה אירגונית לניהול הידע:

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

8. התאמת המשאבים במערכת לצורך:

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

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

9. שילוב כלי פיתוח מהיר - Low Code:

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

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