לגעת בפער - שבין החלפת מערכת לבין הרחבת השימוש במערכת הקיימת


מדוע המערכת הישנה "תקועה"?

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

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

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

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

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

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

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

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

מהי מערכת מוצלחת?

הפשט: מערכת שלה משתמשים רבים ואשר על גבה מבוצעים התהליכים/משימות שלשמם יועדה.

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

עקרונות יסוד

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

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

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

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

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

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

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

הפיתוי

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

זה נראה קל.

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

ההבדל בין מערכת ישנה לחדשה

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



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

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

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

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

  • משהו קרה לספק או להסכם איתו, באופן שלא ניתן יותר להתבסס עליו.

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

הצעות לשמירת המערכת הקיימת כ"חדשה"

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

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

תפיסת ה Web Services או בניה מודולרית:

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

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

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

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

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

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

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

צימצום מערכות:

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

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

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

יצירת ארכיטקטורה ארגונית חכמה:

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

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

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

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

· שילוב כלים המאפשרים את אותם הפתרונות לכל(!) המערכות. למשל: בסיסי נתונים, BI, ניטור, כלי ETL ו Service-Bus. אחרת - מגדל בבל.

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

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

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

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

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

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

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

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

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

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