מחסן נתונים DATA WAREHOUSE המדריך

מבוא - הסבר כללי

מחסן נתונים היא סביבת מחשוב מיוחדת לניהול נתונים המיועדים לקבלת החלטות בארגון. מחסן הנתונים (DWH- Data Warehouse) היא מערכת מידע המכילה מאגר נתונים מקיף ומאפשרת תחקור מידע לצורך תמיכה בתהליכי קבלת החלטות בארגון ו/או איתור מקרים חריגים. מחסני נתונים מאופיינים לרוב, בנפחי מידע גדולים של נתונים היסטוריים רב-תקופתיים. מחסני נתונים אינם מעדכנים נתונים אלא מתבססים על מאגרי מידע תפעוליים (OLTP - Online transaction processing) אופרטיביים בארגון ומחוצה לו כגון: כספים, שיווק, מלאי, ניהול היצור וכ"א.

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

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

סוגי מערכות

מקובל לסווג את מערכות מחסן הנתונים לשני סוגים:

 ·         מערכת ארגונית/רב ענפית ((Data Warehouse - מחסן נתונים המתמקד במספר תחומים עסקיים כאשר כל תחום הוא נושא בפני עצמו. לכל תחום יש מאפיינים ייחודיים משלו כאשר חלק מהמאפיינים משותפים למספר תחומים. בהקמת מערכת מסוג זה יש לענות על הצרכים הייחודיים של כל ענף וכן להתייחס לאינטגרציה של סוגי המידע השונים לכלל מערכת אחת, תוך התאמה לצרכים  המגוונים של משתמשים רבים  בעלי דרישות שונות.

 ·         מערכת מחלקתית/ענפית (Data Mart) - מחסן נתונים המתמקד בתחום עסקי אחד של  הארגון – שכר, כ"א, ייצור וכד'.

ארכיטקטורה כוללת

להלן הצגה סכמתית של הארכיטקטורה של מערכות מחסן נתונים

 

 

מערכת מחסן נתונים קלאסית נחלקת לחמישה חלקים:

 ·         מערכות תפעוליות (On Line Transactional Processing - OLTP) - המערכות התפעוליות בארגון או מחוצה לו, המהוות את מקורות המידע העיקריים למחסן הנתונים.

 ·         מאגר נתונים תפעולי ((ODS - Operational Data Store. מאגר נתונים הדומה באפיונים שלו לאפיוני מחסן הנתונים אולם הוא מכיל נתונים הנדרשים על ידי המערכות התפעוליות ולכן מכיל נתונים עדכניים הרבה יותר והעומק ההיסטורי שלו קטן.

 ·         שטח הקליטה והטיפול בנתונים Staging Area) - STA) – המקום בו ייקלטו הנתונים הנגזרים מהמערכות התפעוליות, יסוננו, יטויבו, יסוכמו (לא תמיד) ואז יועברו למחסן הנתונים המרכזי.

 ·         מאגר המידע ( Data Warehouse- DW) - בסיס הנתונים המרכזי של מחסן הנתונים. המאגר מכיל את הנתונים שנגזרו מהמערכות התפעוליות, לאחר שטויבו והותאמו למאגר האינטגרטיבי המרכזי. אחסון הנתונים נעשה לרב במסד נתונים יחסי, במבנה סכימת כוכב וכולל טבלאות סיכום לשיפור ביצועים. יתכן גם קישור לבסיס נתונים רב ממדי ליישומי OLAP.

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

 

יש לשים לב לחצים הפנימיים במחסן הנתונים הפונים ממאגר הנתונים הראשי כלפי מעלה לטבלאות הסיכום. חצים אלה פירושם שבנוסף למהלכי קליטת המידע (ETL - Extraction, Transformation & Load) , יש גם מהלכי עדכון של קבצים שתפקידם לשרת שאילתות מורכבות. מערכות מחסן נתונים מכילות מהלכי אצווה כלל לא-טריוויאליים.

למרות הדמיון הכללי של ארכיטקטורה זו לארכיטקטורה הקלאסית של מערכות עיבוד נתונים (קלט, עדכון, שאילתות-פלט), יש למערכות מחסן נתונים ייחודיות בנקודות הבאות:

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

ב.       עיצוב בסיס הנתונים אינו מנורמל (כמקובל במערכות קלאסיות) - ראה בהמשך.

ג.        מחסן הנתונים מהווה בסיס לעיבוד נתונים בשיטות מיוחדות: OLAP ו- Data Mining, ראה הקיט מערכות EIS בכרך התמחויות/מערכות מידע .

ד.       תלות במערכות התפעוליות – מחסן הנתונים אינו מייצר מידע חדש אלא מתבסס על מידע הנשאב ממערכות תפעוליות.

ה.      מחסן הנתונים מחזיק עומק היסטורי של הנתונים.

ו.         שירות למגוון גדול של משתמשי קצה:

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

             ·         מנהלים בדרג ביניים - לצורך קבלת מידע אופרטיבי ("כמה מכרנו בחודש האחרון")

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

 

עיצוב בסיס הנתונים

בעיצוב בסיס הנתונים של מערכות מחסן נתונים יש להתמודד עם שני אתגרים עיקריים:

 ·         כמות גדולה מאוד של נתונים.

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

 

עקרונות עיצוב בסיס הנתונים של מחסני נתונים שונים מבסיסי נתונים רגילים בנקודות הבאות:

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

 ·         טבלאות סיכום - בנוסף לטבלאות המידע הבסיסיות, מוגדרות טבלאות סיכום המכילות נתונים מסוכמים מראש. שאילתות מנותבות דרך טבלאות הסיכום לצורך שיפור ביצועים.

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

מודל הכוכב

פתרון קלאסי ומקובל לעיצוב מחסן נתונים הוא מודל הכוכב (Star Schema). מודל זה  מכיל טבלה מרכזית גדולה מאד (Fact Table) בה נמצאות רשומות המידע הבסיסיות (הגולמיות) שהן ברמת הפירוט הגבוהה ביותר. "מסביב" לטבלה המרכזית יש אוסף של טבלאות אשר מגדירות את הממדים (החתכים) השונים לפיהם ניתן לחתוך את המידע הבסיסי. בנוסף, קיימות טבלאות סיכום שמטרתן לסייע בביצוע שאילתות מורכבות. ניתן כמובן, תמיד, לבצע שאילתות ישירות מול המידע הבסיסי (Fact Table), אלא שאז עשויה להיות בעיה של ביצועים וזמני תגובה, בפרט במאגרים גדולים.

 

 

יתרונות מודל הכוכב הם:

 ·         מודל פשוט.

 ·         מקטין למינימום את השימוש בפעולות  join.

 ·         מאפשר ביצוע שאילתות מורכבות ע"י משתמשי קצה.

 ·         מאפשר הפשטה של מודלים מורכבים.

 ·         מהווה מקור נתונים עבור בסיס נתונים רב ממדי.

 

החסרונות, לעומת זאת, הם:

 ·         שכפול נתונים (צורך שטחים גדולים).

 ·         סיכון של חוסר עקביות בנתונים.

 ·         מחייב טבלאות סיכום רבות.

 

מודלים נוספים

בנוסף לסכימת הכוכב, קיימים מודלים נוספים המהווים הרחבה שלו:

 ·         מודל פתיתי השלג (Snow Flakes) - מודל זה מבוסס על מודל הכוכב, אך מאפשר טבלאות עזר - סגמנטים - מעל טבלאות הממדים. מבנה זה משמש בעיקר במצב בו מצטברים נתונים רבים בטבלת ממד אשר הופכים אותה ללא יעילה.

 ·         מבנה מרובה כוכב (Multi Fact Table) - משמש לקישור כמה  מערכות מחסן נתונים, אשר חלק   מטבלאות הממדים שלהן משותפות.

 

להלן מודל פתיתי השלג בדוגמה של מחסן נתוני מכירות. טבלת הסגמנטים (פתית השלג) של ממד המוצרים, נותנת סיווג לפי קטגוריות של מוצרים.

 

שפה ומינוח

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

ניהול הפרויקט – מחזור חיים

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

ניהול הפרויקט

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

 

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

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

שלבי מחזור החיים

ייזום

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

מסגרת הזמן והיקף ההשקעה ביזום

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

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

לקוחות המערכת

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

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

לקוח, מומחי יישום ומשתמש עיקרי

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

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

אפיון

לימוד מצב קיים

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

דגשים באפיון

אפיון של מערכת מחסן נתונים מתמקד במספר נושאים מרכזיים:

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

 ·         הגדרת  s - Key Performance Indicators’KPI – הגדרה של קריטריונים עיקריים להצלחת מחסן הנתונים כולל פרמטרים מספריים מדידים לצורך בדיקה מאוחרת.

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

 ·         עיצוב בסיס הנתונים - בניגוד למערכת המבוססת על בסיס נתונים טבלאי רגיל, אשר מאפשרות לממש כל דו"ח ודרישה של המשתמש, הרי שבמערכת מחסן נתונים מגבילים מבנה בסיס הנתונים והיקף הנתונים את יכולות השליפה. יש לתכנן את מבנה הנתונים לפי דרישות האחזור הייחודיות של כל ארגון ומשתמש. תוצר חשוב של שלב זה הוא המלצה אם להקים מחסן מידע שיספק את כל צרכי המשתמשים, או להקים מספר מרכולי מידע, Data Marts, ומהם ליצור את מחסן המידע.

 ·        הגדרת תהליך Source To Target – בשלב האפיון יש להגדיר את מבנה טבלאות היעד והמקורות מהם נלקחים הנתונים בכל אחד משלוש השכבות היוצרות את מחסן הנתונים:ODS, STA, DW.

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

בקשה להצעות

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

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

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

 

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

עיצוב ובנייה

שלב העיצוב והבנייה מתמקד במהלך איסוף הנתונים וגזירתם ממערכות תפעוליות, טיובם וטעינתם למאגר המידע במבנה מודל הכוכב (Star Schema). בהערכה כללית ניתן לאמוד עלויות שלב זה ב- 60% לערך מכלל העלויות של הקמת המערכת היישומית. השקעה מרכזית נוספת היא בעיצוב הממשק למשתמש, בניית השאילתות והדו"חות והתאמה של כלי האחזור למודלים הנדרשים להצגת הנתונים וניתוחם.

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

בדיקות מערכת

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

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

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

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

בדיקות הקבלה של המשתמשים צריכות להתחלק בין מומחי התוכן של התחומים השונים כדי ליהנות מהבנתם את עולם תוכן הנתונים.

התקנה והרצה

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

תחזוקה

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

תוצרים

תיק מערכת

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

תיק נושא

תוצר נוסף הנו תיק נושא אשר מהווה תיק פרויקט לתחום מסוים המהווה חלק ממחסן הנתונים. בכל פעם שיש להוסיף נושא חדש למחסן הנתונים הארגוני ייכתב תיק נושא אשר ירכז בתוכו את כל הדרישות (אפיון ועיצוב) לנושא עצמו. במקביל יעודכן תיק המערכת הכללי בפרטים הקשורים לנושא זה. טבלאות אשר יהיו משותפות למס' נושאים יטופלו בתיק המערכת ובתיק הנושא תבוצע רק הפנייה אליהן.

אבטחת איכות

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

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

 ·         האם המסמך תואם את מטרתו?

 ·         מה מידת מחויבות המעורבים לתוכן המסמך?

 ·         האם מכיל מספיק מידע על מנת לקבל החלטה להמשך?

 ·         האם ברור מה הצעד הבא ומה משמעויותיו?

 ·         האם כל נושא במערכת תוחם באופן ברור?

 ·         האם קשור בתכנית העבודה השנתית או בתכנית אב (תכנון אסטרטגי)?

 ·         מי אישר את המסמך?

 ·         האם נכתב לפי הכללים הנהוגים בארגון?

 

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

 ·         ניהול סיכונים

 ·         אמידת עלויות

 ·         הערכת עלות/תועלת

 ·         הגדרת משאבים לפרויקט לכל אחד משלביו

 ·         הגדרת ועדות ובעלי תפקידים לפרויקט

 ·         כתיבת נוהלי העבודה בין המעורבים לאורך ביצוע הפרויקט

 ·         מחויבות הארגון לתהליך ומעורבת ההנהלה

 ·         הגדרת תכולת הפרויקט ושלבים לביצועו

 ·         הגדרת מומחי תוכן לכל נושא במערכת

 ·         היערכות ארגונית להטמעה והדרכה