מזל טוב. יש לכם בעיה, פרויקט, תקציב ודד-ליין. במקום לזרוק על זה גופות, תוכנה היא הפתרון אבל עכשיו אתה צריך להחליט לבנות או לקנות, זו השאלה. או שזה? אני כבר לא כל כך בטוח שזו החלטה ברורה.
בנה שימוש להתייחסות לשכירת מתכנתים בבית כדי לקודד כל מערכת שהייתה נחוצה ולקנות בהתייחס למוצרי המדף שניתן לרכוש ולהפעיל. זה היה הגיוני כשדיברנו על מערכות חשבונאות, מערכות מסחר, CRM, דיווח,
הלוואות, גביות, CLM וכו'. אנו חיים כעת בסביבת הקוד הנמוכה שבה בניית משהו לא דורשת ניסיון בקידוד. זה יכול להיות גרור ושחרר. יחד עם זה עם קניית פתרונות מדף שבסופו של דבר מותאמים אישית עד כדי כך
ובכן בנו את זה. אז איפה זה משאיר לנו את ההחלטה לבנות או לקנות? בואו נראה מה אנחנו באמת צריכים.
אף מערכת מודרנית לא יכולה יותר לסמוך על נקודת כניסה אחת. ציפיות הלקוח מכתיבות שיש צורך בערוצים שונים. באופן אישי, בטלפון ישיר או מוקד טלפוני, דוא"ל, מדיה חברתית, SMS, אינטרנט, נייד, טאבלט - גם מופעל נייד וגם מקורי
אפליקציות, והכל עם הצורך להיות ניתנים להחלפה מבלי לאבד תוכן או הקשר. לקוח שמתחיל בסניף/חנות או באופן אישי אבל צריך לצאת לקביעת פגישה רוצה להיות מסוגל להמשיך מאיפה שהפסיק כאשר הוא נכנס מאוחר יותר באותו היום באינטרנט. אוֹ
אם הם מתחילים באינטרנט אבל מתוסכלים ומתקשרים לעזרה, הם לא רוצים להתחיל את התהליך מההתחלה. זה חל גם על בעלי עניין פנימיים. שרשרת המידע בתוך ארגון צריכה להיות גמישה כמו מול הלקוח
אפשרויות.
אז מה הלאה עבור ההתחלה שלנו בכל מקום קלט נתונים? ובכן, יש סיבה שאנחנו צריכים את הנתונים האלה מלכתחילה. בין אם לקוח חדש רוצה לעבוד עם הארגון, לקוח קיים רוצה מוצר או שירות חדש, או אפילו סתם שאילתות יומיומיות, תלונות
או בקשות מידע. כל אלה צריכים להתחיל בתהליכים מוגדרים אך גמישים כדי להשלים את הבקשה בצורה יעילה וקלה ככל האפשר. התהליך מוגדר בדרך כלל ובדרך כלל הצוות מאומן לעקוב אחר רצף של משימות כדי להשלים אותו עם קבוע מראש
פעולות המבוססות על קלט נתונים מסוימים.
לא לקוחות קצה ולא משתמשי מערכת צריכים להזין מחדש מידע בשום מקום אם הוא כבר נלכד איפשהו. למעשה, אם מידע זמין בכל מקום בתוך הארגון או ממקורות צד שלישי כמו ספקי נתונים, לשכות אשראי,
ספקי מיון וכו' זה צריך להיות נגיש לאורך כל התהליך עבור כל המשתמשים הזקוקים לכך. התהליך מוגדר אך נקודות המגע צריכות להיות ניתנות להחלפה לאורך כל הדרך והנתונים שנאספו צריכים להיות משולבים במידת האפשר ומובנים היכן שניתן.
תפריטים נפתחים, ערכי חיפוש, שדות תאריך וערכי טקסט חופשי מבוקרים כדי להבטיח כמה שיותר איכות נתונים מלכידת מראש. זה מאפשר הרבה יותר אוטומציה לאורך התהליך ופחות טיפול בחריגים.
כעת, כאשר נתונים נמצאים בתהליך של לכידה או עדכון פעיל, ניתן ליישם את הבינה המלאכותית. הצוות לא צריך לדעת את כל הפרטים ואפילו חברים חדשים יותר יכולים לעבוד על מקרים מורכבים יותר מכיוון שהמערכת משתמשת בכללים מקודדי מדיניות
היגיון לקבל באופן אוטומטי החלטות שלעבר הצוות היה צריך להיות בעל הכשרה וניסיון נרחב להתמודד. אין יותר טעויות תוך מתן אפשרות לפיקוח ואפילו בדיקות בקרת איכות או תורי חריגים מוחלטים להתערבות ידנית במידת הצורך.
כל זה דורש גישה שיטתית. הרעיון הישן של תיקיית מנילה שיושבת במגירה של אנשי הצוות לתיק הלקוחות שלהם מיושן ויוצר סיכון מיותר. לקוחות המעובדים בבידוד יכולים להיות מגבילים וגם מיותרים
באותו הזמן. אם ללקוח תאגידי יש דירקטורים שיושבים מול מספר לקוחות אחרים, מדוע שכל ביקורת פרטנית תתעלם מהתמונה הרחבה יותר. האם אתה גם הולך לסקור את אותו במאי מספר פעמים בכל מערכת יחסים או שאתה יכול
לעשות זאת פעם אחת ולהשתמש מחדש במידע הזה ברחבי הארגון?
הם אפילו לא צריכים שיהיו להם צדדים קשורים משותפים כדי שהתועלת תהיה ברורה. תעשיות דומות, לקוחות לקוחות דומים, מה אם הספקים/ספקים של הלקוחות שלך הם גם לקוחות בעצמם? זה מביא אותנו לאופן שבו אתה צריך לעבד את המידע
ומדוע ארגונים צריכים להסתכל על פני הארגון כאשר שוקלים תוכנה בימינו. אם אתה רואה בעיה בנפרד ומתייחס אליה ככזו, הקמת תקציבים והנפקת RFP עבור כל רכיב CRM, Fincrime, Client Outreach, אתה בסופו של דבר
עם הוצאה של יותר משאבים בניסיון לשלב הכל יחד מכל חיסכון פוטנציאלי שציפו לו בתחילה. כעת החל את זה עבור כל אזור או קו עסק שעשוי לקבל תקציבים נפרדים ופיקוח ובסופו של דבר תקבל 8 גרסאות
של אותה תוכנה שצריכה להיות משולבת עם עצמה עקב התאמה אישית כבדה לכל אזור המבטלת כל יתרונות גודל שהם יכולים להשיג.
תיקייה במגירה שצריך לעבור בדיקה שנתית או אחרת, כאשר הצוות צריך לקבל הכשרה מה לעשות ומתי לעשות זאת. ניתן לחלק את הסקירה כולה (או שילוב חדש/מוצר/שירות נוסף/וכו') לחלקים מרוכבים שעשויים או
ייתכן שלא יטופלו על ידי אנשים/צוותים אחרים. לאחר מכן, המערכת יכולה לקבוע מתי משימה הושלמה או מתי נלכד מספיק נתונים כדי להישלח לאדם הבא לקלט שלו. כל אלה בנויים כמקרים ותתי מקרים בתוכם. בדרך זו כל אלמנט של
לתיק יכול להיות מועד אחרון, נתיב הסלמה, מוקצה ומאשרים משלו. במקום משימה אחת גדולה שאיש צוות צריך להיות מנוסה מספיק כדי לדעת איך לבצע ולמי לפנות עבור אלמנטים שונים בתוכה, המערכת מקצה כעת את העבודה
ומבטיח את השלמתו בזמן בכל החברה עם כמה שיותר משימות אוטומטיות כדי לשחרר את מקבלי ההחלטות להתמקד במה שחשוב.
כל זה טוב ויפה מנקודת מבט עסקית. העבודה ידועה ומה צריך לעשות. אבל כשאנחנו מנסים להחליט אם כדאי לנו לקנות או לבנות את התוכנה בעצמנו, איך זה משפיע על הדברים? ובכן, נניח שיש מספר מקורות
של נתונים על פני מספר מערכות. כל מערכת מודרנית צפויה להיות מונעת על ידי API ובעלת יכולות קוד נמוכות/ללא קוד. הנחה סבירה לתוכנה מהירה וגמישה יותר. יש להתייחס לכל דבר בימינו כאל שירות מיקרו לסוגיו כדי להימנע
מונוליטים של תוכנות בסגנון ישן. יש להתקין ולהשתמש בתוכנה מכיוון שהיא הטובה ביותר הזמינה והמוגנת לעתיד כדי להסתגל לשינויים לפי הצורך. יותר מדי הצעות מושרשות ומתוחזקות רק בגלל שהן קשות מדי וגוזלות זמן
להחליף. רוב זה נובע מכך שהכללים מקודדים קשיחים, כנראה שזורים בנתונים עצמם, הנתונים לא רק משולבים אלא משוכפלים מספר פעמים עבור כל פיסת תוכנה נפרדת בשרשרת המידע, ואם תנסה להחליף חלק אחד,
כל המערכת עלולה להישבר. יותר מדי מתהליך החשיבה הישן, אם הוא לא שבור אז אל תתקן אותו. מה שבאמת צריך זה שכל חלקי הרכיבים האלה יהיו מיקרו-שירותים, נטילת נתונים הדרושים, יישום כללים אוטומטיים או קלט/ביקורת של משתמשים ו
מעביר אותו לשירות המיקרו הבא. אין לאחסן נתונים ביותר ממיקום אחד. זה עשוי להיות מאוחד אך לא משוכפל מחוץ לגיבויים. מערכות CRM, Onboarding, KYC, Client Outreach וכו' שלך צריכות לגשת רק לנתונים שהם צריכים ולא
להיות מאגרי נתונים עצמם אלא אם כן בחרת אחד כזה. שכפול אותם נתונים על פני מספר מיקומים והכללים השולטים בהם הוא תרגיל בחוסר תועלת שכן כל מערכת נוספת שנוספה תכפיל את המורכבות הכרוכה בכך.
זה מביא אותנו לשיקול הסופי. בין אם יש לך מקור יחיד של אמת/עותק זהב או מספר רשומות ומערכות מיותרות ומתחרות שיכולות לעדכן אותם, עדיין תמצא את עצמך בשכבה נוספת של דרישות המבוססות על שורה של
עסקים, תחום שיפוט, סוגי לקוחות ומוצרים/שירותים. אדם זוכה ליחס שונה מחברה או נאמנות, והוא שונה לפי תחומי עסק צרכנים/קמעונאיים, מסחריים או תאגידיים מבחינת דרישות והתאמה. בדוגמאות הבסיסיות ביותר אם
יש לנו 10 סוגי לקוחות (פרטיים - רווקים, נשואים וכו', חברה פרטית, חברה ציבורית, נאמנות, צדקה וכו') ואתם עשויים לפעול ב-10 אזורים, ואולי תציעו 10 סוגים של מוצרים/שירותים, אנחנו כבר ב- פוטנציאל 1000+ כללים שיכולים
להיות מיושם. האם לא יהיה הרבה יותר קל להגדיר כללים עבור אזור, עבור תחום עסק, עבור סוג לקוח ומוצרים או שירותים ולתת למערכת לפתור את הדרישות במקום זאת? הסרת כפילויות ושימוש חוזר בנקודות נתונים שהיו בעבר
מסופק. זה היתרון של הפשטת התהליך והכללים שלך משכבת הנתונים שלך.
אז עכשיו כשאנחנו בוחנים את השאלה הישנה של קנייה או בניית תוכנה, אנחנו יודעים שאנחנו צריכים תזמור רב-ערוצי, אוטומציה של תהליכים במידת האפשר, לוגיקה של כללים גמישים, ניהול תיקים לפיקוח וביקורת, קוד נמוך ומונעי API, תקציר
שכבת נתונים ומנוע חוקים אינטליגנטי שיכול לרשת משכבות לוגיקה שונות. שוק הטכנולוגיה מלא בחדשנים שמספקים בשמחה כל בעיית נישה שאפשר לחשוב עליה אבל באיזה שלב זה מפסיק להיות הגיוני להיות "מהמדף"
מוצרים שכולם צריכים להיות מותאם אישית ולשלב אחד עם השני במקום לבנות את זה בעצמך. פלטפורמות קוד נמוך יכולות לאפשר לך לקבל 80% מהדרישות שלך, ואתה רק צריך להגדיר את הדלתא של 20%. הטוב משני העולמות הוא שפל
פלטפורמת קוד שאחרים גם בנו עבורם רכיבים ניתנים לשימוש חוזר, כך שתוכל לקבל את מוצרי 'המדף' כמאיצים עבור העסק שלך, תוך יכולת עבור הצוות שלך או צד שלישי מוסמכים לבנות את שאר הדרישות הספציפיות
לארגון שלך. לקנות או לבנות? זה באמת צריך להיות שניהם.
