תגידו מה עדיף להזמין פיצה במשלוח, לאכול במסעדה או להכין בעצמנו בבית?
האמת שאם תשאלו אותי אימא שלי מכינה את הפיצה שאני הכי אוהב, משהו באותנטיות, בטעם הביתי הזה, בפשטות וחוסר הדיוק תמיד מנצח כל פיצה של מסעדה אחרת בעיני. ברור שיש פיצות יותר מפונפנות, יש פיצות עם תוספות מטורללות (טעמתי השבוע פיצה חריימה ופיצה פולנטה מעולות), יש כאלה שמגיעות תוך דקות ספורות בלבד כמעט ללא המתנה, ויש כאלה ממש זולות שזה נראה לא משתלם להכין בבית. אז מה עדיף?
מה שנכון לגבי פיצה נכון גם לגבי קיש לורן בעל 17 שלבים ושלוש שעות של עבודה? ומה לגבי סושי, האם אבקש מאימא שלי לדוג סלמון נחלים מיפן?
איך זה קשור לניהול מוצר?
שאלות דומות לאלה אני שואל כשאני מגיע לעבוד בעצמי או לייעץ על מוצר, שירות או מערכת חדשים, האם לפתח בעצמנו או לרכוש?
האמת שרוב ה-CTOים שפגשתי יעדיפו לפתח מאשר לרכוש. הנה כמה סיבות עיקריות:
חשש להכניס קוד לא מוכר ולא גמיש
עלות מערכת המדף יכולה לאיים
באגים אפשריים במערכת מדף שלא בשליטטינו
חשש נוסף ומהותי - אם אני מכניס מערכת לארגון שלא אני פיתחתי, מה זה אומר על גוף הפיתוח שלי?
אני מבטיח לענות על שאלות אלה בסוף, אבל דווקא בואו נתחיל מההתחלה.
ב 20 שנות קריירה בניהול מוצר, אפיון וניתוח מערכות ואסטרטגיה וכיועץ עצמאי בשנים האחרונות, פגשתי עשרות לקוחות, מאות מערכות ודרישות וגיבשתי מחשבה "לא עשינו את זה כבר?" או "כבר עשינו כמה פעמים משהו ממש דומה לזה במקום אחר?".
אז אני רוצה להציע את המחשבה הזו:
כ 80-90% ממערכות העולם מבוססות על אותם שני סוגי פתרונות ופלטפורמות (השאר באמת דורשות פתרון יחודי).
אני מקבץ אותן לשתי אלה:
פלטפורמות לניהול תוכן ומידע - Content Management System (בקיצור CMS)
פלטפורמות לניהול קטלוג ותהליכי מכירה (eCommerce CMS)
כאן הקסם קורה ומיד,
שתי סוגי מערכות אלה מגיעות באופן מובנה היכולות ה"בסיסיות" הבאות:
יכולת ניהול משתמשים: רישום משתמשים פנימיים, ניהול הרשאות, הגדרת פרופילים ניהול סיסמאות, 2FA.
יכולת ניהול לקוחות: רישום לקוחות חדשים, ניהול הרשאות, הגדרת פרופילים, ניהול סיסמאות, 2FA.
מערכות White Label יכולות להראות בדיוק כפי שתרצו ללא סממנים של ספק התוכנה, עם הגדרת עיצוב מלאה וקסטומיזציה גמישה במיוחד.
ממשקי API להזנה ומשיכה של מידע.
תמיכה ברספונסיביות Webית.
יכולות דיווח והפקת דוחות, אנליזה בסיסית.
תמיכה בריבוי שפות וריבוי Cultures (כמו תאריכים, סימנים ומטבעות).
מהי יודעות לעשות מרבית מערכות ה CMS:
מסכי הזנה:
ניהול דפי מידע מרובים.
ניהול גרסאות מידע.
ניהול קטגוריות, שיוך דפים לקטגוריות.
ניהול תגיות / תיוג ידני ואוטומטי.
ניהול הרשאות ברמת קטגוריה ועד רמת הדף
מסכי צפיה:
יכולת חיפוש מסמכים באופן גמיש לפי שם, קטגוריה או תגית.
יכולת ביצוע פעולות: לייק, Comment, Share
יכולת תרומת מידע (כמו ב Wikipedia)
יכולת מעקב אחרי שינויים.
יכולת ניהול שיחה על גבי המסמך (Forum)
יכולת יצוא המידע באופנים שונים.
מערכות מוכרות מהסוג הזה:
מערכת Umbraco - שהיא המומלצת ביותר בעיני, חברת Tectu הישראלית ביצעה בעבר כמה קסטומיזציות מרשימות במיוחד.
מערכת Strapi - השניה הכי מומלצת
פלטפורמת MediaWiki (שעליה בנו אלפי מערכות ואתרים, ביניהם וויקיפדיה) - חינמית לחלוטין
מערכת Zoho Wiki
מערכת Guru Wiki
מערכת Slite - היפייפיה
מערכת Zendesk Docs - יקרה יחסית אך מעולה ומיידית.
מערכת Stonly
מערכות ניהול קטלוג, תהליכי מכירה וחנויות:
ניהול הגדרת המערכת
ניהול קטלוג מוצרים
ניהול קטלוג מחירים
ניהול קטלוג מבצעים
ניהול הזמנות
ניהול הזמנות
ניהול הזמנות דיגיטליות על ידי הלקוח
יכולת ניהול חנות פיזית
מנוע חיפוש מוצרים גמיש
ניהול משלוחים
ניהול התחשבנות והפקת חשבוניות
ניהול תהליך האספקה
מנוע המלצות.
מערכות מוכרות מהסוג הזה:
מערכת WIX
מערכת Shopify
מערכת Magento
מערכת WooCommerce
מערכת BigCommerce
אז איך אני ממליץ מקבל את החלטה?
אלו המקרים שהייתי ממליץ על מערכת מדף הם:
דרוש פתרון מיידי
אין משאב פיתוח רלוונטי פנוי לנושא, שימוש במשאב הפנים חברתי עלול להוציא אותם מהפוקוס המוצרי
דרושה גמישות ומוכנות לפיצ'רים עתידיים
לא דרושה תחזוקה
חיבוריות גבוהה מיידית עם מערכות נוספות Plug&Play
חלק מהמערכות ה SaaS אז לא דרושה התקנה, וחלק הן Open Source שדורשות התקנה פשוטה יחסית.
אלו המקרים שלא הייתי ממליץ על מערכת מדף:
כשהמוצר/שירות עושה פעולה ספציפית שנוגעת ל IP הארגוני: למשל דרושה לכם מערכת שמחשבת מסלולי נסיעה עבור שליחים - יש מערכות מוכנות כאלה אך CMS לרוב לא תומכות. המערכת שלהם עושה סריקות רנטגן לחיות (יש מערכת כזאת) - זהו פתרון יחודי מהותי.
כשהארגון שלכם צריך לנהל למידע, קורסים דיגיטלית ולאפשר למידע - - יש מערכות מוכנות כאלה אך CMS לרוב לא תומכות. מערכות יות מתאימות יהיו כמו edX ודומות.
מערכות ניהול פניות / ניהול רשימות - יש מערכות מוכנות כאלה אך CMS לרוב לא תומכות, כמו Monday, Zendesk וכו'.
להלן מספר דוגמאות אמיתיות לצרכים שעלו וקבלת ההחלטה:
כשאני פוגש ארגון שמבקש לפתח מערכת, מוצר או שירות חדש, אני מנסה לרגע לשקול את אחת מסוגי מערכות אלה.
מקרה ראשון: ארגון שעוסק במכירת רכבים שרוצה לארגן את הנהלים והמידע הפנים ארגוני על הדגמים השונים, על תקלות שירות, על מחירים, הסברים שונים לנציגי המכירות והשירות - האם כדאי לנו לפתח מערכת ניהול ידע ארגונית? התשובה שלי: בסבירות גבוהה כדאי להשתמש במערכת מדף, נהול ידע מסוג זה באופן גמיש ניתן למימוש מיידי באמצעות מערכת CMS. חלק מהמידע יהיה זמין גם ללקוחות וכלל המידע יהיה זמין לכלל העובדים לאחר הזדהות.
מקרה שני: ארגון שמוכר קורסים דיגיטליים, רוצה לפתח פתרון שמאפשר לנהל קטלוג הקורסים, כך משתמשים יכולו לחפש ולמצוא את הקורס (או כל שירות אחר) הרלוונטי, לצפות בדף המידע משלו, מחירונים, מבצעים, ויכולת ביצוע התשלום בעצמם. (מערכת הלמידה היא מערכת אחרת) התשובה שלי: בסבירות גבוהה לא כדאי, ניהול ידע מסוג זה באופן גמיש ניתן למימוש מיידי באמצעות מערכת eCommerce CMS. ההטמעה היא מיידית או פשוטה למדי. תוכלו לטעון את הקורסים שלכם ולהתחיל במכירה שלהם באופן כמעט מיידי.
מקרה שלישי: אדם פרטי או עסק קטן שמוכר מוצר פיזי כמו תכשיט, פגישת ייעוץ תזונה, או ספר. יש צורך להעלות את המוצר/שירות היחיד שלנו או מרובים, לנהל מחירים, לנהל הזמנות, לנהל אספקות ומשלוחים, לפרסם את הלינק באתרים השונים. התשובה שלי: בסבירות גבוהה לא כדאי, כמעט כל מערכות eCommerce CMS שיכולות לטעון את קטלוג המידע שלכם ולהתחיל במכירה כמעט מיידית, הם
מקרה רביעי: ארגון בעל מוצר יחודי ומדהים במערכת שפותחו בבית וצוות הפיתוח היה רוצה להשקיע את כל המאמצים על מערכת זאת, עולה צורך באתר שיווקי שיוכל להציג את דפי התדמית שלנו, השירותים שלנו משתנים במהירות ולכן דרושה לנו גמישות ודינאמיות, העיצוב צריך להראות ב Look & Feel של הארגון, וצריכה להיות אפשרות לפנות בטלפון, מייל, לפתוח פניה באתר. התשובה שלי: בסבירות גבוהה כדאי להשתמש במערכת מדף , מערכות CMS יכולות להעלות אתר תדמיתי מלא באופן כמעט מיידי ולבצע את כל הפעולות שאותם הצגתם.
לסיכום:
מוצר מעולה לא חייב להיות מבוסס על טכנולוגיה פורצת דרך, מוצר מעולה הוא מוצר שמביא ערך מעולה למשתמשים. במדינת הסטארט-אפ אני מכיר מקרים מדהימים שבהם השתמשו בהטמעה של WordPress לניהול חנות המוצרים שמכרה במיליונים ולאחר מכן גם החברה נמכרה במיליונים רבים. כי המוצרים שנמכרו בחנות היו בעלי ערך רב ופלטפורמה (הטכנולוגיה) שעליה התבססה החנות היתה לא מהותית.
פיתוח הוא אפשרות, כלי ולא מטרה לפתח בעצמינו הוא אופציה. אנחנו לא מפתחים כי אפשר, אנחנו מפתחים כי צריך. כשלא מדובר על ה IP המוצרי - אם ניתן שלא לפתח עדיף שלא לפתח. אם השירות הוא לא המהות המוצרית שלכם (למשל האופן בו משתמשים יפנו לתמיכה) זה רמז גדול לכך שאנחנו לא בכיוון.
מערכות המדף מאפשרות שימוש מיידי, חלקן SaaS וחלקן דורשות התנה, חלקן חינמיות לחלוטין והיקרה ביותר שמצאתי היא בעלות של כ 45$ למשתמש (לא לקוח) לחודש. עלות זולה בהרבה מרוב הפיתוחים שנבצע בעצמנו. תתחילו איתן, תתנסו בהם, תלמדו מהם, אפילו תעתיקו מהן. רק אל תתחילו עם פיתוח כשלב ראשון לבחינת מהות ערכו של המוצר.
השוואה בין פיתוח לעומת מערכת מדף - תבחנו את כל הסעיפים בדרושים מעבר לפיתוח עצמו: שרתים ואחסון, תחזוקה, תמיכה, סייבר ואבטחה, יכולות עתידיות, שדרוג גרסאות.
ומילה ל CTOים
90% מחברות ה-IT בישראל קורסות תוך 3 שנים, ו-70% מהקוד בעולם נזרק לפח ללא שימוש. האם לא עדיף להביא ערך בזמן הקצר ביותר האפשרי?
התפקיד של מנהלי המוצר הוא לקבל החלטות עסקיות מורכבות, ולא רק "להאכיל באיפיונים". ההטמעה והתחזוקה של מערכת מדף הן לרוב באחריות גוף הפיתוח, ואנשי המוצר יגדירו צרכים ויסייעו בבחירת המערכת.
התנגדות לגיטימית למערכת מדף יכולה להיות בעיות אבטחה, תמיכת סייבר לא מספקת, חוסר גמישות בקוד, ו-Performance.
התנגדות פחות לגיטימית למערכת מדף יכולה להיות: "אם נרכוש מערכת אז מה יעשו המפתחים", או "אנחנו יודעים לפתח את זה, למה לרכוש?" אנחנו מפתחים כי צריך ולא כי אפשר, התשובה היא שברוב המקרים זול יותר לרכוש מערכת מדף ולרוב לא דורשה יותר קסטומיזציה ממה שמאפשרים כלי המדף.
בואו נוודא שאנחנו מביאים את הערך הטוב ביותר לארגון בזמן הקצר ביותר האפשרי. CTO שמדלוור הוא CTO מצוין, לא רק כזה שמייצר מכונת פיתוח משומנת. מסכימים?
בואו נחליט יחד מהו ה-IP המוצרי שמחייב פיתוח פנימי ונבחן יחד מערכות משלימות שעדיף לרכוש ולהשתמש בהן מיידית.
וככה יהיה לנו יותר זמן לאכול עוד פיצה :-)
コメント