בואו נדבר על אופרציה (חלק א')

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

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

אני מגדיר אופרציה ככל מה שקשור לתמיכה "לוגיסטית" בלקוחות משלמים, לאו דווקא באופן ישיר. זה יכול להיות פתיחת רישיונות שימוש וזה יכול להיות גם גיוס כוח אדם. בניגוד למחלקות הפיתוח או הכספים, מחלקת אופרציה בסטארט אפים יכולה ללבוש מגוון צורות, בהתאם לסוג הפעילות המיוחד של הסטארט אפ, ובדרך כלל מנהל הכספים לוקח על עצמו גם את התחום הזה, מסיבות שאסביר בהמשך. באופן כללי, אני לא חושב שיש הגדרה מילונית ל-COO (Chief Operating Officer); קראתי שבפייסבוק למשל שריל סנדברג אחראית פחות או יותר על כל דבר שהוא לא פיתוח, כלומר מכירות, שיווק, פיתוח עסקי, משאבי אנוש ועוד. בחברות אחרות זה לא תמיד כך.

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

1. נהלים זה חשוב

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

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

  1. איש מכירות פותח הזדמנות ב-CRM (במקרה שלנו, Salesforce)
  2. בהסתמך על המוצרים והמחירים שנמצאים בהזדמנות, איש המכירות שולח הצעת מחיר ללקוח.
  3. לקוח מאשר את הצעת המחיר (בקרוב נטמיע מערכת חתימות דיגיטליות בשביל העניין הזה, שתצרף את הצעת המחיר החתומה להזדמנות כ-Attachment)
  4. לאחר קבלת האישור מהלקוח, איש המכירות "שולח את ההזדמנות" להוצאת חשבונית. במילים אחרות, הוא לוחץ על כפתור ששולח את הנתונים של ההזדמנות (פרטי לקוח, המוצרים השונים, מחירים) למערכת הנהלת החשבונות (פריוריטי, במקרה שלנו).
  5. מערכת הנהלת החשבונות יוצרת חשבונית במצב טיוטה.
  6. מנהלת החשבונות "סוגרת" את החשבונית, כלומר משנה את הסטטוס שלה ל"סופי", והמערכת שולחת את החשבונית ללקוח על סמך פרטי הקשר שלו (כן, צריך לדאוג לסנכרון בין מערכת הנהלת החשבונות ל-CRM). אפשר לדלג על השלב הזה ושהמערכת כבר תסגור לבד את החשבונית ותשלח ללקוח. זה תלוי עד כמה אנשי המכירות שלהם מבולגנים.
  7. כעת, רצוי שההזדמנויות ב-CRM יכללו קישור לחשבונית שהופקה בגינן במערכת הנהלת החשבונות. אצלנו יש פרוצדורה לילית שעושה זאת עבור כל החשבוניות שהופקו ביממה האחרונה. מבלי להיכנס יותר מדי לפרטים, יש לנו אובייקט מסוג חשבונית שמזינים אליו את פרטי החשבונית וגם שדה מסוג Lookup שאליו מזינים קישור להזדמנות.
  8. במידה ומדובר במכירה חדשה, כבר במעמד צירוף פרטי החשבונית להזדמנות, נפתח לאחר מכן רישיון שימוש לפי תנאי ההזדמנות / חשבונית והלקוח יכול להתחיל לעבוד. בנוסף לזה, במידה ונפתח רישיון הפרוצדורה יוצרת ב-CRM אובייקט שמקשר בין הזדמנות לבין הרישיון שנפתח בהסתמך עליה (חייבים לעשות זאת באמצעות אובייקט נפרד כי זו הדרך היחידה ליצור קשר מסוג Many to Many), כך שמעגל המכירה והאספקה הושלם, תוך תיעוד מתאים וללא כל מגע יד אדם. לטעמי, זו צריכה להיות השאיפה בכל חברה.

הדוגמה הזו מגלמת בתוכה הרבה אמיתות קטנות בנוגע לעבודת מחלקת האופרציה בסטארט אפ. ראשית, היא קשורה בטבורה למחלקת הכספים. מה לעשות, מה שקשור ללקוחות משלמים לרוב קשור למערכות המידע והתהליכים הללו הם הלחם והחמאה של מנהל כספים טוב. לכן לדעתי, יותר קל למצוא מנהל כספים מיומן שילמד אופרציה מאשר לתת לאיש אופרציה שילמד כספים. אפשר לתת לאיש אופרציה להיות איש הקשר כאשר ניהול הכספים מתנהל במיקור חוץ. שנית, מדובר בהליך שהוא ברובו אוטומטי, מה שהופך אותו ל-scalable – אם הוא עובד טוב על 100 עסקאות, יכול לעבוד טוב גם על 100,000 (ייתכן שיידרשו התאמות מסוימות).

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

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

2. מבנה רישוי / תמחור לא טוב ימנע מכם לצמוח

אם יש דבר אחד שאני מת עליו ב-SaaS זה העובדה שאי אפשר לסבך את זה יותר מדי. כלומר, אפשר, אבל השוק יבעט אתכם החוצה תוך שתי שניות בערך. ב-99% מהמקרים יש 2-5 מסלולים (Plans), לעיתים בתשלום קבוע ולעיתים בתשלום למשתמש, תנאי תשלום חודשיים או שנתיים וזהו זה. נגמר העולם של חברות הסלולר עם "x שקלים עד y דקות שיחה, פלוס z ש"ח לחודש דמי אחזקה, מחולקים ל-24 תשלומי קבועים, לא כולל t ש"ח עבור חבילת גלישה עד u ג'יגה בייט". המעבר לתכניות פשוטות ושקופות הוא מעבר לא קל, בעיקר כי הוא שולל מכם את הבחירה איפה להיות בטרייד אוף שבין אפליית מחירים מושלמת (היכולת לגבות מאדם בדיוק את התועלת שלו מהמוצר, תוך שימוש במגוון טריקים) לבין מכירת מספר מועט של מסלולים במודל low-touch, שהוא הרבה יותר scalable (עוד פעם המילה הזו). לדעתי, בטווח הארוך, אם אין לכם יכולת לנקוב ב-3-5 מסלולים ולתמחר אותם בצורה שתתגמל אתכם, יש לכם בעיות רציניות עם המודל העסקי.

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

דוגמה: נאמר ומשתמש רכש רישיון ל-5 מושבים (Seats, זהו המונח המקצועי ומעתה אשתמש בו), במחיר של $50 למושב לחודש. הוא משלם במועד ההזמנה $250. לאחר שבוע הוא מעוניין להוסיף מושב אחד. הוא ישלם $37.5 שהם יתרת התקופה שנשארה עד מחזור החיוב הבא, ובמחזור החיוב הבא הוא יחויב $300 (6 מושבים כפול $50). עכשיו, נאמר והגיע מועד החיוב ואכן הלקוח חויב ב-$300. לאחר יום הוא מעוניין להפחית שני מושבים כך שגובה הרישיון יהיה 4 מושבים. הוא יכול לעשות זאת, אך הוא לא יקבל כסף בחזרה! המערכת אמורה לזכור שבמועד החיוב הבא עליה להוריד את גודל הרישיון ל-4 מושבים ולחייב אותו ב-$200, בינתיים הוא יכול להשתמש ב-2 המושבים העודפים מכיוון שהוא כבר שילם עליהם מראש, וזהו זה! זה לא משנה אם המסלול הוא חודשי או שנתי, קניית רישיון היא עד הסייקל הבא, בתשלום מראש. כך נוהגות כל חברות ה-SaaS וזו ללא ספק הדרך הטובה ביותר.

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

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

3. אם זה לא אוטומטי, זה יעשה צרות

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

בחזרה לאוטומציה, ועכשיו מגיע החלק החשוב אז תקשיבו טוב: בהתחלה, מחלקת המכירות הולכת להגיע אליכם אחת לשבוע עם עסקה שאי-אפשר "להלביש" על המנגנון האוטומטי. בהנחה שבניתם מנגנון טוב, אסור לכם לאשר אותה. אתם הולכים להגיד ל-VP Sales שיהנדס את העסקה בהתאם ל-policy שמיושם בנוהל האוטומטי. הוא הולך להתעצבן. אתם עדיין לא תאשרו את העסקה. אם המנכ"ל חכם, הוא יצדד בכם ומנהל המכירות ייאלץ להתקפל. התדירות של עסקאות "מחוץ ל-policy" תלך ותקטן עם הזמן. כשמספר הלקוחות יילך ויגדל מבלי להצריך עוד עבודה ידנית, אתם והמנכ"ל תדעו שהצלחתם ויש לכם policy שאפשר לצמוח איתו. הרגע הזה הוא רגע מכונן והוא יסב לכם אושר רב. לפחות כך היה במקרה שלי. זה לא אומר שלא צריך להמשיך ולשפר אותו, כן? למשל, לאחרונה גילינו שהרבה מהשגיאות שמשתמשים מקבלים כאשר הם מנסים לרכוש את המוצר שלנו יכולות היו להימנע אם היינו מציגים הודעות שגיאה אינפורמטיביות יותר.
אני רוצה להדגיש שתי נקודות בתרחיש שתיארתי. האחת, יש כאן הנחה גלומה שהגדרתם policy טוב, שהוא מספיק גמיש כך שאפשר לרוץ איתו בלי גיהוקים, אבל זה דבר שדורש אינטואיציה (שהיא פונקציה של ניסיון כאשר מדובר במערכות סדורות, לפי כהנמן), ולכן ייתכן שתצטרכו לעדכן אותו מספר פעמים עד שיהיה מושלם. הנקודה השנייה היא שחשוב להבין שאנשי המכירות הם רובם ככולם לא אנשים רעים שיש להם אינטרס לבלגן לכם את החיים. יש להם את היעדים שלהם, שנגזרו מהיעדים של החברה, והם כנראה עדיין לא התרגלו לכך שיש שוטר חדש בעיר. לכן, צריך לנהל את החיכוכים הללו בחוכמה ותוך וידוא שיש לכם גיבוי מלא מהמנכ"ל שלכם. בסוף כולם יהיו מרוצים יותר.

סיכום ביניים

וואו, יותר מ-1,900 מילים ויש לי עוד הרבה בקנה. נעצור כאן ונמשיך בפוסט הבא, בוא אגע בכלים שיכולים לסייע לכם באוטומציה של תהליכים והשגת Quick Wins שייתנו לכם רוח גבית בדרככם ליצור Unicorn שמעסיקה ארבעה עובדים ;)

נ.ב – השקתי ניוזלטר

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

10 תגובות כתיבת תגובה

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

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

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

    • אהלן,
      אני אתחיל באיך זה עובד אצלנו ואז אמשיך לפיתרון שאני חושב שצריך להטמיע אצלכם.
      אצלנו, לטוב ולרע (בעיקר לרע), דין הזדמנות הוא דין חשבונית, ולכן הזדמנות שהיא Closed Won צריכה לצאת עליה חשבונית עם בדיוק אותם פריטים. בגלל שלפריוריטי אין API (אגב, זה מתוך אידאולוגיה של חסור פתיחות ויזמים מתחילים צריכים לקחת זאת בחשבון לפני שהם בוחרים מערכת ERP), מה שקורה זה ששמנו כפתור בדף ההזדמנות שכאשר לוחצים עליו הוא מפעיל קוד שיוצר קובץ CSV עם פרטי החשבונית (מספר לקוח בפריוריטי, תנאי תשלום, ת.ז של ההזדמנות וכו') וכן שורה עבור כל שורת מוצר (מק"ט, מחיר לפני הנחה, הנחה וכו'). קובץ ה-CSV הזה נשמר במקום מוגדר מראש, וישנה פרוצדורה בפריוריטי שרצה כל חצי שעה, אוספת את כל קבצי ה-CSV ופותחת חשבוניות במצב טיוטה (אם יש שגיאה מוציאה דוח שגיאות). שאר התהליך כבר תואר בפוסט.
      במקרה של Quickbooks אני יודע בוודאות שיש API מאוד נוח, ולמעשה יש לך שתי דרכים להשתמש בו. הדרך הראשונה היא לבנות כפתור שישלח בקשת POST ל-QB עם פרטי החשבונית העתידית, לקבל מ-QB את פרטי החשבונית שנוצרה ולצרף אותם להזדמנות. הדרך השנייה היא באמצעות Zapier, שהוא שירות שמקשר בין שירותי ענן. הדרך שבה זה עובד היא "ברגע שמשהו קורה בשירות x אז תעשה משהו בשירות y". יש להם ממשק די נוח ואני מכיר כמה לקוחות שלנו שחיברו את המערכת שלנו ל-QB באמצעותם. במקרה שלך זה יכול להיות משהו בסגנון של "ברגע שמצורף חוזה חתום לחוזה, פתח חשבונית ב-QB ושמור את פרטי החשבונית בהזדמנות המתאימה".
      בכל אופן, לחבר את SFDC ל-QB אמור להיות נושא די פתור בשנת 2016 – שניהם שירותי ענן מאוד ליברליים.
      לגבי הכרה בהכנסה מה שעשינו זה שהוספנו לכל מוצר פרמטר של "נדחה" או "לא נדחה". ברגע שיוצאת חשבונית, הסכום בגין מוצרים לא נדחים עובר לחשבון ההכנסות והסכום בגין מוצרים נדחים עובר לחשבון הכנסות נדחות. מאחר ואצלנו מכירים בהכנסות על פני 12 חודשים, כשהסכום עובר לחשבון הכנסות נדחות, הוא עובר יחד עם 12 פעולות יומן עתידיות של הפשרה לחשבון ההכנסות הנכון. זה יוצר טיפהלה בלאגן בחישובי המעמ אבל יש לי מנהלת חשבונות תותחית אז הצלחנו להסתדר. במקרים שבהם ההכרה בהכנסה מבוססת על שימושים אני חושב שלא יהיה מנוס מלבנות פרוצדורה חודשית שמתממשקת לדטהבייס הכולל שימושים של הלקוחות, יודעת לקשור אותם את השימושים לחשבוניות שיצאו ולכן יודעת גם כמה צריך להפשיר לחשבון ההכנסות. מאמין שאם תבנה אבטיפוס טוב בעזרת Power Query תוכל להשתמש בו כבסיס לאפיון של המערכת האמיתית.

      ערן

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

    אשמח להרחבות בפוסט הבא בנושא!

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

      ערן

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

  6. כמה זמן חיפשתי כתבה כזו…
    פשוט מעולה!!
    ערן, יש אפשרות להתייעץ איתך בנושא קטן בפרטי? אם כן, אשמח שתשלח לי מייל. (מצרפת כאן)
    ממשיכה לעקוב!!

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

      ערן

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *