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

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

הבעיה מתחילה במקום אחר.

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

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

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

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

מתחילים בתהליך העסקי, לא בטכנולוגיה

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

באיזו שפה נפתח? איפה המערכת תשב? איזו פלטפורמה נבחר?

אלה שאלות חשובות, אבל הן מגיעות בשלב מאוחר יותר.

לפני הכול צריך להבין מה קורה בעסק היום.

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

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

לא תמיד צריך לפתח מערכת חדשה

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

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

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

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

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

סימן ראשון: העובדים מעתיקים את אותו מידע ממערכת למערכת

נניח שהזמנה חדשה נכנסת דרך אנשי המכירות.

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

כל מערכת בפני עצמה יכולה להיות מצוינת.

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

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

סימן שני: קובץ Excel הפך למערכת קריטית

Excel הוא כלי עבודה מצוין, והבעיה אינה בעצם השימוש בו.

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

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

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

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

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

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

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

אבל העסק שסביבה השתנה.

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

גם כאן לא תמיד צריך למחוק הכול ולהתחיל מחדש.

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

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

• אנשי המכירות מסתכלים על ה-CRM.
• התפעול עובד במערכת אחרת.
• המחסן מנהל את המלאי במקום נוסף.
• הנהלת החשבונות מחזיקה מידע משלה.

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

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

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

מתי פיתוח תוכנה בהתאמה אישית הופך לאפשרות הנכונה?

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

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

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

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

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

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

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

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

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

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