Low Code vs. "Best Of Breed" approach

או פיתוח מהיר מול התאמת מערכות מדף לארגון

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

יש בעיה בגישה למערכות מדף הקיימות...

הצורך בפלטפורמות לפיתוח מהיר, לא נבנה בריק.

האתגרים העומדים בפני רוב יחידות ה IT הם בגדר בלתי אפשריים.

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

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

אם כך – לארגונים שמוצריהם כבר נמכרים בהצלחה, אין זכות קיום מחר?

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

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

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

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

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

תבדקו את עצמכם – זה המצב בארגון שלכם?

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

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

· למערכות שלכם נדרש ידע קנייני רב? כלומר אתם תלויים בכוח אדם ספציפי, בספק ספציפי?

· הכשרה של כוח אדם נוסף לגיבוי או שיפור עלויות הוא ארוך מאוד ויקר?

· כשאתם עסוקים בהטמעת המערכת, משתמשים חדשים (בעיקר צעירים) מתקשים באימוצה?

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

מה Low Code מחדש בתפיסה?

ה Low Code אינו רק אבולוציה של כלי ה RAD הוותיקים.

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

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

2. זמן הכתיבה מחדש יהיה קצר יותר מלתחזק פתרון של קוד כתוב בשפת דור 3.

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

השבוע קיבלתי גיג ב Whats APP :

חדר בריחה?

שזה חדר הבריחה הקשה ביותר...

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

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

ובשורה המשפיעה על האסטרטגיה של פתרונות מחשוב לארגונים.

שהרי, אם להתאים פתרון ככפפה ליד, זול יותר ומהיר יותר מלהכניס "Best of Breed" – חוקי המשחק השתנו.

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

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