חברה לפיתוח Dashboard לניהול מוצרים מחוברים: מה הלוח צריך להציג ואיך בונים אותו נכון

חברה לפיתוח Dashboard לניהול מוצרים מחוברים בונה את הממשק שבו צוות התפעול, התמיכה, הטכנאים ולעיתים גם הלקוחות רואים את מצב המכשירים בשטח ופועלים עליהם. לוח טוב מציג קודם את מה שדורש טיפול, מאפשר לרדת מהצי כולו למכשיר בודד ולהיסטוריה שלו, ומציג נתונים שאפשר לסמוך עליהם. כדי לבנות לוח כזה, החברה צריכה להבין את הנתונים שמגיעים מהמכשיר ולא רק לעצב מסכים, ולכן יש יתרון לחברה שמכסה גם את התוכנה במכשיר, את הענן ואת הממשק. ב-TandemG, לוח הניהול נבנה כחלק מפיתוח IoT מקצה לקצה: צוותי ה-Embedded, הענן, ה-Full Stack והמובייל עובדים על אותו מוצר, מהנתון שנמדד במכשיר ועד התצוגה. החברה פועלת בישראל מאז 2010, עם צוותים בלוד ובריגה.

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

למי הלוח מיועד: ארבעה קהלים מרכזיים

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

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

מה חייב להיות בלוח ניהול למוצרים מחוברים

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

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

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

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

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

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

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

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

הנתונים שמאחורי הלוח

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

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

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

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

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

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

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

עקרונות שמבדילים לוח שימושי מלוח מרשים

חריגים קודם. לוח שמציג מאה גרפים ירוקים מסתיר את המכשיר האחד שדורש טיפול.

מהכלל אל הפרט. מתמונת הצי, לקבוצה, למכשיר, לאירוע. כל לחיצה מקרבת לתשובה.

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

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

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

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

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

שפה של המשתמש. "שגיאה 0x1F" לא אומרת לנציג שירות דבר. תרגום של קודי שגיאה להסבר ולפעולה מומלצת הופך את הלוח לכלי עבודה.

תרחיש לדוגמה: פנייה של לקוח, דקה אחת בלוח

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

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

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

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

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

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

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

כלי מדף, פלטפורמת IoT או פיתוח מותאם

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

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

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

פורטל ללקוחות: מה שונה בלוח שהלקוח רואה

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

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

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

דוחות. דוחות תקופתיים שאפשר להוריד ולהעביר הלאה, בפורמט שמתאים לו.

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

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

איך יודעים שהלוח מצליח

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

לוח שגדל עם הצי

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

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

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

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

איך נראה פרויקט פיתוח של לוח ניהול

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

שאלות שכדאי לשאול חברה לפני שבוחרים

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

טעויות נפוצות בפיתוח לוח ניהול למוצרים מחוברים

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

שאלות נפוצות

מה זה Dashboard לניהול מוצרים מחוברים?

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

למה חשוב שהחברה שבונה את הלוח תכיר את המכשיר?

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

האם אפשר להשתמש בכלי מדף במקום פיתוח מותאם?

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

מה ההבדל בין לוח לצוות פנימי ללוח ללקוחות?

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

איך מבטיחים שהלוח יישאר מהיר כשהצי גדל?

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

האם לוח ניהול צריך גרסה לנייד?

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

כמה זמן לוקח לבנות לוח ניהול?

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

על איזה כלי כדאי לבנות לוח ניהול?

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

מה עושים כשהמכשירים הקיימים לא מדווחים את מה שהלוח צריך?

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

האם אותו לוח יכול לשמש גם לניתוח עסקי?

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

היתרון של TandemG

בחברת TandemG אנו בונים לוחות ניהול למוצרים מחוברים מתוך היכרות עם כל השרשרת: התוכנה במכשיר, התקשורת, הענן והממשק. מחלקת ה-Cloud וה-Full Stack שלנו מפתחת את הלוח והשירותים שמאחוריו, ומחלקת ה-Embedded דואגת שהמכשיר ידווח את מה שהלוח צריך. כשחסר נתון שהמכשיר יכול למדוד, הוא מתווסף לתוכנה של המכשיר בעדכון הבא.

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

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

למי מתאים

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

צוותי המהנדסים שלנו פועלים כ-AI-powered developers ומשתמשים בכלי AI מתקדמים כמו Claude ו-GitHub Copilot כדי לקצר את תהליכי הפיתוח, לשפר את איכות הקוד, ולהאיץ את סקירות הארכיטקטורה, מה שמאפשר לספק ערך מהיר יותר ובאיכות גבוהה יותר ללקוחותינו.

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

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

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