Cash Flow Playground: המודל שעונה על 'מה יקרה למזומן שלנו אם...' תוך שניות

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

זה בדיוק מה ש-playground של תזרים מזומנים נותן.

מה זה playground, ולמה כל CEO רוצה אחד

חשוב להבחין: תחזית תזרים היא לא דבר אחד. יש את ה-13-week cash flow לניהול נזילות שוטף. יש תחזית חודשית. יש direct מול indirect method. וכל אחד מהם משתנה לפי סוג העסק - SaaS, ייצור, שירותים, שלב מוקדם מול Enterprise.

ה-playground הוא סוג אחר לגמרי. הוא לא התחזית הרשמית, לא ה-13-week לטרეז'רי - הוא סנדבוקס. כל הוצאה עתידית נראית לעין, כל שורה ניתנת לעריכה, וה-free cash flow החודשי, תחזית סוף השנה, ויתרת המזומן מחושבים מחדש בזמן אמת תוך כדי משחק.

הדגמה חיה - עריכת שורת הוצאה, ויתרת המזומן מתעדכנת תוך כדי הקלדה:

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

איך זה עובד: 4 שלבים, והשני הוא הסיפור האמיתי

1. קלט. P&L היסטורי חודשי, רשימת שכר, הוצאות תוכנה, רשימת לקוחות עם תדירות חיוב וימי גבייה לכל לקוח, והנחות התחזית. שום דבר לא מומצא - אם משהו חסר, הוא שואל.

2. שער איכות נתונים. לפני שבונים כלום, בודקים שה-P&L מסתכם נכון, שמפל ה-MRR מאוזן, שהמזומן מתאזן ל-0, ושה-AR וההכנסה הדחויה מתגלגלים כמו שצריך. נכשל? שואלים. לעולם לא מרמים. זה הסעיף הכי חשוב בכל התהליך - למי שבונה בעצמו, זה הכלל שהכי משתלם להעתיק: הגורם שמבצע את המשימה לא מקבל לזייף את הקלט של עצמו.

3. בנייה. קובץ עצמאי אחד, שישה טאבים מקושרים: P&L Playground, תוכנה, שכר, MRR פעיל, תזרים נכנס, תזרים מזומנים. בפועל (actuals) נעול, תוכנית ניתנת לעריכה, נוסחאות תמיד מחושבות מחדש.

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

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

הכללים שאפויים בפנים

זה מה שהופך מודל פיננסי מיפה למהימן: actuals נעולים (עריכות נוגעות רק בחודשי תוכנית), הוצאות שומרות סימן (מינוס שהוקלד לא הופך עלות להכנסה בטעות), מזומן שונה מרווח נקי (AR והכנסה דחויה נעקבים כמו שצריך, לא cumsum נאיבי), ומפל MRR חייב להתאזן (סה"כ = קודם + לקוחות חדשים + upsell + downsell + churn).

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

איך מגדירים את זה (5 דקות)

זה Claude skill - מתקינים פעם אחת, ואז פשוט מבקשים מ-Claude לבנות או לעדכן playground.

מה צריך: תוכנית Claude עם Code execution and file creation דלוק. בלי זה, skills לא רצים.

בגרסת ה-web / desktop / Cowork:

1. להדליק code execution: Settings ← Capabilities ← Code execution and file creation
2. לגשת ל-Customize ← Skills
3. ליצור או להעלות skill מותאם לתהליך הזה
4. להפעיל אותו

אחר כך, בצ'אט חדש: "בנה לי cash flow playground מהמספרים האלה" - ומצרפים P&L, שכר, הוצאות תוכנה, ורשימת לקוחות (תדירות חיוב + ממוצע ימי גבייה לכל לקוח).

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

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

הצעד הבא

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