אחרי מספיק שנים עם Qlik Sense בארגונים ישראליים, מפתחים חוש מסוים: נכנסים לסביבה חדשה, פותחים שתי אפליקציות, ותוך רבע שעה אפשר לנבא די בדיוק איפה הפרויקט יכאב בעוד שנה. לא בגלל כישרון נבואי, אלא כי הטעויות חוזרות על עצמן. אותן שש, כמעט תמיד.
Qlik הוא כלי חזק, ולכן גם הטעויות בו חזקות: מודל מנופח אחד יכול להאט שרת שלם, וסקריפט לא מתועד אחד יכול להפוך מערכת שלמה לתלויה באדם אחד. הנה הרשימה, עם הדרך למנוע כל אחת, ומה עושים אם אתם כבר בפנים.
טעות 1: הכול באפליקציה אחת
מתחילים עם אפליקציית מכירות. ואז מוסיפים גם מלאי, כי קשור. ואז כספים, כי ביקשו. שנתיים אחרי, יש אפליקציה אחת עם עשרות טבלאות, מאות שדות וארבעים גיליונות, שכל מחלקה משתמשת בפינה אחרת שלה. היא איטית, כל שינוי בה מסוכן, וטעינה שלה תופסת את חצי הלילה.
הכלל הבריא: אפליקציה לכל תחום החלטות. מכירות לחוד, תפעול לחוד, כספים לחוד, כולן ניזונות מאותה שכבת נתונים משותפת. גבולות ברורים שומרים על מהירות, על אבטחה ועל שפיות בתחזוקה.
טעות 2: סקריפט בלי שכבות ובלי תיעוד
האפליקציה טוענת הכול ישירות מהמקור: שאילתות ארוכות על הפריוריטי, טרנספורמציות באמצע, הכול בסקריפט אחד של אלף שורות בלי הערה אחת. זה עובד מצוין, עד היום שבו צריך לשנות משהו, או שהבן אדם שכתב את זה עוזב.
הדרך הנכונה מוכרת וותיקה: ארכיטקטורת QVD דו שלבית. שכבה ראשונה שרק שולפת נתונים גולמיים מהמערכות ושומרת אותם, ושכבה שנייה שבונה מהם את המודל העסקי. כל שלב קצר, ממוקד ומתועד. זה לא בירוקרטיה, זו הסיבה שטעינה לוקחת עשר דקות במקום שלוש שעות, ושאפשר להחליף מפתח בלי להתחיל מאפס.
טעות 3: אין בעלים עסקי
האפליקציה "של המחשוב" או גרוע מזה, "של היועץ שבנה אותה". אף מנהל עסקי לא מרגיש שהיא שלו, אף אחד לא מוודא שהמדדים עדיין רלוונטיים, ואף אחד לא שם לב שחצי מהגיליונות מתים. ההשקעה נשחקת בשקט.
לכל אפליקציה צריך שם של אדם עסקי לידה: מי שמחליט מה נכנס, מי שעונה כשמספר נראה מוזר, מי שאומר פעם ברבעון "את זה כבר אפשר למחוק". בלי זה, גם האפליקציה הטובה ביותר היא יתומה עם תאריך תפוגה.
טעות 4: לשחזר את האקסל, רק יפה יותר
מביאים את דוח האקסל הוותיק ואומרים "תעשו לנו את זה ב-Qlik". והתוצאה: אותה טבלה, אותם טורים, רק עם לוגו. זה מפספס את כל הנקודה של הכלי, שנבנה לחקירה, לא לשחזור טבלאות. המשתמשים, בצדק, לא מבינים מה הרווח, וחוזרים לאקסל המקורי.
התהליך הנכון מתחיל משאלות, לא מדוחות קיימים: אילו החלטות אתם מקבלים, ומה אתם צריכים לראות כדי לקבל אותן טוב יותר? הדוח הישן הוא עדות למה שהיה אפשרי בכלי הקודם, לא מפרט למערכת החדשה.
טעות 5: קשרים לא מכוונים במודל
הקלאסיקה השקטה של Qlik: שני שדות עם אותו שם בשתי טבלאות מתחברים אוטומטית. לפעמים זה בדיוק מה שרצית, ולפעמים שדה גנרי כמו "תאריך" או "קוד" יוצר קשר שאיש לא התכוון אליו, והמספרים יוצאים שגויים באופן שקשה מאוד לאתר, כי הכול נראה תקין.
ההגנה: מוסכמות שמות קפדניות בסקריפט, בדיקה של מבנה המודל אחרי כל שינוי, וחשד בריא כלפי כל מפתח סינתטי שצץ. דקה של תשומת לב במודל חוסכת ימים של ציד באגים במספרים.
טעות 6: בלי מוסכמות, כל מפתח והסגנון שלו
Sales, sales_final, SalesNew2, מכירות_גרסה_ב. כל מפתח שעבר בפרויקט השאיר שכבה גיאולוגית משלו: סגנון שמות אחר, דרך אחרת לחשב, גיליונות ניסיון שנשארו. אחרי כמה שנים, האפליקציה היא אתר ארכיאולוגי שרק מומחה יכול לחפור בו.
הפתרון משעמם ולכן עובד: מסמך מוסכמות של עמוד אחד. איך קוראים לשדות, איך מסמנים דגלים, איפה כותבים הערות, מה מוחקים לפני מסירה. עמוד אחד, נאכף בעקביות, והסביבה נשארת קריאה גם אחרי חמישה מפתחים.
וטעות שביעית, שקטה: שוכחים את המשתמשים
היא לא טכנית ולכן לא נכנסה לרשימה הראשית, אבל היא קוברת יותר פרויקטים מכל השאר: בונים אפליקציה מצוינת ואז זורקים אותה על המשתמשים במייל עם קישור. בלי הדרכה, בלי הסבר מה השתנה, בלי מישהו שיושב איתם שעה ומראה איך חוקרים. התוצאה צפויה: אנשים פותחים פעם אחת, לא מבינים מה רואים, וחוזרים לאקסל שהם מכירים.
ההשקעה הנדרשת קטנה להפתיע: מפגש הדרכה מעשי אחד לכל קבוצת משתמשים, על הנתונים שלהם ועל השאלות שלהם, לא על נתוני דמו. ועוד דבר קטן עם השפעה גדולה: לשבת שבועיים אחרי ההשקה עם שלושה משתמשים ולראות מה הם באמת עושים. הפער בין מה שתכננתם למה שקורה בפועל הוא רשימת השיפורים הטובה ביותר שתקבלו.
אם אתם כבר עמוק בפנים: מסלול תיקון
גיליתם את עצמכם בשלוש טעויות ומעלה? קחו נשימה, לא בונים הכול מחדש. הסדר שעובד: קודם ממפים מה באמת בשימוש, ורוב הסיכויים שתגלו שאפשר לארכב שליש. אחר כך בונים שכבת QVD מסודרת מתחת לאפליקציה הקריטית ביותר, בלי לגעת בממשק שלה. ואז, בהדרגה, מפרקים את המפלצת לאפליקציות תחומיות. כל שלב נותן ערך בפני עצמו, ואף שלב לא מסכן את מה שרץ.
איך בודקים ספק או מפתח לפני שמתחילים
רוב הטעויות שברשימה נכנסות לארגון דרך מי שבונה. לכן, לפני שסוגרים עם מפתח או אינטגרטור, שלוש בקשות פשוטות: לראות סקריפט אמיתי שהוא כתב (מחפשים שכבות, הערות, מבנה, לא קסמים), לשמוע איך הוא מסביר ארכיטקטורת QVD למי שאינו טכני, ולקבל ממנו תוכנית מסירה: מה נשאר אצלכם ביד ביום שהוא מסיים. מי שעונה טוב על שלוש אלה כנראה לא ישאיר אחריו את הבלגן שתיארנו. מי שמתחמק, כבר ענה.
השורה התחתונה
אף אחת מהטעויות האלה היא לא באג של Qlik, והן לא נובעות מחוסר כישרון. הן קורות כשעובדים מהר בלי כללים, וזה קורה לכולם. ההבדל בין סביבה בריאה לבעייתית הוא לא גאונות, הוא משמעת קטנה ועקבית: שכבות, שמות, בעלים, תיעוד. משעמם? אולי. אבל המשעמם הזה הוא מה שמפריד בין השקעה שמחזיקה שנים לפרויקט שקוברים בשקט.
ואם אתם רוצים אבחון מהיר של הסביבה שלכם, התחילו משאלה אחת פשוטה: אם המפתח הראשי שלכם יודיע מחר על עזיבה, כמה שבועות ייקח למחליף להבין את מה שהוא השאיר? התשובה הכנה לשאלה הזאת היא מדד הבריאות האמיתי של כל סביבת Qlik.
רוצים להבין איפה הנתונים שלכם נתקעים? נשמח לשיחה קצרה.