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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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