→ כל הפרויקטים פרויקט 04 ייצור · ניהול ידע · אינטגרציה · AI Active Demo · PoC · 2026

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

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

המציאות
הנתונים שעונים על שאלות הכדאיות קיימים — אך מפוזרים בשלושה מקומות: ניהול ייצור, דוחות מדידה, וטפסי ביקורת. אין ביניהם חיבור אוטומטי.
הפער האמיתי
לא בעיית סריקה או OCR. הנתונים קיימים אך אינם מחוברים — והחיבור חי רק בראשו של מנהל המחלקה. כשהוא עוזב, הידע הולך איתו.
מה נבנה
PoC שמאחד שתי שרשראות מידע, מסיק איזה כלי ביצע איזו עבודה, מחשב שלושה מדדי כדאיות, ומחזיר המלצה: שמור / עקוב / בחן מחדש.
01

מקור הבעיה

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

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

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

עקרון הפתרון

במקום לשאול אדם “מה אתה יודע”, STKMS שולפת את הידע ישירות מהמערכות הקיימות ומחברת אותו לכלל החלטה. הליבה אינה קריאת דוח בודד — אלא החיבור וההיסק בין המקורות. ה-LLM קורא דוחות PDF ומחלץ מידות, אבל הוא שכבת קריאה בלבד, לא הליבה.

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

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

א
שרשרת א׳ · מצב קיים
מחבר שקורא רשומות כלים ונתוני שימוש/ייצור מ-ERP/Excel — תמונת המצב הקיים של הכלי בארגון.
ב
שרשרת ב׳ · דוחות + היסק
נתוני CMM (Excel) ודוחות PDF בקריאת LLM, ומנגנון היסק שמסיק מהמידות שנמדדו איזה כלי מיוחד ביצע את העבודה.
הצלבה + שלושה מדדים
מצליב את ההיסק מול נתוני השימוש, ומחשב שלושה מדדים: ממוצע שימושים בשנה · מספר פרויקטים שונים · שנים ברצף.
מנוע המלצה + פלט
תמונת מצב מאוחדת והמלצה לכל כלי מיוחד: שמור / עקוב / בחן מחדש.
LLM · PDF readingExcel I/OInference engineRecommendation engineDatabase · PoC

החלטה ארכיטקטונית מרכזית: מבנה שתי שרשראות + היסק כמחבר — הערך הוא בחיבור בין מצב הכלי לדוחות, לא בקריאת דוח בודד. ERP ו-CMM מיוצגים כקובצי Excel ברמת ה-PoC, וה-LLM מוגבל לקריאת PDF כדי שלא יהפוך לליבה.

04

המימוש בפועל

שמונה לשוניות הדמו, בסדר הזרימה של המערכת: שרשרת א׳ (מצב קיים) ← שרשרת ב׳ (דוחות + קריאת LLM) ← הצלבה והיסק ← סקירה אנושית ← מדדים והמלצה. לחיצה על כל מסך פותחת אותו בגודל מלא.

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

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

מה זה מוכיח
מתודולוגיה מובנית — וחיבור עולם תפעולי-ייצורי עם אינטגרציה, היסק ו-AI כשכבה, לא כזהות.
סטטוס
Demo פעיל · PoC לתיק עבודות, מידע סימולציה בנפח קטן,
מה לא נבנה
אין חיבור ERP/CMM חי (Excel בלבד), אין משתמשים או נתונים אמיתיים, ואין ROI כספי מדוד.
כשמנהל המחלקה עוזב, הידע לא צריך ללכת איתו.

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

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