תוֹכֶן
- הבנת הדיון
- פנים או מחוץ לקופסה
- בינה עסקית אינה מוצר סחורות (עדיין)
- אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
- שותפות, לא עסקה חד פעמית
מקור: Cybrain / Dreamstime.com
להסיר:
אם אתה שוקל ניתוחים משובצים, עליך להסתכל מעבר לפתרונות הסטנדרטיים של "לבנות" או "לקנות".
ככל שהאנליטיקה המוטמעת הופכת לבולטת יותר ויותר בנוף הבינה העסקית (BI), נראה כי השאלה אם חברות צריכות לבנות או לקנות יישומי BI משובצים, רלוונטית מתמיד. הניסיונות הרבים לענות על שאלה זו מתעלמים מהעובדה הבסיסית שהשאלה עצמה מטעה, שכן עבור מרבית הארגונים אין תשובה פשוטה כן או לא. במקום זאת, שיטות עבודה מומלצות לניתוח משובץ אינן "לבנות" ולא "לקנות" - אך למעשה דומות יותר לשותפות.
הבנת הדיון
"ניתוח משובץ" הוא מונח שמיכה המתאר שילוב של תכונות שונות של כלי בינה עסקית ביישומים אחרים (לעתים קרובות, אך לא באופן בלעדי, ב- SaaS). לדוגמה, חברה שמפתחת תוכנת CRM אולי תרצה לספק תובנות מעמיקות יותר מהנתונים שהיא אוספת כדי לשפר את הצעת הערך הכללית של החברה או למכור שירות פרימיום. מכאן שייראה לשלב תכונות כמו טרנספורמציית נתונים, שאילתת נתונים גדולים מהירה או הדמיות אינטראקטיביות לחבילת תוכנת CRM משלה.
גרטנר העריך כי עד 2015, 25 אחוז מיכולות הניתוח יוטמעו, ויגדלו מחמישה אחוזים בלבד בשנת 2010. רוב אנשי המקצוע בענף ה- BI יסכימו כי ה- BI המוטבע הפך לתחום מרכזי במוקד העסקים והטכנולוגיה כאחד. לקוחות דורשים שירות עצמי, גישה משמעותית לנתונים, והתחרות מכריחה חברות להתאים לדרישות הללו, מה שמביא בתורם להתמקדות רבה יותר בבניית יכולות מסוג זה.
פנים או מחוץ לקופסה
שאלת "לבנות או לא לבנות" הפכה להיות נושא לדיונים סוערים כאשר שוקלים פרויקט אנליטי משובץ. בצע חיפוש מהיר של Google אחר "build vs buy embedded analytics", ותהפציץ עם עמוד אחר עמוד מאמרים שישאל ותנסה לענות על השאלה המדויקת הזו. אביא בקצרה את הטיעונים הנפוצים ביותר עבור כל צד בוויכוח:
- פיתוח תכונות BI פנימיות מעניק לחברות גמישות ושליטה רבה יותר במוצר הסופי. מפתח האפליקציות המקורי מוכר באופן אינטימי ביותר עם המוצר והלקוחות שלו, וכך יוכל להתאים פיתרון ליתר דיוק. אולם, בניית תכונות BI באופן פנים דורש השקעה משמעותית ולעתים קרובות מניבה תוצאות תת-נקביות בגלל רמת ההשקעה הנדרשת והצורך במיומנויות מיוחדות.
- קניית פיתרון "מחוץ לתיבה" מאפשרת לחברה למנף את ההשקעות האדירות שכבר עשתה ספק ה- BI ומאפשרת גישה ליכולות BI עדכניות.
ברוב המקרים, חברות שמבקשות לספק יכולות ניתוח נתונים משמעותיות ללקוחותיהן מוטב לחפש להטמיע מוצר קיים ולא להתחיל מהתחלה. עם זאת, מה שאני רוצה להדגיש הוא שהדרך בה מוצגת שאלה זו היא כשלעצמה מטעה: ללא ספק, התרחיש הנפוץ יותר - והעדיף - הוא למעשה לא בנייה ולא קנייה, אלא פיתרון שלישי שניתן לתאר בצורה מדויקת יותר כ שותפות.
בינה עסקית אינה מוצר סחורות (עדיין)
כשאנשים מדברים על "build vs buy", אפשר להתרשם שהאפשרות קיימת להיכנס לרשת ולקנות פיתרון BI משובץ סוהר, שאפשר לחבר אותו בקלות למוצר קיים ופרסטו! ניתוח מיידי מול לקוחות. למרבה הצער, כשמדובר בצרכים ומוצרים מתוחכמים יותר, זה כמעט ולא המקרה.
אני לא מתכוון לרמוז כי יישומי BI צריכים להיות עניינים ארוכים או קשים, אלא רק שכל יישום הוא שונה. חברה שבדרך כלל רוצה להציג מאה אלף שורות נתונים ללקוחותיה אינה זקוקה לאותו "שריר" טכנולוגי כמו זה שעובד עם מאה מיליון שורות; כמו כן, נתונים שמקורם בעשרות מקורות מובנים ולא מובנים הם שונים למדי מאשר טבלאות מאורגנות בצורה מסודרת במסד נתונים של SQL. הדמיית נתונים ברמה גבוהה היא דבר אחד (לדוגמא, אפליקציית מסחר אלקטרוני המציגה תנועה ומכירות למוכרים), ואילו ניתוחים מתקדמים, תרגילי פירוט ודוחות הניתנים להתאמה אישית דורשים יכולות שונות לחלוטין.
כשמדובר בסוגים אלה של מקרי שימוש מתקדמים יותר, הרעיון של פיתרון מתאים לכל גודל אינו מציאותי: יש לשלב את התכונות האנליטיות ביישום הקיים ולהתאים אותן באופן אישי לצרכים המדויקים של המוצר הספציפי. ובסיס לקוחות מבחינת דוגמנות נתונים, אבטחה, ניהול ודיווח. שוב, אין זה אומר שמאמצי שילוב אלה צריכים להיות מסובכים יתר על המידה או לדרוש משאבי פיתוח נרחבים - עם זאת, הם ידרשו הבנה של הנתונים העומדים בבסיסם, ויכולת להתאים אישית ולתקשר בקלות עם פלטפורמת ה- BI באמצעות גישה לממשק ה- API.
אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
אינך יכול לשפר את כישורי התכנות שלך כאשר לאף אחד לא אכפת מאיכות התוכנה.
שותפות, לא עסקה חד פעמית
ההחלטה להשתמש בספק חיצוני להטמעת ניתוח דומה יותר לשותפות מאשר לסוג הרכישה "השג ושכח מזה". היזם וספק ה- BI עובדים יחד כדי לבנות את מוצר הנתונים הנדרש, וממשיכים לשתף פעולה ככל שהמוצרים מתבגרים, מתווספים תכונות חדשות ומתעוררים צרכים חדשים.
האם המשמעות היא שהמפתח יצטרך לסמוך על ספק ה- BI לכל שינוי או התאמה אישית? ממש לא - על מפתחים להיות בעלי עצמאות מלאה ושליטה במוצר שלהם. עליהם להיות הבעלים הבלעדי של המוצר, מקצה לקצה, ולהיות מסוגלים לפתח אותו בעצמם, מבלי שייאלצו להסתמך על השירותים המקצועיים של הספק או על יועצים חיצוניים. על מנת להשיג תוצאה כזו, על המפתחים לשתף פעולה עם ספק BI שהוא מאפשר, תמיד לזכור מפתחים. שיטות העבודה המומלצות כוללות תחזוקה של SDK מקיף, עם תיעוד מצוין ועיצוב מוצר BI ככלי פלטפורמה פתוחה.
פלטפורמות פתוחות מאפשרות גישה נוחה באמצעות ממשקי API נפוצים, ומבטיחות שתוכנת BI גמישה מספיק כדי להשתלב במערכות הקיימות של המפתחים בצורה חלקה, ומתאימה לצרכים ודרישות ספציפיות סביב מקורות נתונים, אבטחה ושיקולים דומים. ולביצוע יישומים מורכבים ממשקל כבד - ספקי BI מובילים מספקים את המשאבים המקצועיים הדרושים בכדי להעלות את הלקוחות במהירות האפשרית ולהתמודד עם סוגיות התחזוקה השונות שעולות באופן בלתי נמנע.
יתרה מזאת, על שני הצדדים לראות במערכת היחסים ביניהם לטווח ארוך - תכונות חדשות שהוצגו בפלטפורמת ה- BI צריכות תמיד להיות מובנות בגישה "API-first", מה שמאפשר למפתחי אפליקציות לשלב במהירות ובקלות את התכונות הללו בהיצע שלהם; התקשורת בין ספק ה- BI למפתח היישומים צריכה להיות פתוחה ותכופה כך ששניהם יוכלו להבין טוב יותר את חוזקותיו ומגבלותיו של האחר ולהתאים את מאמצי הפיתוח, התמיכה וניהול החשבון בהתאם.
הבנת הניתוח המוטמע כשותפות מתמשכת, ולא כרכישה חד פעמית, תביא למפתחים לשאול שאלות רלוונטיות יותר לפני היציאה לפרויקט BI משובץ; ולהוביל את ספקי ה- BI להתחייבות רצינית לבניית פלטפורמות פתוחות באמת, לשמירה על שירות לקוחות ותיעוד מעולים. במקרים כאלה, כולם עומדים לרוויח.