תוכנה לניהול ייצור

שני עולמות, שני קצבים

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

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

המדידה שעושים לפני שמזמינים

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

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

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

הגבול שצריך לשרטט

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

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

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

למה מערכות לא נכנסות לשימוש

הסיבה הנפוצה היא לא איכות התוכנה אלא למי היא תוכננה.

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

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

קריאה מהציוד: איפה הזמן באמת נגמר

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

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

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

סימנים שההצעה לא תחזיק

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

איך אני עובד על זה

עיסוק בתחום מאז 2004, עבודה על מערכות AI מאז 2023, פרויקטים ללקוחות בארבע עשרה מדינות. אני ארכיטקט עצמאי ולא ספק מערכות, ולכן המסקנה «הוסיפו שכבה דקה ואל תיגעו ב-ERP» היא תוצאה לגיטימית של סקירה, ולא פעם אחת היא גם הנכונה.

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