→ כל הפרויקטים פרויקט 02 ייצור · ארכיטקטורה · מערכות מידע Proof of Concept · 2026

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

“איפה הפריט עומד עכשיו?” היא אחת השאלות הפשוטות ברצפת ייצור — ובהרבה מקרים, כדי לענות עליה צריך לשאול אדם. שיניתי ישות אחת: ממכונה לפריט.

המציאות
מידע ייצור קיים — אבל מפוזר בין מכונות, הזמנות, תחנות ואנשים, ומאורגן סביב המכונה ולא סביב הפריט.
הפער האמיתי
הישות המרכזית של המערכת לא תאמה את השאלה הניהולית. התרגום ממכונה לפריט חי בראש של אדם מנוסה.
מה נבנה
מערכת Streamlit שמארגנת מידע קיים סביב הפריט: Manager View, Work Orders, Operator View ו-Analytics.
01

מקור הבעיה

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

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

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

עקרון הפתרון

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

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

ארכיטקטורה · שלוש שכבות

1
קלט / מקור מידע
קובצי JSON (תחנות, Jobs, Work Orders) ונתוני Demo, מאחורי DataManager facade כנקודת גישה אחת.
2
עיבוד / ארגון
Models ו-Repositories (CRUD + גיבויים), ו-Services ללוגיקה: workflow, work orders, dashboard, charts.
3
תצוגה / פעולה
Views נפרדות למנהל ולמפעיל, גרפי Plotly ו-Waterfall, וייצוא CSV דרך pandas.
PythonStreamlitpandasPlotlyJSONdataclassesRepository Pattern

החלטה ארכיטקטונית מרכזית: פריט כישות מרכזית (ולא מכונה) — זו ההשערה של ה-PoC. Repository Pattern מפריד את ה-persistence מהלוגיקה, כך שאפשר להחליף ל-DB בעתיד.

04

המימוש בפועל

שש מסכים מוכיחים את הזרימה — מהגדרת Job כמסע פריט ועד תמונת ייצור כוללת.

pcf · manager view
מסך Manager View עם הגדרת Job כרצף תחנות למסע פריט
Manager View — ישות-פריט בפעולה
Whyהגדרת Job עם רצף תחנות — כאן מתחיל המעבר ממכונה לפריט.
pcf · work orders
מסך Work Orders לתכנון יומי, שיוך Jobs ופרסום
Work Orders — ידע מנהל הופך למבנה
Whyסדרי עדיפות שחיו בראש המנהל הופכים לתצוגה תפעולית מסודרת.
pcf · analytics
מסך Analytics עם גרפים וסטטוסים סביב מסע הפריט
Analytics — שאילתות חדשות מאותם נתונים
Whyאותו מידע, מאורגן סביב הפריט, מייצר שאלות שאפשר לשאול ישירות.
pcf · status assessment
מסך Status Assessment עם תמונת מצב מרוכזת לפריטים
Status Assessment — בדיקת מצב בזמן אמת
Whyתמונת סטטוס מרוכזת שמחברת החלטת ניהול לעדכון שוטף על מסע הפריט.
pcf · operator view
מסך Operator View לביצוע משימות בתחנה לפי מסע הפריט
Operator View — עבודה תפעולית בקו
Whyהמפעיל רואה את הפעולה הרלוונטית מתוך מסע הפריט, בלי תרגום ידני בין מסכים.
pcf · drawing cards
מסך Drawing Cards עם מסע הפריט המלא לפי תחנות
Drawing Cards — כרטיס = פריט, לא מכונה
Whyהמפעיל רואה את מסע הפריט המלא — לא רק את הפעולה הנוכחית בתחנתו.
05

ערך תפעולי וגבולות אמת

מה זה מוכיח
הוכחת גישה: ארגון מחדש של מידע קיים סביב הישות הנכונה משנה את מה שניתן לדעת — בלי להוסיף מידע.
סטטוס
PoC עם נתוני Demo, לא מחובר לנתוני CNC אמיתיים.
מה לא נבנה
אין Authentication, אין חיבור ERP/מכונה, ואין DB מלא — JSON
שנה את הישות — ושינית את מה שניתן לדעת.

מכאן אפשר להעמיק

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