למי מתאים פיתוח מערכת ווב ייעודית, ולמי זה פשוט יותר מדי?
יש סימן אחד שמזהה עסק שכבר מפעיל מערכת בלי לדעת את זה. פותחים גיליון גוגל, ובו טבלה של לקוחות או הזמנות. לצידה קבוצת וואטסאפ שבה מעדכנים סטטוסים. ולצידה תיקייה של קבצים ששמם מכיל תאריך וגרסה. שלושת אלה ביחד הם מערכת מידע, פשוט אחת שאף אחד לא כתב, שאין בה הרשאות, שאין בה היסטוריה ושאי אפשר לחפש בה. השאלה אם אתם צריכים פיתוח ייעודי היא בעצם השאלה כמה זמן וכמה טעויות עולה לכם ההפעלה הידנית של הדבר הזה כל חודש. במאמר הזה אני נותן חישוב פשוט שמכריע, ארבע משפחות של מערכות שאני בונה בפועל, ובאותה מידה גם את הצד השני: מתי זו הגזמה, ומתי תוסף מהמדף או טופס חכם פותרים את הכול בעשירית מהמחיר. המחירים כאן לפני מע״מ.
תוכן העניינים 7 פרקים
הסימן המזהה: תהליך שרץ בגיליון ובוואטסאפ
הסימן אינו כמות העבודה אלא מספר המקומות שבהם אותו מידע חי במקביל. אם פרטי לקוח קיימים בגיליון, במייל, בהודעה ובראש של עובד אחד, אתם משלמים בכל יום על סנכרון ידני. הסנכרון הזה לא מופיע בשום דוח, אבל הוא נבלע בשעות של אנשים.
שלוש שאלות עוזרות לזהות את זה מהר. האם יש עובד שרק הוא יודע איפה נמצא מידע מסוים. האם הייתה בחצי השנה האחרונה טעות שנבעה מכך שמישהו עבד על גרסה ישנה של קובץ. והאם קורה שאתם עונים ללקוח לא יודע, אבדוק ואחזור, על שאלה שהתשובה לה קיימת אצלכם.
שלוש תשובות חיוביות אינן ראיה שצריך לפתח מערכת, אבל הן ראיה שהתהליך הנוכחי מגיע לגבול היכולת שלו.
שווה להבחין בין שני סוגי כאב שנראים דומים. הראשון הוא כאב של נפח: אותו תהליך פשוט, פשוט הרבה פעמים. את זה פותרים באוטומציה, לפעמים אפילו בלי פיתוח. השני הוא כאב של מורכבות: כמה סוגי משתמשים, הרשאות שונות, מצבים שתלויים זה בזה, וצורך לדעת מה קרה ומתי. את זה כלים גנריים לא פותרים טוב, ושם פיתוח ייעודי מתחיל להיות ההגיוני מבין האפשרויות.
החישוב שמכריע אם זה כבר כואב מספיק
אני מבקש מלקוחות לעשות את התרגיל הזה לפני שאני מציע משהו:
- רשמו את שלושת התהליכים הידניים החוזרים ביותר בעסק. לדוגמה: קליטת פנייה, הפקת הצעת מחיר, תיאום מועד.
- העריכו כמה דקות לוקח כל אחד מהם בפעם אחת, וכמה פעמים הוא קורה בחודש.
- הכפילו, וחלקו ב-60. קיבלתם שעות בחודש.
- הכפילו בעלות שעת העבודה שלכם או של העובד שעושה את זה.
אם התוצאה היא מתחת לחמש שעות בחודש, אל תפתחו כלום. שפרו טפסים, סדרו תיקיות, קנו כלי מדף. אם היא בין חמש לחמש עשרה שעות, אוטומציה חלקית או תוסף ייעודי ישתלמו. אם היא מעל חמש עשרה שעות בחודש והתהליך גם מייצר טעויות מול לקוחות, פיתוח ייעודי מחזיר את עצמו בפרק זמן שאפשר לחשב מראש, ולא באמונה.
אני מוסיף לזה שאלה נוספת שאין לה מספר: מה קורה כשהעסק יגדל פי שניים. תהליך ידני שעובד היום בקושי, לא יעבוד בכלל בכפול.
ויש עלות שנייה שכדאי לרשום בנפרד, כי היא לרוב גדולה מהשעות: עלות הטעויות. הזמנה כפולה, מועד שנשכח, לקוח שקיבל מחיר שגוי, מסמך שנשלח לאדם הלא נכון. כל אחד מאלה עולה זמן תיקון, ולפעמים עולה לקוח. אני מבקש למנות כמה מקרים כאלה היו בשנה האחרונה, בלי לשפוט אף אחד, פשוט כמספר. המספר הזה הוא לרוב מה שמכריע את ההחלטה, לא חישוב השעות.
ארבע משפחות של מערכות שאני בונה בפועל
הרוב המכריע של הבקשות שמגיעות אליי נופלות לאחת מארבע קטגוריות, וזה עוזר להעריך תקציב מוקדם.
מערכות הזמנה ותיאום. יומן, זמינות, אישורים, תזכורות, ניהול נותני שירות. מתאים לקליניקות, לשירותי שטח ולכל עסק שמוכר זמן.
פאנלי משתמשים ואזורים סגורים. הלקוח נכנס ורואה את המסמכים שלו, את הסטטוס שלו, את ההיסטוריה. מוריד עומס אדיר מהטלפון.
אינטגרציות בין מערכות קיימות. חיבור האתר למערכת ניהול הלקוחות, סנכרון מלאי, העברת נתונים בין כלים שכבר יש לכם. לעיתים קרובות זה הפרויקט הזול ביותר עם ההשפעה הגדולה ביותר.
הרחבות ייעודיות לוורדפרס. סוגי תוכן מותאמים, שדות, לוגיקה עסקית שאין לה תוסף מדף. כאן פיתוח מערכות ווב מורכבות יושב על גבי האתר הקיים במקום להחליף אותו.
מה שמשותף לארבע המשפחות הוא שכולן מתחילות מתהליך שכבר קיים בעסק ורץ ידנית. אני לא בונה מערכות לתהליכים שעוד לא הופעלו על אנשים אמיתיים, כי אין ממה לגזור את הדרישות. אם התהליך עדיין לא רץ אצלכם בגיליון, קודם הפעילו אותו בגיליון.
הערה על הבחירה הטכנולוגית. חלק מהמערכות נכון לבנות בתוך וורדפרס, כשהן מחוברות לתוכן ולמשתמשים שכבר שם. חלק נכון לבנות בנפרד ולחבר לאתר, במיוחד כשיש עומס אמיתי או צורך בממשק מהיר. ההחלטה הזו לא נעשית לפי אופנה אלא לפי מי מתחזק אחר כך, ולפי מה שכבר קיים אצלכם.
למי זה פשוט יותר מדי
ארבעה מצבים שבהם אני ממליץ לא לפתח:
- התהליך עדיין משתנה כל חודש. פיתוח מקבע החלטות בקוד. אם עוד לא החלטתם איך העסק עובד, כל שינוי יעלה כסף.
- יש כלי מדף שעושה את רוב מה שצריך. רוב הצורך בשלושה ימי הטמעה עדיף כמעט תמיד על כל הצורך בשלושה חודשי פיתוח.
- המשתמשים הם שניים או שלושה אנשים באותו משרד. במקרה כזה גיליון מסודר עם הרשאות ונוהל עבודה קצר יעשה את העבודה.
- מה שכואב הוא בעצם מכירה. מערכת לא תפתור מחסור בפניות. לפעמים התשובה היא אתר טוב יותר, שעולה החל מ-₪3,800 חד פעמי לפני מע״מ, ולא מערכת.
יש עוד מקרה שאני נתקל בו לא מעט: הצורך האמיתי הוא למכור, לא לנהל. עסק שמבקש מערכת ניהול לקוחות מפני שקשה לו לעקוב אחרי הזמנות, כשמה שבאמת חסר הוא חנות שתקבל את ההזמנות בעצמה, ₪5,800-₪35,000 חד פעמי לפני מע״מ. חנות מנוהלת היטב מייתרת חלק גדול ממה שנראה כמו צורך במערכת, כי היא כבר מכילה מלאי, הזמנות, לקוחות וסטטוסים.
הכלל שאני חוזר עליו: פיתוח ייעודי הוא הפתרון האחרון ברשימה, לא הראשון. הוא הכי יקר, הכי איטי, והכי קשה להחליף אחר כך. הוא גם הפתרון היחיד שמתאים בדיוק לעסק שלכם, וזו הסיבה שהוא קיים.
טבלת החלטה לפי מספר משתמשים ותהליכים
| המצב אצלכם | מה מתאים | סדר גודל של עלות לפני מע״מ |
|---|---|---|
| עד 3 משתמשים, תהליך אחד חוזר | טופס חכם וסידור תהליך, בלי פיתוח | במסגרת האתר הקיים |
| מכירה של מוצרים במחיר קבוע | חנות ולא מערכת | ₪5,800-₪35,000 חד פעמי |
| תהליך אחד כבד, משתמשים פנימיים בלבד | הרחבה ייעודית לוורדפרס | הקצה התחתון של טווח הפיתוח |
| לקוחות חיצוניים נכנסים ורואים מידע אישי | פאנל משתמשים עם הרשאות | הקצה האמצעי |
| שתי מערכות קיימות שצריכות לדבר | אינטגרציית API | משתנה לפי איכות הממשק של הצד השני |
| כמה תהליכים, כמה סוגי משתמשים, דוחות | מערכת מלאה | הקצה העליון, עד ₪80,000 |
למה טווח המחיר כל כך רחב
הטווח של פיתוח מערכות ווב הוא ₪8,000-₪80,000 חד פעמי לפני מע״מ, וההפרש נראה מוזר עד שמבינים ממה הוא נובע. ארבעה גורמים מזיזים אותו יותר מכל דבר אחר.
מספר סוגי המשתמשים. מערכת עם משתמש אחד היא פרויקט אחד. מערכת עם מנהל, עובד ולקוח היא שלוש מערכות שצריכות להסכים ביניהן על מה כל אחד רואה.
איכות הצד השני באינטגרציה. חיבור למערכת עם ממשק מתועד הוא עבודה צפויה. חיבור למערכת ישנה בלי תיעוד הוא מחקר.
מה קורה כשמשהו נכשל. תשלום שלא עבר, קובץ שלא נשמר, הזמנה כפולה. הטיפול במצבי הקצה האלה הוא לרוב שליש מהעבודה, והוא גם מה שמפריד בין מערכת שעובדת לבין מערכת שמפחידים להשתמש בה.
וכמות הנתונים ההיסטוריים שצריך להעביר פנימה מהמצב הקיים. גיליון מסודר עובר בקלות. שלוש גרסאות של אותו גיליון עם שמות דומים ושדות שונים הן פרויקט בפני עצמו, ולפעמים כדאי פשוט להתחיל נקי ולהשאיר את ההיסטוריה לקריאה בלבד.
שני סעיפים נוספים שכדאי לוודא שנמצאים בהצעת המחיר, כי הם משפיעים על העלות הכוללת: תקופת ליווי אחרי העלייה לאוויר, ומה קורה בשנה השנייה. מערכת חיה דורשת תחזוקה בדיוק כמו אתר, והתקציב צריך להכיל את זה מראש ולא כהפתעה.
איך מתחילים בלי לשרוף את כל התקציב
אני כמעט תמיד ממליץ על אותו מסלול. מתחילים באפיון קצר וכתוב שמתאר את התהליכים, את המשתמשים ואת המסכים, בלי לכתוב שורת קוד. האפיון הזה שווה כסף גם אם תלכו לפתח במקום אחר, כי הוא מה שמאפשר לקבל הצעות מחיר שאפשר להשוות ביניהן.
אחר כך בונים את הליבה בלבד: התהליך האחד שכואב הכי הרבה, מקצה לקצה, כולל המצבים שנכשלים. מפעילים אותו חודשיים על אנשים אמיתיים. רק אז מרחיבים.
הסיבה פשוטה. רוב הרשימות שלקוחות מביאים לפגישה הראשונה מכילות תכונות שאיש לא ישתמש בהן, ואי אפשר לדעת מראש אילו. בנייה בשלבים מוצאת אותן בזול.
שלושה דברים שכדאי לסגור בכתב לפני שמתחילים, בלי קשר למי מפתח. הקוד והגישה לשרת שייכים לכם ונמסרים לכם בסיום. יש תיעוד בסיסי שמאפשר למפתח אחר להיכנס לתמונה. ויש הגדרה ברורה של מה נחשב סיום שלב, כדי שהתשלום יהיה קשור לתוצר ולא לתאריך.
ולבסוף, שריינו זמן של אנשים מהצוות. מערכת נכשלת לרוב לא בגלל קוד אלא בגלל שאיש לא נמצא כדי לענות על שאלות במהלך הבנייה ולבדוק את מה שנמסר. שעתיים בשבוע של מישהו שמכיר את התהליך שוות יותר מכל מסמך אפיון.
אני ארתור קלנדרוב, מנהל את הפרויקטים בשיווקנט. אם עשיתם את חישוב השעות ויצא לכם מספר שמפריע לכם, שלחו לי אותו יחד עם תיאור של התהליך האחד שהכי כואב. אני אגיד לכם בכנות אם זה מקרה של מערכת ייעודית, של כלי מדף, או של סידור התהליך בלי פיתוח בכלל. הטלפון 054-238-3789, ואפשר גם בWhatsApp. דברו איתי בוואטסאפ ←
