איך בוחרים מערכת לעיבוד מסמכים חכם לחברה עם 200 עד 5,000 עובדים? בודקים דבר אחד לפני כל השאר, האם המערכת בודקת את המסמך מול ה-ERP לפני שהיא קולטת אותו, או רק מחלצת שדות ומשאירה לכם את הבדיקה. אחר כך בודקים חיבור ישיר, עבודה בלי תבניות, תהליכים רב-שלביים, איפה הנתונים נשמרים, וכמה זמן לוקחת ההטמעה.
בחברה בגודל הזה יש כבר ERP מסודר, פריוריטי או Oracle Fusion, ויש צוות שמקליד אליו. חשבוניות ספק, הזמנות לקוח, תעודות משלוח, תיקי יבוא. כל אחד מגיע במייל, ומישהו פותח אותו.
הבחירה כאן שונה מהמדריך איך לבחור מערכת קליטת חשבוניות בלבד, כי בחברה כזאת המסמכים מגיעים מכל הכיוונים. מה שעובד לחשבוניות צריך לעבוד גם להזמנות ולתיקים.
שבע שאלות לפני שבוחרים
האם היא בודקת מול ה-ERP לפני הקליטה
זה ההבדל בין סורק לבין מערכת. סורק מחלץ שדות. מערכת לעיבוד מסמכים חכם מוצאת את הזמנת הרכש, משווה, ועוצרת מה שלא תואם. בלי זה העבודה לא נעלמת, היא רק עוברת שלב.
חיבור ישיר או תוכנת ביניים
חיבור דרך Make, n8n או Zapier נראה נוח בדמו. בייצור הוא עוד מערכת שנופלת, עוד מקום שהנתונים עוברים דרכו, ועוד מישהו שצריך לתחזק אותה. חיבור ישיר ודו-כיווני ל-ERP גם קורא ממנו וגם כותב אליו.
תבנית לכל ספק או בלי תבניות
אם צריך להגדיר תבנית לכל ספק, מישהו אצלכם יתחזק מאות תבניות. ספק חדש או עיצוב חדש של חשבונית צריכים לעבוד מהמסמך הראשון.
תהליכים רב-שלביים
הזמנת רכש, תעודת קבלה וחשבונית הן תהליך אחד. תיק יבוא הוא חמישה מסמכים שמגיעים בנפרד. מערכת שמטפלת בכל מסמך לבד משאירה לכם את החיבור ביניהם.
איפה הנתונים נשמרים
בחברה עם 200 עובדים ומעלה יש כבר מישהו שאחראי על אבטחת מידע, והוא ישאל. בדקו אם אפשר להתקין על השרתים שלכם, ואם הנתונים יוצאים לצד שלישי.
כמה זמן לוקחת ההטמעה
פרויקט של חצי שנה לא מתאים לחברה בגודל הזה. הטמעה סבירה נמדדת בשבועות, לא ברבעונים, ומתחילה מסוג מסמך אחד.
עברית ואנגלית
חשבונית מספק מקומי בעברית, פקינג ליסט מהספק בסין באנגלית. המערכת צריכה לקרוא את שניהם, לפעמים באותו מסמך, בלי שתגדירו לה שפה.
מה שונה בחברה של 200 עד 5,000 עובדים
יש כבר ERP, ואין כוונה להחליף אותו
המערכת צריכה להתאים לפריוריטי או ל-Oracle Fusion כפי שהם, בלי פיתוח ובלי לשנות תהליכים. ככה נראית אוטומציה בפריוריטי שלא דורשת פרויקט.
אין צוות פיתוח פנוי
מנהל מערכות המידע מנהל עשרות מערכות. פתרון שדורש קוד או תחזוקה שוטפת ייתקע אחרי החודש הראשון, כשהמפתח שהקים אותו עובר לפרויקט אחר.
הנפח גדל, הצוות לא
כשכוח האדם מצטמצם והחברה גדלה, המסמכים מתרבים. הפתרון צריך לגדול עם הנפח בלי להוסיף עובדים.
מודל כללי או מתמחה
על ההבדל בין מודל כללי למודל שמתמחה במסמכי שרשרת אספקה יש ויכוח בתעשייה. בפועל, מודל שמכיר חשבוניות, הזמנות ותיקי יבוא טועה פחות על המסמכים שלכם.
איך זה עובד עם דוקונברט
דוקונברט היא שכבת ה-AI מעל ה-ERP. היא מחוברת לפריוריטי דרך הקונקטור הדו-כיווני של דוקונברט לפריוריטי, ול-Oracle Fusion Cloud ERP בחיבור ישיר, בלי תוכנת ביניים. ככה נראית הזמנת לקוח אחת.
ההזמנה מגיעה למייל
כ-PDF מהלקוח, בפורמט שלו. אין טופס ואין פורטל.
דוקונברט מזהה את הלקוח
לפי כתובת המייל ולפי המסמך, ומושכת מה-ERP את כרטיס הלקוח, המחירון וההסכם.
דוקונברט בודקת את השורות
פריטים, כמויות ומחירים מול הנתונים ב-ERP. פריט לא מוכר או מחיר שונה נעצרים עם הסבר, והצוות מטפל רק בהם.
ההזמנה נקלטת
כהזמנת לקוח בפריוריטי, מקושרת ללקוח הנכון. אותו תהליך עובד גם להזמנות לקוח שמגיעות ב-PDF בכל ERP, וגם לחשבוניות ספק ולתיקי יבוא.
למי זה מתאים
סמנכלי כספים וחשבים שרוצים שכל חשבונית תיבדק מול ההזמנה לפני שנקלטת.
מנהלי מערכות מידע שמחפשים חיבור ישיר לפריוריטי או ל-Oracle Fusion בלי פיתוח.
סמנכלי תפעול בחברות ייצור, הפצה ויבוא עם מאות מסמכים בשבוע.
קבוצות גדולות שרוצות להתחיל מחברה בת אחת ולהרחיב.
שאלות ותשובות
האם צריך להחליף את ה-ERP?
לא. דוקונברט מתחברת לפריוריטי ול-Oracle Fusion כפי שהם, ומשאירה את הנתונים אצלם.
כמה זמן לוקחת ההטמעה?
הטמעה טיפוסית של דוקונברט היא כ-10 ימי עסקים. מתחילים מסוג מסמך אחד, בדרך כלל חשבוניות ספק או הזמנות לקוח.
מה אם יש לנו גם חשבוניות וגם הזמנות וגם תיקי יבוא?
זה בדיוק המקרה. אותה מערכת מטפלת בכולם, ואפשר להתחיל ממערכת לקליטת חשבוניות ספקים ולהוסיף סוגי מסמכים אחרי.
האם הנתונים יוצאים מהארגון?
לא חייבים. אפשר להתקין את דוקונברט בענן ייעודי או על השרתים שלכם, והחיבור ל-ERP ישיר.
רוצים לראות את זה על המסמכים שלכם? לתיאום דמו או להתחיל ניסיון