אין ספק שהספר Business Intelligence Roadmap, שנכתב בשנת 2003 ע"י שתי נשים Larissa T. Moss ו- Shaku Atre, הנו ללא ספק אחד הספרים המקיפים ביותר שנכתבו בתחום הבינה העסקית. הספר עוסק בהקמת פרוייקטי בינה עסקית וסוקר לא פחות מ- 920 פעיליות שיש לבצע במהלך פעילות זו.
הספר, בעל אוריינטציה טכנולוגית, יותר מאשר עסקית, וניכר שנכתב ע"י אנשי מערכות מידע, אך בהחלט כאלו מנוסים שעסקו בעשרות פרוייקטים לפחות, אם לא למעלה מכך. בנוסף ל-16 פרקים המתארים כל אחד את שלבי הפעילות השונים, ישנם פרקים נוספים הסוקרים את הפעילות מנקודות מבט שונות: מיהם השותפים ובאילו שלבים הם לוקחים חלק; רשימת טיפים וכללי עשה ואל תעשה לכל שלב; נקודות כניסה ויציאה לכל שלב, המלמדים, מעבר לתוצאות המתקבלות מביצוע השלב, מתי לא כדאי לבצע את השלב (כאשר נקודת הכניסה לא מתקיימת, או לחילופין, כאשר נקודת היציאה כבר הושגה בארגון); תכנית עבודה מפורטת, ועוד.
ששה עשר השלבים מאורגנים בששה שלבי על להקמת סביבת הבינה העסקית. לא נראה לי שרבים ידבקו ברמת תשומה ורמת פירוט זו. ועם זאת, יש מה ללמוד מהבנת המודל המוצע:
מפת הספר
הצדקת הפעילות:
תכנון:
ניתוח עסקי:
עיצוב:
בנייה:
בחרתי לפרט בתמצית בעיקר מידע מתקדם וטיפים לאופן ביצוע השלבים השונים. את המידע הבסיסי (מהו השלב) והמעמיק (פרטים רבים על דרך ביצועו), יש לקרוא בספר עצמו. הסיכום, כפי שאפשר לשער, כולל רק מקצת מהתכנים (הספר המלא הנו 543 עמודים), וכל העוסק בבינה עסקית, חדש כמנוסה, ילמד ממנו. זאת, למרות החסר (לטעמי) בפרקים הכרחיים (הטמעה, ניהול השינוי, הקשר לתהליכי עבודה). סומנו בסימול מיוחד, דברים שנראו לי כקוראת ראויים ופחות טריוויאליים. השורה התחתונה- מדובר בספר מקיף ומומלץ ביותר.
מקווה שתהיה לכם קריאה מהנה.
חזרה
הצדקת הפעילות
הערכת המקרה העסקי Business Case Assesment
הקמת סביבת בינה עסקית אמיתית ומקיפה עולה מליוני דולרים. לא פחות.
אין להקים סביבה כזו, חלקה או במלואה ללא הצדקה עסקית, וללא יוזמה, רצון והבנה של הצורך העסקי מטעם אנשי העסקים בחברה. לעולם, ההצדקה לפעילות בינה עסקית חייבת להיות עסקית ולא טכנוולגית, ועל פי רוב מדובר בפעילות איטרטיבית ולא חד פעמית.
להלן מספר קטגוריות של יתרונות עסקיים מקובלים:
הגדלת הכנסות.
הגדלת רווח.
שיפור שביעות רצון לקוח.
הקטנת עלויות.
הגדלת נתח שוק.
לכל אחד מאלו מפורטים יתרונות עסקיים ממוקדים אותם אפשר להשיג באמצעות בינה עסקית.
אך אין תועלת ללא עלות, ובמקרה של פעילות בינה עסקית, כל פעילות מלווה גם בסיכונים, רבים יותר מאשר בפעילויות IT אחרות.
סוגי הסיכונים שיש להיערך אליהם:
סיכונים טכנולוגיים: בשלות טכנולוגיותבשוק ובארגון; כמות הטכנולוגיות השונות הנדרשות; אי תאימות של מערכות הפעלה; אי תאימות של מסדי נתונים.
סיכוני מורכבות: מורכבות סביבת ה- IT; מורכבות פתרון הבינה העסקית; תכיפות השינויים התהליכיים הצפויה; כמות האתרים הצפויה; רמת ביזור הנתונים, התהליכים והבקרה.
סיכוני אינטגרציה: כמה ממשקים צפויים ליישום; האם ישנם ממשקים חיצוניים; כמה כפילות נתונים צפויה; כמה מפתחות ראשיים יש לשלב ביישום; האם ישנם סטנדרטים סותרים; האם ישנם סטנדרטים בכלל; האם צפויות רשומות מיותמות רבות, הנוגדות כללי שלמות נתונים.
סיכונים ארגוניים: עד כמה הארגון סובלני לסיכונים; עד כמה הנהלת מערכות מידע סובלנית לסיכונים; לכמה תמיכה מורלית ותקציבית ניתן לצפות אם הפרוייקט יקלע לקשיים.
סיכוני צוות: כמה ניסיון יש לחברי הצוות במימוש פרוייקטי BI; עד כמה הניסיון מבוסס; עד כמה מאוזן הצוות; מה רמת הגיבוש ומורל הצוות; מה הסיכון שמי מחברי הצוות יעזוב; האם יש לחברי הצוות כל הכישורים והידע הנדרשים; עד כמה יהיה הנציג העסקי פעיל ויוזם; עד כמה חזק מנהל הפרוייקט.
סיכונים כספיים: עד כמה ניתן לצפות ROI; מה הסיכון שהעלויות תגברנה על התועלות; האם ניתן להתגבר על סיכונים צפויים בזכות השיפור הטכנולוגי.
הפעילויות העסקיות הכלולות בשלב זה: הגדרת הצורך העסקי; הבנת המצב הקיים; הגדרת מטרות; הצעת פתרון בינה עסקית; ניתוח עלות-תועלת; ניתוח סיכונים; כתיבת דו"ח מסכם. טיפ: אם הפרוייקט והיוזמה מובלים ע"י הגוף העסקי ונציגיו, יש סיכוי גבוה להצלחה.
חזרה
תכנון
ניתוח תשתיתי Enterprise Infrastructure Evaluation
פעילות בינה עסקית מתמקדת בהקמת תשתי ארגונית תומכת קבל החלטות. היעדר הסתכלות ארגונית חוצת יחידות, יוצרת "ספגטי" ובטווח הרחוק מקטינה את הסיכוי למנ את הארגון בזכות נתוניו. הבנה מקדימה של תשתית הארגון חשובה עוד לפני תחילת פיתוח הפתרון, כדי להבין לאיזו סביבה מורכבת מחד ומשתפת מידע מאידך אנו נכנסים, ומה סיכויי ההצלחה לפעילות חוצת ארגון בטווח הרחוק, כנובע מאלו.
הניתוח התשתיתי כולל שני חלקים:
הניתוח הטכנולוגי:
בוחן את-
החומרה (Hardware), ביזורה ורמת הבקרה של ביזור זה וחלוקת הנתונים בתוכו.
התווכה (Middleware) והעברת המידע והנתונים הקיימת כיום בין המערכות והיחידות השונות.
מסד הנתונים (DBMS) רמת השונות שבו (למספר סוגי מסדים שונים), והרמה הטכנולוגית של המסדים המובילים.
כולל את הפעילויות הבאות:
הערכת הפלטפורמה הקיימת; הערכה ובחירה של מוצרי שתית נוספים; דו"ח תשתיתי; רכישה והרחבה.
הניתוח הארגוני:
בוחן מצב נוכחי של-
פעילויות הארגון הפונקציונליות.
תהליכי עבודה.
ישויות ונתונים.
שימוש מערכות תפעוליות במידע. מידע חוצה ארגון.
מילון נתונים תשתיתי.
עבודה לפי סטנדרטים, וסטנדרטים אחידים.
כולל את הפעילויות הבאות:
הערכת התשתית הארגונית; דו"ח מצב; שיפור
יש כאן אמירה מאד חשובה: במידה ויש לארגון סבלנות וסובלנות, כדאי להתחיל בשיפור התשתיות המחשוביות והארגוניות ורק לאחר מכן להתחיל בפעילות הבינה העסקית הישירה. כמובן, שהתועלות ברורות, אך לא בכל ארגון ניתן להתחיל ברוח זו. במקרים כאלו, מומלץ לשלב בכל פעילות BI ישירה, פעילות אחת לפחות של קידום הארגון להוספת סטנדרטים / האחדה תשתיתית.
טיפ: אם יש מילון נתונים ארגוני, כדאי להיעזר בו לצורך הניתוח. במידה ולא, וישנו כלי CASE, זה יוכל לספק הרבה מהנתונים הנדרשים להערכה.
חזרה
תכנון הפרוייקט Project Planning
תכנון פרוייקט בינה עסקית שונה מתכנון פרוייקט רגיל. הסיבות:
נדרשות יכולות וניסיון שונה מאלו הכרוכים בניהול פרויקט מידע של מערכת תפעולית.
נדרשות יכולות hands-on רבות לניהול הפעילות.
נדרשים שינויים רבים יותר מהמקובל במהלך הפרוייקט. דחייה של לוחות זמנים הנה עניין תדיר ויש להתרגל אליו ולהיערך מראש בהתאם.
נדרשת איטרציה רבה וחזרה על שלבים דומים עם תכנים שונים כחלק מובנה מהפעילות.
מומלץ להגדיר (ולכתוב דו"ח) הכוללים התייחסות להיבטים הבאים:
מטרות ויעדים.
תיחום.
סיכונים.
אילוצים.
הנחות יסוד.
תהליכי ניהול שינוי.
תהליכי טיפול בסוגיות ניהוליות.
כדאי לשים לב שמדובר רק בחלק ממרכיבי הניהול הרגיל של כל פעילות, חלק שמקבל משקל יתר בפעילות בינה עסקית.
נקודות למחשבה:
שימו לב שהפרוייקט הנו עתיר נתונים ולאו דווקא עתיר פונקציונליות. היערכו בהתאם בתיחום.
סיכונים שכיחים: היעדר מחוייבות; בעל חסות שאובד; חוסר שיתוף פעולה מהצד העסקי; לו"ז לא ריאלי; תיחום לא ריאלי; ציפיות יתר; תקציב לא מתאים; צוות לא מיומן וחסר הדרכה וידע מספקים; שינויים תכופים בתעדוף העסקי; ניהול פרוייקט לא יעיל; יכולת שדרוג והרחבה מוגבלים.
אילוצים: ישנם חמישה אילוצים מקובלים בכל פעילות: איכות, תקציב, משאבים, זמן ותיחום. מומלץ להבטיח שזה יהיה גם סדר החשיבות בהתייחסות אליהם (איכות בהתחלה ותיחום אחרון, והשאר לפי סדר זה). תכנון הפרוייקט כולל: הגדרת דרישות; הגדרת מצב המסדים וקבצי המקור; בחינה מחודשת של הערכת עלויות וסיכונים; הגדרת גורמים קריטיים להצלחה; הכנת תוכנית פרוייקט; הכנת תוכנית עבודה-על; Kickoff.
טיפים:
שינויים במהלך הפרוייקט יהיו, בין אם נרצה ובין אם לא. יש לבחור מנהל פרוייקט שישכיל להתמודד עם השינויים. יש להיזהר, כי אי ניהול נבון של השינויים יכול להרוג את הפרוייקט כולו.
הרבה מהפעילויות יכולות להתבצע במקביל. מומלץ לנצל זאת, כי זמן תמיד יהיה בחסר.
חזרה
ניתוח עסקי:
הגדרת דרישות Project Requirements Definition
פעילות הגדרת הדרישות מקבלת גוון שונה כאשר מדובר על כלל פעילות
הבינה העסקית בארגון והנעתה, לעומת העיסוק בפעילות בינה עסקית ממוקדת לקהל יעד ומטרה מוגדרים.
במקרה הראשון, של הנעת פעילות כוללת, מומלץ להכין דו"ח הכולל:
דרישות לפי נושא (בהמשך יתפתחו כנראה כל אחד לפרוייקט);
רשימה של סוגיות עסקיות קריטיות, שעלו במהלך הריאיונות, ולהציע לתת להם מענה מיידי, בין אם בפעילות בינה עסקית, ובין אם בפעילויות אחרות (פעמים רבות עולים צרכים אחרים תוך כדי);
הזדמנויות שניתן לזהות וכדאי למנף בפעילות הבינה העסקית;
המלצות.
צעדים הבאים לפעולה (תוך ציון מה קריטי יותר).
במקרה השני, של פעילות בינה עסקית ממוקדת, מומלץ להכין דו"ח הכולל:
מטרות במונחים של:
אופי הבעיה העסקית.
הנזק הנגרם מהיעדר סביבת BI תומכת (עלות אי ניהול המידע).
למה הבעיה לא יכולה להיפתר ללא בינה עסקית.
איך הבינה העסקית מסייעת לפתרון הבעיה.
דרישות מפורטות של:
נתונים; מקורות מידע.
כלים נדרשים.
דו"חות וגרפים; פונקציונאליות.
טיוב (תוך תעדוף מה קריטי יותר).
מידע היסטורי.
אבטחת מידע.
אמנת שירות מוצעת (זמני תגובה, זמינות, רמת טיוב ועוד) SLA.
הפעילויות העסקיות הכלולות בשלב זה: הגדרת דרישות תשתית טכניות; הגדרת דרישות תשתית לא טכניות (סטנדרטים ועוד); הגדרת תכולת מסמך דרישות; הגדרת דרישות ממקורות המידע; סקירת תיחום הפעילות; הרחבת מודל הנתונים הלוגי; הגדרת SLA ; כתיבת דו"ח דרישות מפורט.
טיפים לראיונות על בסיסם נבנים הדו"חות לעיל:
בראיונות ראשונים מומלץ להימנע מירידה לפרטים. יש להתרכז בפן העסקי.
אנשים יטו לספר על מה שיש להם יותר ממה שהם באמת צריכים.
תהיינה דעות סותרות.
הימנעו מלכתוב יותר מידי בזמן הראיון. פוגם בזרימת השיחה.
כדאי להעביר לאנשים את סיכומי הראיונות ולוודא שאכן הצרכים הובנו כפי שחשבנו.
טיפים נוספים: ודאו שהתיחום ישים; הפרידו בין הגדרת הדרישות לעיצוב ע"י אנשי התוכנה; הימנעו מעודף נתונים, רק כי "יש לנו אותם".
חזרה
ניתוח נתונים Data Analysis
מחברי הספר מגדירים שלב זה של ניתוח הנתונים כשלב הקריטי ביותר בפעילות כולה.
את ניתוח הנתונים מומלץ לעשות תוך שילוב שתי השיטות המוכרות לניתוח גם יחד:
וTop Down- ניתוח מלמעלה שהוא אכן הטוב ביותר להבנת התמונה הכוללת של הארגון.
וBottom Up- ניתוח מעיני כל פרוייקט בנפרד, תוך שילוב הנתונים במערך הנתונים הקיים.
יש לתת דגש לכך שניתוח הנותנים יהיה עצמאי ולא תלוי: מסד, חומרה, שיטת גישה, עיצוב, כלים, תוכניות.
המחברים מביעים משאלת לב, שיכולה לחסוך לנו הרבה משאבים בהקמת מערכי בינה עסקית: הגדרת סטנדרט מחייב, לפיו כל פיתוח מערכת תפעולית מחייב פיתוח מודל נתונים לוגי במקביל. הלה ישולב במודל הנתונים של הסביבה העסקית ויחסוך הרבה כסף, זמן וחשיבה לא מיטבית אל מול המצב כיום.
מודל נתונים טוב כולל לכל נתון:
שם, תיאור, קישור לפעילויות עסקיות, מפתח; סוג, אורך, תוכן; חוקים עסקיים, מדיניות Governance; בעלות.
כאשר אנו מדברים על מודל שלם, אנו מגדירים:
חוקי הסבה טכניים בין המערכות. מתקיימים תמיד.
חוקים עסקיים הקשורים בתוכן הנתון. פירוט להלן.
חוקי שלמות נתונים. פירוט להלן.
הפרות של חוקים עסקיים:
ערכי נתונים חסרים.
שימוש בערכי ברירת מחדל (0,999, FF וכו').
ערכי dummy בעלי משמעות עסקית ייחודית (שימוש בת.ז. 888 כדי לציין תושב זר וכו').
לוגיקה הכלולה בתוך ערכי הנתון: מיקודים נמוכים מעידים על אזור היישוב בארץ.
שימוש מרובה בשדה אחד: ערכים בטווח מסוים מדברים על סוג הלקוח, בטווח אחר על מיקומו וכו'.
שימוש מרובה על ציר הזמן באותו נתון למטרות שונות (redefine בשפת COBOL).
נתונים המתפרשים על יותר משדה אחד (כתובת ב- 5 שורות המהוות 5 שדות).
הפרות של חוקי שלמות נתונים:
סתירות בין נתונים הקשורים לישות משותפת. למשל: לונדון, צרפת.
הפרות של חוקים עסקיים מוגדרים לאותה ישות. למשל: אדם שתאריך לידתו אחר תאריך פטירתו.
ערכים שונים בעלי מפתח אחיד (שני אנשים עם אותה ת.ז.).
חסר במפתח ייחודי (לקוח אחד עם מספר קודי לקוח שונים).
ישויות ללא ישות אב. למשל- עובד עם קוד מנהל שאינו קיים.
טיוב נתונים:
אחת המטרות של סביבת בינה עסקית הנה לספק מידע אינטגרטיבי, המיישב סתירות בין מקורות שונים. זה אינו יכול להתרחש במידה והנתונים אינם מטייבים. כאשר בוחרים את הנתונים לסביבה העסקית יש לקחת זאת בחשבון. שלבי הבחירה:
זיהוי הנתונים הנדרשים; ניתוח תוכן הנתונים; בחירת הנתונים המתאימים (רק הליבתי ביותר העונה לצרכים); וידוא רמת ניקיון אפשרית סבירה; הכנת מפרט טיוב; בחירת כלים תומכים.
נקודות מפתח בעת בחירת הנתונים והבנת רמת ניקיונם:
רמת שלמות הנתונים. ככל שנתונים מוזנים יותר באופן ידני, כך שלמותם גדלה.
רמת דיוק הנתונים (במיוחד נתונים מספריים לא שלמים).
רמת נכונות הנתונים (האם ידועים בה הבדיקות על הזנת הנתונים ושמירת נכונותם).
רמת אמינות הנתונים. ככל שהנתונים ישנים יותר, יש סיכוי שכבר אינם אמינים; האם מדובר בנתוני מקור או העתק של נתונים. ועוד.
מבנה הנתונים הבסיסי. יהיה קל יותר להסב ולהבטיח רמת ניקיון על מקור טבלאי מאשר היררכי וכו'.
הפעילויות העסקיות הכלולות בשלב זה: ניתוח מקורות מידע חיצוניים; שיפור מודל הנתונים הלוגי והרחבתו; ניתוח רמת ניקיון הנתונים; פתרון סתירות; הגדרת מפרטי טיוב.
טיפים:
טריוויאלי, אך לא תמיד מבוצע: שילוב DBA בביצוע שלב זה.
בתוך תיחום הפרוייקט- שימוש בטכניקת Top-Down להגדרת החוקים העסקיים וב- Bottom-Up לאיתור הפרות.
למנהלים שטרם ניהלו שלב כזה בעבר: הכפילו כל הערכת זמנים פי 4 !!!!
חזרה
אבטיפוס ליישום Application Prototyping
שלב האבטיפוס הנו שלב אפקטיבי להבנת חסרים ופתרון סתירות חבויות.
לקחים שנלמדו מהקמת אבי-טיפוס:
הגבילו את התיחום.
הבינו את דרישות מסדי הנתונים עד כמה מוקדם שאפשר. ישפיע על עיצוב המסד.
בחרו את הנתונים הנכונים לשילוב באבטיפוס. בחרו דגם קטן דיו.
בחנו בשלב זה את ידידותיות ונוחות כלי הגישה וכלי ניתוח הנתונים.
שלבו את בעלי התפקידים העסקיים בתהליך.
נקודות מומלצות בעת קביעת אבטיפוס:
צוות אבטיפוס קטן.
ניהול הדוק של deadline.
תיחום. עשו שימוש במונח- slimware.
תוצרים מוגדרים היטב.
תכולה: כללו בדיקה של GUI, ממשקים ושיטות הבאת תוצרים נוספות.
המעיטו בהגדרות שלמות נתונים לאבטיפוס.
שתפו עד 5 (ובמקרים חריגים עד 8) בעלי תפקידים עסקיים באבטיפוס. לא יותר.
עודדו את בעלי התפקידים העסקיים להגדיר מדדי הצלחה.
סוגי אבי-טופס מוכרים קיימים:
וShow & Tell (מוכוון הנהלה); Mock-up (להבנת דרכי גישה וניתוח נתונים); Proof-of-Concept (לבירור נקודות מימוש לא סגורות); Visual-Design (כמו Mock-up, אך מעמיק יותר ); Demo (מראה ופונקציונאליות חלקית); Operational (בוחן סוגיות תפעול. רחב).
את האבטיפוס מומלץ ללוות במסמך מגדיר הכולל הגדרת סוג, מטרות, בעלי תפקיד עסקיים מעורבים, חומרה ותכנה, הגדרת דרישות להבטחת סטנדרטים, ידע ומיומנויות של הצוות ושימושיות.
הפעילויות העסקיות הכלולות בשלב זה: ניתוח דרישות גישה; הגדרת תיחום; בחירת כלים לאבטיפוס; הכנת מסמך מגדיר; הגדרת דו"חות ושאילתות; בניית האבטיפוס; הצגת האבטיפוס.
טיפים:
הדגימו את האבטיפוס כמה וכמה פעמים בתהליך לשותפים ובעלי הדעה.
בעלי התפקידים העסקיים יהיו אלו שיבחנו את הידידותיות והנוחות.
מנהלים רבים חושבים שהם רוצים רק תוצאות סיכומיות. בדרך כלל מתברר אחרת. בחנו נקודה זו באבטיפוס.
חזרה
ניתוח מילון נתונים תשתיתי Meta Data Repository Analysis
ניתוח מילון נתונים תשתיתי Meta Data Repository Analysisמילון נתונים תשתיתי הוא גם מסד, אלא שמטרתו להכיל מידע על הנתונים הקיימים.
המידע משמש גם להבנה (כוללת של המערך ופרטנית של מצב נתון); גם ככלי לניהול וגם ככלי לניווט בתכנים. קיומו של מילון נתונים עוזר לקידום הסטנדרטיזציה.
המידע המומלץ הכלול מסווג לארבע קבוצות:
בעלות (על נתונים ועל יישומים).
מאפיינים תיאוריים (לתהליכים עסקיים; לנתונים עסקיים): שם, תיאור, הגדרה, ערכים מותרים, הערות.
חוקים ומדיניות עסקיים: קשרים, מדיניות עסקית, אבטחת מידע, טיוב, תוקף, עדכניות.
מאפיינים פיזיים (לנתונים ויישומים): מקור, מיקום פיזי, הסבות, חישובים למיניהם, היקף, צמיחה.
קיימים אתגרים רבים הקשורים למילון הנתונים:
אתגרים טכניים. מדובר בפרוייקט בפני עצמו. יש להחליט האם לרכוש או לבנות לבד.
אתגרי ציוות. מחויב מנהלן שיתחזק את המילון התשתיתי, אחרת זה יצא מסנכרון.
אתגרים תקציביים. הארגונים אינם רוצים להשקיע (או להשקיע מספיק) בהקמה ובתחזוקת המילון.
אתגרי שימושיות. רוב מילוני הנתונים התשתיתיים לא נוחים דיים לשימוש והנגשה.
אתגרים פוליטיים. ישנה שונות רבה בין המחלקות ואופן טיפולן בבינה העסקית. פה מחויבת אחידות.
הפעילויות העסקיות הכלולות בשלב זה: ניתוח דרישות המילון התשתיתי; ניתוח דרישות הממשקים; ניתוח דרישות הגישה והדיווח מהמילון; בנו מודל נתונים לוגי (תרשים ERD); הגדירו את סוג הנתונים שינוהלו. טיפ: קשה להקים מילון תשתיתי בבת אחת. תעדפו את סוג המידע שיישמר: חובה, חשוב, אפשרי.
חזרה
עיצוב
עיצוב מסד Database Design
מסדי נתונים התומכים בפעילות בינה עסקית שונים מאלו התומכים במערכות תפעוליות.
עיקרי ההבדלים:
מוכוונים כלפי משתמשים שונים, בעלי צרכים שונים. מותר לאפשר כפילויות.
זמני התגובה נמדדים על פי רוב בשניות, דקות ושעות (ולא תת שניות).
לא מנורמלים!
מכילים מידע רב מחושב, ולא רק נתונים גולמיים.
מכילים מידע היסטורי ולא רק תמונת מצב עכשווית.
כוללים רמות רבות של מידע סיכומי.
סוגי העיצוב העיקריים של מסדי נתונים כוללים:
וStar Schema לאחסון טבלאי של נתונים קובייתיים.
וSnowflake Schema כנ"ל, אך תוך יצירת היררכיה למאפייני הגישה (למשל ארץ> עיר> שכונה).
עיצוב פיזי חשוב להבטחת זמני תגובה סבירים. אפשרויות לזירוז זמני תגובה:
אחסון נתונים תדירים בגישה על התקנים מהירים.
אחסון רמות שונות של סיכום על פלטפורמות שונות.
וStripping של הדיסקים (לדיסקים פיזית קטנים) להשגת אופטימיזציה של פעילות הקלט-פלט.
מיקום ה datasets כך שחיפושים ארוכים נמנעים ככל האפשר.
בחירת כתובת וסכמות אחזור במקצרות את כמות ה- seeks. המטרה- seek אחד לכל אחזור.
הרצת פעילויות רבות ככל הניתן במקביל.
הפרדת אינדקסים מנתונים. הפרדת האינדקסים עצמם בין הדיסקים השונים.
עיצוב פיזי כולל התייחסות לפרמטרים הבאים:
וPartitioning, Clustering, Indexing, Reorganizations, Backup & Recovery.
הפעילויות העסקיות הכלולות בשלב זה: סקירת דרישות הנתונים; החלטה על רמות הסיכום הנדרשות; עיצוב המסד הלוגי; עיצוב מבנה המסד הפיזי; בניית המסדים; פיתוח תהליכי תחזוקה; היערכות לניטור ושיפור העיצוב; היערכות לניטור ושיפור עיצוב השאילתות.
טיפים:
תנו לאנשי ה DBA לעצב את מסד הנתונים. אל תחליטו לבד ותשאירו להם רק את הבניה.
הטמיעו את ההבנה שמסדי הבינה העסקית ענקיים (VLDB). אלו שלא- יהיו כאלו. תכננו בהתאם.
וClustering משפר ביצועים באופן ניכר ביותר. נצלו אותו.
אל תבנו אינדקסים כאשר ישנם ערכים שמתייחסים ליותר מ- 15% מהנתונים (מין).
ארגנו מחדש את המסד לאחר 5% תוספות /ביטולים.
חזרה
עיצוב ETL ETL Design
וETL ובשמו המלא, Extract-Transform-Load (שליפה-הסבה-טעינה),
עוסק בהבאה נכונה של הנתונים ממגוון המערכות התפעוליות. מרכזו של השלב בחלקו האמצעי, ההסבה, האחראית גם על הטיוב.
החוק החשוב ביותר ביישום ETL הנו קיומו של מהלך אחד שיתופי כזה (ולא פעילויות מבוזרות).
ההיערכות לתהליך ETL כוללת:
וReformatting- פרמוט מחדש, היות ומקורות המידע מסוגים מגוונים.
וReconciling- יישוב סתירות בין מגוון המקורות המשולבים יחד.
וCleansing- היערכות לטיוב: הגדרת הצרכים.
וETL כולל שלוש סוגי תוכניות: טעינה ראשונית, טעינת מידע היסטורי, טעינת פערים. העיצוב צריך להתייחס לכל הסוגים הללו.
השליפה: מנקודת מבטן של המערכות התפעוליות, הכי פשוט להכפיל את הנתונים ושמערך הבינה העסקית ידאג לשאר. מנקודת מבט של בינה עסקית הדרך המועדפת הנה מיון, סינון, טיוב וסיכום ישר במקור כפעולה אחת שתוצאתה השליפה. בחיים בדרך כלל מתפשרים: השליפה הנה הכפלה, אך כזו המאפשרת הגעה למידע הרצוי יחסית בדרך המהירה ביותר.
ההסבה: החלק המורכב ביותר. יש להתייחס לבעיות בנתוני המקור- נתוני מפתוח לא עקביים, ערכים לא עקביים, פונטים שונים של נתונים, ערכי נתונים לא מדויקים, שמות נרדפים וריבוי שמות למונח יחיד, לוגיקה חבויה בקוד.
הטעינה: טעינה של הנתונים הנקיים. מומלץ לבטל קשרי RI ואינדקסים לפני הטעינה, ולשחזרם אחרי. הפעילויות העסקיות הכלולות בשלב זה: כתיבת דו"ח מיפוי מקור-מטרה; בחינת יכולות כלי ה ETL; עיצוב תהליך ה ETL; עיצוב תוכניות ה ETL; הכנת אזור עבודה ל ETL.
טיפים:
וETL הנו התהליך המורכב ביותר בכל פעילות הקמת סביבת בינה עסקית ובעיקרו ההסבה. היו בטוחים להקצות מספיק זמן לשלב זה.
האתגר הגדול ביותר בעיצוב ETL טוב הנו איתור אנשים המבינים את משמעות הנתונים, החוקים העסקיים וההיסטוריה. שווה לשלב במחקר זה גם בעלי תפקידים עסקיים אך גם תוכניתנים רלוונטיים מהסביבות התפעוליות.
חזרה
עיצוב מילון תשתיתי Meta Data Repository Design
עיצוב מילון נתונים אינה סוגיה חדשה והיא מקובלת מתחילת שנות ה- 80. עם זאת,
תמיד היא היתה מאופיינת בבעיות רבות החל מהזנה ידנית, דרך טכנולוגיות לא בשלות ועד כשל ביצירת מילון משותף, חוצה יחידות בעל הבנה והערכה ארגונית.
לא נאמר שהמצב התהפך, אך יש בהחלט שיפור, לפחות בחלק מהממדים, והיכולת לשקול מילון נתונים תשתיתי בהחלט אפשרית וישימה.
סוגיות מרכזית בעיצוב מילון נתונים:
מילון ריכוזי / מבוזר (מודל משותף, המידע מבוזר) / מבוסס XML (מודלים שונים במילונים שונים, כאשר התיוג המשותף XML). שיקולים להחלטה- נוחות ממשק, שליטה על התכנים, אמינות ועדכון אוטומטי, בעלות, כפילות נתונים.
רכישה / פיתוח עצמי: שיקולים להחלטה- התאמה לצרכים, חסכון במשאבי פיתוח.
מבנה ERD (Entity Relational Diagram) / OO (Object Oriented) : שיקולים להחלטה- קלות קריאה והבנה, גמישות מבנית, פשטות שליפה, פשטות מימוש.
הפעילויות העסקיות הכלולות בשלב זה: עיצוב המסד של מילון הנתונים התשתיתי; התקנת מוצר מלווה (או פיתוח); עיצוב תהליך העברת הנתונים למילון; עיצוב תוכניות יישומיות נדרשות.
טיפים:
החלו במילון נתונים מרכזי כי הוא יותר קל להקמה ותחזוקה.
רוב הגישות למילון נתונים אמורות להיות ע"י בעלי תפקידים עסקיים ולא ע"י אנשים טכניים. תכננו בהתאם.
חזרה
בנייה:
פיתוח ETL ETL Development
הרבה מהשלבים הקודמים כללו איסוף של חוקים עסקיים. אלו באים לידי ביטוי
בשלב זה של בניית ההסבה בפועל.
ההסבה כוללת את הרכיבים הבאים:
טיוב.
סיכומים (בעיקר סכומים או כמויות).
נתונים מחושבים.
אגרגציה של נתונים ממקורות שונים.
שילוב של נתונים והחלטה על מפתחו ושמות יחידים.
אחת מהטענות הנשמעות ע"י בעלי תפקידים עסקיים כנגד סביבות בינה עסקית היא של חוסר אמינות בנתונים. באופן אירוני, בדרך כלל, כאשר יש פערים, הנתונים בסביבות הבינה העסקית מדויקים יותר ולא להיפך. עם זאת, הלה מחייב הוכחה, ושמירתו של מידע אודות ההסבה ואודות זמן ההעברה קריטיים לטובת מטרה זו. כמו כן, מומלץ לוודא העברה תקינה של הנתונים (וגם מידע על כך לשמור במקום נגיש לבעלי התפקידים), על מנת למנוע בעיות אמינות אמיתיות.
הפעילויות העסקיות הכלולות בשלב זה: בנייה ובדיקה יחידנית (Unit test) של תהליך ה ETL; בדיקות אינטגרציה או רגרסיה של התהליך; בדיקות ביצועים של התהליך (!!!); בדיקות איכות; בדיקות קבלה.
טיפים:
ארגונים משקיעים כ- 80% מזמן הפעילות בנושא בינה עסקית במאמצים "אחוריים", לרבות טיוב. כלים יכולים לסייע בהערכת הניקיון וייעולו.
80% מההשקעה בטיוב הנה בחוקים עסקיים ורק 20% בהסבות טכניות. בחרו איפה להשקיע מאמצים בחלק הראשון כדי לייצר בתוכו 20-80 (20% מאמץ שיביא 80% מהצורך).
הסימפטומים המקובלים ביותר לנתונים לא נקיים הנם סתירות בנתונים ושימוש חוזר באותו שדה למטרות שונות. המרכיב השני נפוץ במיוחד בשליפות מקבצים שטוחים.
חזרה
פיתוח יישום Application Development
פיתוח היישום כולל העמדת סביבה בה יש תבניות מוכנות וקלות לגישה.
הנ"ל כולל גם חישובים וסיכומים, אך לא פחות קוביות מוכנות בהן קל לנווט להגעה למידע הרצוי.
מומלץ לעשות שימוש בכלי OLAP מוכנים עבור סביבה זו.
הפונקציונאליות הנלווית לכלי OLAP:
מייצגים את המידע והגישה אליו באופן רב ממדי.
נותנים סיכום ואגרגציה.
נותנים יכולות שאילתא וניתוח אינטראקטיביים.
תומכים מנתחים עסקיים הבונים שאילתות משתנות.
תומכים בפעולות drill-down, roll-up, drill-across.
כוללים מודלים אנליטיים.
כוללים מודלים לניתוח מגמות.
מציגים מידע בדו"חות ובגרפים.
תשתית OLAP כוללת שלושה מרכיבים: שירותי תצוגה; שירותי OLAP; ושירותי מסד נתונים.
ארגונים רבים עוסקים במערך בינה עסקית בלקוחות. שמונת הממדים הקשורים ללקוחות ולמידע עליהם, הנם:
סוג לקוח.
התנהגות רכישות.
דירוג אשרי.
תחום.
דמוגרפיה.
פסיכוגרפיה (פילוח שוק על-פי מאפייני אישיות של קהלי יעד).
היסטורית רכישות.
קטגורית מוצרים.
הפעילויות העסקיות הכלולות בשלב זה: החלטה סופית על הדרישות; עיצוב תוכניות יישומיות; בניה ובדיקה יחידנית של התוכניות; בדיקה כוללת של התוכניות; הדרכות לגישה למידע.
טיפים:
התאימו את התצוגה לאוריינות והרגלי בעלי התפקידים. אל תתנו פתרון מתוחכם מידי, למי שלא מתאים.
קל להבין 2-3 ממדים; 5-6 ממדים קשים לתפיסה; 7 ממדים הם המקסימום.
כדי לאפשר ביצועים סבירים הכינו מידע סיכומי לשאילתות שכיחות. יותר אפקטיבי מאשר להסביר למה זמני התגובה מתארכים.
חזרה
כריית נתונים Data Mining
כריית נתונים רינה תוכנת מדף מן המוכן. היא מחייבת, בצד כלי תוכנה, יישום תומך. כריית נתונים אינה ניתוח סטטיסטי ונבחנת ממנו בכמה היבטים:
אינה מחייבת הנחת יסוד מקדימה (שאותה בוחנים).
האלגוריתמים מפתחים בעצמם את המשוואות הנבדקות.
יודע לפעול גם על נתונים שאינם מספריים.
חייב, כדי לפעול נכון, נתונים מטויבים נקיים.
החשיבות בהעמדת פתרון של כריית נתונים, ביכולתו לענות על שאלות שמקבלי ההחלטות לא יודעים לשאול. לכן מקובל לכנותו גם Knowledge Discovery וזהו מרכיב משלים ליכולות הקודמות שהוזכרו ולא תחליף להן.
פעמים רבות, למרות קיומו של מחסן נתונים המהווה סביבה למערך הבינה העסקית, יש לשקול עבודה מול מערך המידע התפעולי, אם המערך העסקי כולל סיכומים ולא נתונים גולמיים (ולכן מקשה על פעילותו). מאידך, אם נתוני המערכות התפעוליות אינם נקיים, אולי יש להעדיף את סביבת הבינה העסקית.
טכניקות כריית נתונים: 1. Associations Discovery- זיהוי התנהגות של מאורעות/תהליכים בדידים (רכישה בסופרמרקט). 2. Sequential Pattern Discovery- זיהוי התנהגות לאורך זמן של מאורע / תהליך (רכישות בסופרמרקט). 3. Classification- זיהוי מאפיינים של קבוצות שהוגדרו מראש (מאפייני נוסעים מתמידים). 4. Clustering- ארגון פריטים בקבוצות; זיהוי הקבוצה אליה משויך כל פריט. 5. Forecasting- ניתוח רגרסיה בכלל וניתוח רגרסיה תלוי זמן בפרט.
יישומים עיקריים בהם משתמשים בכריית נתונים: ניהול שווקים, חיזוי הונאות, ניהול סיכונים, שירותים פיננסיים, הפצה (בקרת מלאי).
הפעילויות העסקיות הכלולות בשלב זה: הגדרת הבעיה העסקית; איסוף נתונים; מיזוג וטיוב הנתונים; הכנת הנתונים; בניית המודל האנליטי; ניתוח תוצאות; ביצוע בדיקות חיצוניות לתיקוף; ניטור המודל לאורך זמן.
טיפים:
השוו את התוצאות שקיבלתם ל Benchmarks או מידע חיצוני אחר.
כל פעילות כריית נתונים שאין מה לעשות עם תוצאותיה, אינה תומכת עלות-תועלת. חשבו מראש.
חזרה
פיתוח מילון תשתיתי Meta Data Repository Development
מילון נתונים תשתיתי משרת אנשים טכניים, אך הרבה יותר מכך בעלי תפקידים. במידה ולא רוכשים אחד כזה, יש לבנותו לבד. מעבר לכך, יש לתכנן את איסוף המידע לתוכו ממקורות מגוונים:
מסמכים- נהלים, מדריכים ומסמכים נוספים המתארים חוקיים עסקיים.
גיליונות נתונים (Excel)- למידע על חישובים, macros ועוד.
כלי CASE- הכוללים הגדרות של הנתונים הנשמרים במסדים.
מילוני DBMS- כנ"ל.
כלי ETL- הכוללים מידע על ההעברות.
כלי OLAP- הכוללים מידע על חישובים וסיכומים.
כלי כריית נתונים- הכוללים מידע תיאורי על המודלים האנליטיים בשימוש.
יש להבטיח בעת רכישת או פיתוח מילון נתונים תשתיתי שיכלול ממשק נוח לגישה וניווט לכל בעלי התפקידים השונים, החל ממנהלים, דרך מקבלי החלטות נוספים, מומחים המבצעים ניתוחים ועד אנשים טכניים.
הפעילויות העסקיות הכלולות בשלב זה: בניית מסד הנתונים למילון; בניית ובדיקת תהליך העברת המידע למילון; בניית ובדיקת יישום המילון; בדיקת התוכניות הכוללות או המוצר המוכן (עם נתונים); הכנת המילון לייצור; הדרכה.
טיפים:
בניית מילון נתונים תשתיתי אינה מאורע חד פעמי כי אם מאורע מתפתח.
בפיתוח מילון לבד, היערכו לבניית שני סודי ממשקים: לתוכניות הטוענות את המילון, ולבעלי התפקידים המשתמשים בו.
גודל מילון נתונים יכול להיות עד 5% מגודל מסד הנתונים, אם נבנה נכון. בדקו עצמכם.
על כל יום של בנייה, הקצו 3 ימים לבדיקות.
חזרה
פריסה:
מימוש Implementation
לאחר תכנון, בניית ובדיקת מערך הבינה העסקית, מגיע השלב המיוחל של העמדתו למשתמשים בסביבת הייצור. מומלץ לבצע השקה מדורגת ולחשוף את הסביבה למעגלים מתרחבים של משתמשים, כל פעם לאחר בחינה, אישור ותיקון מתאים של הסביבה.
ניהול הרשאות ואבטחת מידע: ניהול הרשאות ושמירת אבטחת המידע הנם משימה ידנית שלא ניתן להימנע מדיון בה בסביבת הבינה העסקית; אין מטריה מוכנה המשמרת את הגדרות המערכת התפעולית ומשחזרת אותן בסביבה החדשה. גיבויים: יש להיערך לגיבוי קבוע של מערך הבינה העסקית. זה יכול להתבצע באחת משלוש שיטות:
גיבוי פערים.
גיבוי מהיר של נתוני המערכות התפעוליות מהן נשלף המידע.
גיבוי חלקי כל פעם של אזור נתונים אחר (והשאר נותרים זמינים בעת שאינם מגובים).
ניטור: יש לנטר באופן מתמיד את מערך המחשבים, הרשתות וזמני התגובה של השאילתות המורצות.
גידול: ככלל אצבע ניתן לומר שערך בינה עסקית מכפיל את עצמו מידי שנתיים. יש להיערך הן לגידול בנתונים, הן לגידול בשימוש, והן לגידול בחומרה.
הפעילויות העסקיות הכלולות בשלב זה: תכנון המימוש; הקמת סביבת ייצור; התקנת כלל מרכיבי היישום; העלאת תוכניות ETL למסלול תוכניות המורצות באופן קבוע; טעינת נתוני הייצור; היערכות לתמיכה.
טיפים:
מינוני נתונים: 30% נתונים עסקיים; 30% אינדקסים; 30% סיכומים; 10%- אחר.
חזרה
הערכת גרסא Release Evaluation
תפיסת הגרסאות גורסת חלוקת כל פרויקט בינה עסקית למידע שמביאים עכשיו ולמידע שיובא בעתיד. תפיסה זו מאפשרת העלאת פתרונות, שכן אחרת, יותר מידי פעמים נדחה את ההעלאה, ויותר מידי פעמים נשקיע 20:80 שדברים שאולי לא תמיד נדרשים, ובטח לא נדרשים עכשיו.
עקרונות להגדרת גרסא:
מומלץ לנפק גרסא חדשה כל 3-6 חודשים (חוץ מהראשונה שמשכה אורך יותר).
תוצרי גרסא צריכים להיות קטנים וברי ניהול.
יש לנהל ציפיות ביחס למה מקבלים בגרסא נוכחית ומה לא.
גרסא לא חייבת לכלול יישום שלם.
הגרסא הראשונה – עדיף שתתן רק יסודות.
על ההנהלה להיות מוכנה לקבל מידע בגרסאות.
הכל בר משא ומתן. אין כלום שהנו בגדר "חובה".
על התשתית התומכת להיות יציבה.
הנו חלק מכל גרסא, אחרת לא ניתן לנהלן. Meta data
תהליך הפיתוח צריך להיות בעל נראות.
על הכלים לתמוך בגמישות הנדרשת מעבודה בגרסאות (פיתוח מדורג).
יש לתעדף צרכים חדשים ולא למלאם דווקא לפי סדר הגעתם.
שגיאות קטנות יש לתקן גם בין הגרסאות ללא עיכוב עד הגרסא הבאה; שגיאות גדולות תחכינה, ואם יש צורך, יש להסיר את המידע / פונקציונאליות שגויה עד אז.
בסיום כל גרסא יש לתחקרה ולהפיק את הלקחים. מומלץ להעלות שאלות הקשורות ב: לו"ז; תקציב; שביעות רצון; תיחום; יכולות מו"מ; צוות; מיומנויות והדרכה. מומלץ לבצע את תהליך הפקת הלקחים חודשיים אחרי עלייה לאוויר.
הפעילויות העסקיות הכלולות בשלב זה (של ההערכה): הכנת המידע לסקר; היערכות לתכני המפגש; ביצוע המפגש; מימוש הלקחים.
טיפים:
היערכו לכל פעילות בינה עסקית תוך הנחה שתהיינה מספר גרסאות ולא הכל יעלה בבת אחת.
אל תוותרו על סקרי האירוע והפקת הלקחים אחרי כל העלאת פעילות.
רוצה ללמוד עוד על סיכוני ידע?
הנה מספר כתבות שאולי יעניינו אותך:
Comments