ביצוע עבודה בנקאית ברת חיבור

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

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

כמה שנים לאחר מכן, הבנק רצה לנסות את מה שהיום ייקרא זריז, אבל אז היה Rapid Application Development. המטרה הייתה להאיץ את האופן שבו סיפקנו את הפתרונות שלנו. היינו הראשונים בתחום ה-IT שהיו חמושים במחשבים ניידים ואפילו בטלפונים ניידים. הוציאו אותנו ממשרד ה-IT וקיבלנו משרד באחת מהיחידות העסקיות.

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

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

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

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

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

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

1. ארכיטקט ארגוני (EA): מישהו השולט בפתרון הכולל ברמה גבוהה, המבטיח שימוש חוזר ועקביות מקסימלית. ארכיטקטורת BIAN היא דוגמה טובה למשהו ש-EA יכול ליצור. BIAN מספקת מודל נהדר ליישום של "אבני בניין" הניתנות להרכבה עבור ארכיטקטורת בנק שלמה.
2. יוצרים: מפתחים שיוצרים ומפרסמים את אבני הבניין של חישוב, פונקציונליות או יכולת עסקית בודדים.
3. אוצרים: תפקיד בניהול "הספרייה" או השוק של אבני הבניין. ספרייה זו צריכה לכלול גם כל פתרון קנייני או צד שלישי שנרכש.
4. מלחינים: צוותים המרכיבים פתרון מאבני בניין, תוך שימוש בפלטפורמות וכלים של הרכב יישומים, אך לא בהכרח.
5. צרכנים: המשתמשים בפועל של האפליקציה.

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

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

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

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

על הסופר

Dharmesh Mistry עוסקת בבנקאות כבר יותר מ-30 שנה והייתה בחזית הטכנולוגיה והחדשנות הבנקאית. החל מהאפליקציות הראשונות של האינטרנט והבנקאות הסלולרית ועד לבינה מלאכותית (AI) ומציאות מדומה (VR).

הוא היה משני צידי הגדר והוא לא חושש לחלוק את דעותיו.

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

עקוב אחרי דהארמש בטוויטר @dharmeshmistry ו לינקדין.

קרא את כל הרהורי "אני רק אומר" כאן.