25. 25
יעקבי חגיISUG-2010
- מסווג בלתי -
?עובד זה איך אז – טכנולוגיה
External
Systems
Web Service
Push
(XI Etc)
RDA with Generic Extraction
ECC (SAP Source System)
RDA Daemon
Pull
~ 5/min
DataSource YFI_GL_FAGLFLEX2
PSA
Service API
Delta Queue
DataStore Object
0FIGL_O14
Operational Data Store
DTP for Real-Time Data Acquisition (Step 2)
Infopackage for Real-Time Data Acquisition (Step 1)
SAP Net Weaver Business Intelligence
InfoCube
0FIGL_CXX
InfoCube
Real-Time
Update
Generic Extraction using the real-time DataSource
Delta Queue populated at the time of extraction
בחצי השעה הקרובה תקבלו כלים שיעזרו לכם להתמודד עם דילמה אותה חווים בכל ארגון המקים מערכת בינה עסקית.
חגי יעקבי, מנהל פרויקטי BI ביבמ.
כמה מיישמי BW יש בקהל?
כמה לקוחות של BI יש בקהל?
כבר מהמפגש הראשון שלי עם BI לפני כעשור, לא הפסקתי לשמוע את הדרישה לקבל את הדוחות באון ליין "הדוח הזה לא שווה לי כלום אם לא אקבל נתוני זמן אמת"
מאז ועד היום הדרישה לזמינות נתונים בסמיכות ליצירתם במערכות המקור, רק הולכת וגדלה.
במצגת זו אני מעוניין להציף את הדילמה המשמעויות והפתרונות האפשריים ב BW.
אעשה זאת דרך סיפור הלקוח של פרויקט "מאור" במזי.
אציג את זרוע היבשה, את הפתרון על הדילמות והשיקולים, וגם אגע טיפה בפאן הטכני
כבר מהמפגש הראשון שלי עם BI לפני כעשור, לא הפסקתי לשמוע את הדרישה לקבל את הדוחות באון ליין "הדוח הזה לא שווה לי כלום אם לא אקבל נתוני זמן אמת"
מאז ועד היום הדרישה לזמינות נתונים בסמיכות ליצירתם במערכות המקור, רק הולכת וגדלה.
במצגת זו אני מעוניין להציף את הדילמה המשמעויות והפתרונות האפשריים ב BW.
אעשה זאת דרך סיפור הלקוח של פרויקט "מאור" במזי.
אציג את זרוע היבשה, את הפתרון על הדילמות והשיקולים, וגם אגע טיפה בפאן הטכני
אנחנו חיים בעולם אינסטנס של רווח מהיר, הכול כאן ועכשיו, ארגון שלא עומד בקצב ולא יכול לנתח את העבר, להסיק מסקנות בהווה, להפיק לקחים ליישם ולהשתנות במהירות האור, לא יוכל לשרוד בעולם תחרותי זה.
אולי ה BI צריך להתיישר לדרישות השוק
לפני עשור ה BI היה טוען פעם ביום וצפונה – שבועי, חודשי...
היום אנו נתקלים פחות ופחות בטעינות שבועיות ויותר ויותר בטעינות תת יומיות.
אז בעצם למה לא להפוך את מחסן הנתונים למראת זמן אמת של מערכות המקור?
אנו כולנו מכירים את הסיבות טכניות
פגיעה בביצועי מערכת המקור
פגיעה בביצועי מחסן הנתונים
תעבורת רשת
סיכון לכשל בטעינות
אבל יש גם סיבה עקרונית
יש חשיבות ניתוחית להקפאת המצב.
ברור שישי עוד אלפי סיבות.
אני חוזר לאותו לקוח קצה שצריך הכול כאן ועכשיו.
בפועל אנו יודעים שניתוח מעמיק יביא אותנו להבנה שהצורך לא כל כך קריטי כמו שמתואר ברוב המכריע של המקרים.
אז מי צריך לקחת החלטה כשלקוח הקצה מעוניין בדוחות זמן אמת?
חשוב לאפיין היררכייה מתאימה לענות על שאלה זו.
מנתח מערכות ה BI צריך לדעת לשים מעצור ולהעביר את חובת ה"הוכחה לצורך" אל הלקוח.
בסוף ברור שלפני שניגשים לפתרונות יוצאי דופן צריך לבחון טוב טוב את כל הפרמטרים והחלטה צריכה להלקח בדרג שרואה את התמונה המלאה.
אנחנו חיים בעולם אינסטנס של רווח מהיר, הכול כאן ועכשיו, ארגון שלא עומד בקצב ולא יכול לנתח את העבר, להסיק מסקנות בהווה, להפיק לקחים ליישם ולהשתנות במהירות האור, לא יוכל לשרוד בעולם תחרותי זה.
אולי ה BI צריך להתיישר לדרישות השוק
לפני עשור ה BI היה טוען פעם ביום וצפונה – שבועי, חודשי...
היום אנו נתקלים פחות ופחות בטעינות שבועיות ויותר ויותר בטעינות תת יומיות.
אז בעצם למה לא להפוך את מחסן הנתונים למראת זמן אמת של מערכות המקור?
אנו כולנו מכירים את הסיבות טכניות
פגיעה בביצועי מערכת המקור
פגיעה בביצועי מחסן הנתונים
תעבורת רשת
סיכון לכשל בטעינות
אבל יש גם סיבה עקרונית
יש חשיבות ניתוחית להקפאת המצב.
ברור שישי עוד אלפי סיבות.
אני חוזר לאותו לקוח קצה שצריך הכול כאן ועכשיו.
בפועל אנו יודעים שניתוח מעמיק יביא אותנו להבנה שהצורך לא כל כך קריטי כמו שמתואר ברוב המכריע של המקרים.
אז מי צריך לקחת החלטה כשלקוח הקצה מעוניין בדוחות זמן אמת?
חשוב לאפיין היררכייה מתאימה לענות על שאלה זו.
מנתח מערכות ה BI צריך לדעת לשים מעצור ולהעביר את חובת ה"הוכחה לצורך" אל הלקוח.
בסוף ברור שלפני שניגשים לפתרונות יוצאי דופן צריך לבחון טוב טוב את כל הפרמטרים והחלטה צריכה להלקח בדרג שרואה את התמונה המלאה.
עליה לאויר הוקדמה
ה BW עלה לאויר ביחד עם המערכת כולה
במהלך כל הפרויקט השתמשנו במטודולוגיית ASAP
מימוש הפרויקט מתבצע על-גבי מערכת SAP ECC תוך שימוש במודול ה PS כמנגנון עקרי לתהליכי הרקע.
ה UI של הSAP לא התאים לצרכים של תכנון הגאנט שלנו ולכן החלטנו לפתח מנגנון UI בעצמנו.
את בניית המנגנון הוויזואלי ע"י טכנולוגיית Flash Island המשלבת Flex ו WebDinpro הציג חגי אייז במסלול....
הנתונים מיוצרים בגאנט, נשמרים ומנוהלים ב ECC המנהל גם את התהליכים העסקיים.
מה ECC הנתונים נגזרים אחת ל 5 דקות ל BW ע"י מנגנון ה RDA ומוצגים לצופה הסופי דרך WAD בפורטל הדוחות.
אנחנו חיים בעולם אינסטנס של רווח מהיר, הכול כאן ועכשיו, ארגון שלא עומד בקצב ולא יכול לנתח את העבר, להסיק מסקנות בהווה, להפיק לקחים ליישם ולהשתנות במהירות האור, לא יוכל לשרוד בעולם תחרותי זה.
אולי ה BI צריך להתיישר לדרישות השוק
לפני עשור ה BI היה טוען פעם ביום וצפונה – שבועי, חודשי...
היום אנו נתקלים פחות ופחות בטעינות שבועיות ויותר ויותר בטעינות תת יומיות.
אז בעצם למה לא להפוך את מחסן הנתונים למראת זמן אמת של מערכות המקור?
אנו כולנו מכירים את הסיבות טכניות
פגיעה בביצועי מערכת המקור
פגיעה בביצועי מחסן הנתונים
תעבורת רשת
סיכון לכשל בטעינות
אבל יש גם סיבה עקרונית
יש חשיבות ניתוחית להקפאת המצב.
ברור שישי עוד אלפי סיבות.
אני חוזר לאותו לקוח קצה שצריך הכול כאן ועכשיו.
בפועל אנו יודעים שניתוח מעמיק יביא אותנו להבנה שהצורך לא כל כך קריטי כמו שמתואר ברוב המכריע של המקרים.
אז מי צריך לקחת החלטה כשלקוח הקצה מעוניין בדוחות זמן אמת?
חשוב לאפיין היררכייה מתאימה לענות על שאלה זו.
מנתח מערכות ה BI צריך לדעת לשים מעצור ולהעביר את חובת ה"הוכחה לצורך" אל הלקוח.
בסוף ברור שלפני שניגשים לפתרונות יוצאי דופן צריך לבחון טוב טוב את כל הפרמטרים והחלטה צריכה להלקח בדרג שרואה את התמונה המלאה.
הדרישות כיוונו אותנו לפתרון של זמינות נתונים מיידית.
מה זה קובייה וירטואלית – יתרונות, חסרונות, מתי
מה זה טעינה לפי דרישה – יתרונות, חסרונות, מתי
מה זה טעינת זמן אמת – יתרונות, חסרונות, מתי
מה זה קובייה וירטואלית –
יתרונות:
לא דורש שמירת נתונים,
זמן אמת,
חסרונות:
זמן הצגת הדוח כולל את זמן הטעינה
עיבוד הנתונים בטעינה לא יכולים להיות מורכבים
הביצועים מגבילים את כמות הנתונים ואת סיבוכיות הטעינה
מתי:
כשמדובר במעט נתונים ובטעינות פשוטות
טיפ:
אפשר לטעון קובייה בטעינה יומית ולעשות קוביה וירטואלית על הרשומות החדשות בלבד – מעל שתי הקוביות לבנות MultyProvider
מה זה טעינה לפי דרישה
יתרונות:
המשתמש מקבל את הנתונים בדיוק מתי שהוא צריך, ללא תעבורה מיותרת.
מאפשר גם גזירות מסובכות
חסרונות:
העברת אחריות למשתמש
מתי:
משתמשים מסוימים מאד
כשהדיווח נדרש בסיום תהליך עסקי מוגדר
מה זה טעינת זמן אמת
יתרונות:
זמן אמת
טעינה דלתאית קטנה מאד
מאפשר גם גזירות מסובכות
הנתונים נשמרים במחסן הנתונים
חסרונות:
תעבורת רשת קבועה
מתי:
כשכמות הרשומות החדשות לזמן מוגדר לא גדולה
כשיש צורך בזמינות נתונים בכל זמן נתון
חיפוש ניסיון – לא מצאנו ניסיון אמיתי בארץ
בהמשך התברר שכלמוביל פיתחו במקביל אלינו
דילמות – עד לעליה לאוויר לא היה ברור מה היציבות של הכלי – גם בבדיקות שעלו יפה לא הצלחתי לקבל תחושת בטחון מלאה.
תקלות –
העברות טרנספורטים בזמן עבודת הכלי
טעינות מקבילות לאותו ODS הוביל ל OSS שלא נתן פתרון – מה שדרש מאיתנו לאלתר פתרון מקומי.
אנחנו חיים בעולם אינסטנס של רווח מהיר, הכול כאן ועכשיו, ארגון שלא עומד בקצב ולא יכול לנתח את העבר, להסיק מסקנות בהווה, להפיק לקחים ליישם ולהשתנות במהירות האור, לא יוכל לשרוד בעולם תחרותי זה.
אולי ה BI צריך להתיישר לדרישות השוק
לפני עשור ה BI היה טוען פעם ביום וצפונה – שבועי, חודשי...
היום אנו נתקלים פחות ופחות בטעינות שבועיות ויותר ויותר בטעינות תת יומיות.
אז בעצם למה לא להפוך את מחסן הנתונים למראת זמן אמת של מערכות המקור?
אנו כולנו מכירים את הסיבות טכניות
פגיעה בביצועי מערכת המקור
פגיעה בביצועי מחסן הנתונים
תעבורת רשת
סיכון לכשל בטעינות
אבל יש גם סיבה עקרונית
יש חשיבות ניתוחית להקפאת המצב.
ברור שישי עוד אלפי סיבות.
אני חוזר לאותו לקוח קצה שצריך הכול כאן ועכשיו.
בפועל אנו יודעים שניתוח מעמיק יביא אותנו להבנה שהצורך לא כל כך קריטי כמו שמתואר ברוב המכריע של המקרים.
אז מי צריך לקחת החלטה כשלקוח הקצה מעוניין בדוחות זמן אמת?
חשוב לאפיין היררכייה מתאימה לענות על שאלה זו.
מנתח מערכות ה BI צריך לדעת לשים מעצור ולהעביר את חובת ה"הוכחה לצורך" אל הלקוח.
בסוף ברור שלפני שניגשים לפתרונות יוצאי דופן צריך לבחון טוב טוב את כל הפרמטרים והחלטה צריכה להלקח בדרג שרואה את התמונה המלאה.
חיפוש ניסיון – לא מצאנו ניסיון אמיתי בארץ
בהמשך התברר שכלמוביל פיתחו במקביל אלינו
דילמות – עד לעליה לאוויר לא היה ברור מה היציבות של הכלי – גם בבדיקות שעלו יפה לא הצלחתי לקבל תחושת בטחון מלאה.
תקלות –
העברות טרנספורטים בזמן עבודת הכלי
טעינות מקבילות לאותו ODS הוביל ל OSS שלא נתן פתרון – מה שדרש מאיתנו לאלתר פתרון מקומי.