דילוג לתוכן

טכנולוגיה, AI ואוטומציה

מתי כדאי לבנות תוכנה מותאמת אישית לעסק?

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

SULTAN INNOVATION GROUP6 דקות קריאה6 פרקים

תוכן המאמר

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

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

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

למה השאלה נעשתה מסובכת יותר

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

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

סימנים שהגיע הזמן לבחון את השאלה

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

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

עיקרון

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

שש שאלות להחלטה

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

  1. האם התהליך הזה מבדל אתכם מהמתחרים? אם מדובר בהנהלת חשבונות, בניהול משכורות או בדיוור, כנראה שלא: כולם עושים את זה בערך אותו דבר, ותוכנת מדף תתאים. אם מדובר בדרך ייחודית שבה אתם מתמחרים, מתכננים או מספקים את השירות, וזו הסיבה שלקוחות בוחרים בכם, ייתכן שכן. השאלה הזאת קשורה ישירות ליתרון תחרותי שלא מבוסס על מחיר.
  2. עד כמה הפתרונות הקיימים קרובים לצורך? בדקו כמה תוכנות מדף ברצינות, כולל ההגדרות וההרחבות שלהן. אם אחת מהן מכסה את רוב הצורך, הפער שנותר הוא לעתים קרובות לא מספיק גדול כדי להצדיק פיתוח מלא.
  3. האם הדרישות יציבות? אם התהליך עדיין משתנה כל כמה חודשים, תוכנה מותאמת תדרוש שינויים מתמשכים. לעתים קרובות עדיף לעבוד קודם בכלי גמיש, ללמוד, ורק אחר כך להחליט.
  4. האם התוכנה הקיימת מקדמת את הצמיחה או מעכבת אותה? זה המבחן המעשי. מאמר דעה שפורסם במגזין Entrepreneur ב־2015, ומופיע במקורות, מציע לתלות את ההחלטה בעיקר בשאלה הזאת. אם הכלים הנוכחיים מייצרים עבודה ידנית שגדלה עם כל לקוח חדש, או מונעים מכם להציע שירות שלקוחות מבקשים, יש כאן סימן.
  5. מי יתחזק את התוכנה בעוד שלוש שנים? אם אין תשובה ברורה, אנשים בתוך העסק או ספק עם הסכם תחזוקה, ההחלטה לבנות מסוכנת.
  6. האם העלות הכוללת לאורך זמן משתלמת? חשבו את העלות של כמה שנים, לא רק של הבנייה. השיטה לחישוב כזה מפורטת במאמר איך מודדים את החזר ההשקעה באוטומציה.

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

ארבע דרכים בין קנייה לבנייה

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

קנייה והגדרה

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

קנייה והרחבה

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

כלים לבנייה בלי קוד או עם מעט קוד

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

שכבה מותאמת מעל מערכות קיימות

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

דוגמה היפותטית

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

מה שנוטים לשכוח: עלות, בעלות ותלות

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

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

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

טעויות נפוצות, ומתי ההנחיות האלה לא מתאימות

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

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

השורה התחתונה

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

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

מקורות

התוכן נועד למידע כללי ואינו מהווה ייעוץ עסקי, פיננסי או משפטי.