גרשון דיאמנט – .E.I .MSc

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

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

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

 כמובן שבמפעל יצרני חייבים גם לנהל מלאי בתהליך גם על פריטי הקצה (מסוג Buy) וגם על פריטי ה- Make. ולא די בכך – את המלאי בתהליך, יש לנהל ברמת פריט ופעולה ולא חסרות דוגמאות נוספות של סיבוך, במבנה עץ המוצר או בתמחיר ולא כאן המקום להרחיב ולשכנע את המשוכנעים בלאו הכי. פתרונות מוצלחים יותר של שילוב מערך תפעול ומערך פיננסי הם חבילות התוכנה של מס' חברות בין-לאומיות, אבל גם כאן קיימת בעיה – המערך הפיננסי שלהם אינו מתאים לארץ, ואז בדרך כלל ממליצים למשתמש על מערך פיננסי תוצרת הארץ ותופרים ממשקים המחברים בינו לבין התפעול הלועזי. מעבר לעלות הגבוהה מאוד של פתרון מהסוג הזה קיימת בעיה של נושאים ותחומים שונים שהם בתחום הביניים ובהעדר פתרון משביע רצון בתחום התפעול מנסים לשלב אותם בתחום הפיננסי בצורה מאולצת ויקרה. הבה ונתעכב על מספר נושאים כאלה.

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

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

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

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

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

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

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

•  דוחות ערך מלאי

• הזמנות רכש לפי ספק

• הזמנות רכש לפי פריט

• חוזי רכש שנתיים

• השוואת מחירים לפריט וספק

• הזמנות לקוח לפי ארץ ויבשת

• מכירות לפי לקוח וארץ

• מכירות לפי פריט

• רווחיות לפריט ולהצעת מחיר

• רווחיות לפריט ולהזמנת לקוח

• רווחיות כוללת לתקופה ולפי סוכן

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