وقتی مدل مالی یک شرکت نرم‌افزاری را می‌سازید، مهم‌ترین تصمیم نه فرمول‌ها که چیدمان مدل است. اینکه چند تب دارید، هر تب چه کاری می‌کند و اطلاعات از کجا به کجا می‌رود، تعیین می‌کند مدل شما قابل‌اعتماد و قابل‌استفاده باشد یا یک هزارتوی غیرقابل‌ممیزی. در این نوشته یک چیدمان نمونه برای مدل مالی SaaS را مرور می‌کنیم.
چرا چیدمان از فرمول مهم‌تر است؟
مدل‌های ساختارمند معمولاً شبیه هم‌اند: ورودی، محاسبه و خروجی. این ساختار تقریباً در هر صنعتی کار می‌کند. تفاوت مدل نرم‌افزاری با مدل یک شرکت تولیدی دو چیز است:
- محرک‌های درآمد و هزینه‌ی سفارشی (مثل قرارداد، قیمت، ریزش مشتری و ظرفیت فروش) که باز هم به همان سه صورت مالی وصل می‌شوند.
- درک حساب «درآمد معوق» در ترازنامه که از تفاوت زمان صورت‌حساب و زمان شناسایی درآمد پدید می‌آید. اگر با آن آشنا نیستید، مدل مالی SaaS و شناسایی درآمد نقطه‌ی شروع خوبی است.
مدلی را که در این نوشته توصیف می‌کنیم، حدود ۱۱ تب دارد، اما بیشتر آن را می‌توان از یک تب کنترل کرد.
تب خلاصه و مفروضات؛ مرکز فرماندهی
ایده این است که کل مدل از یک نقطه قابل کنترل باشد. به همین دلیل خلاصه و مفروضات را کنار هم می‌گذاریم: سمت راست ورودی‌ها (با رنگ مخصوص ورودی) و سمت چپ خلاصه‌ی نتایج.
در روش کلاسیک، یک صفحه‌ی جدا برای مفروضات دارید. هر بار ورودی را عوض می‌کنید، باید بین تب‌ها بگردید تا ببینید اثرش درست آمده یا نه و بعد به خلاصه برگردید و تفاوت را «با چشم» حدس بزنید. در چیدمان کنار هم، اثر هر تغییر را فوراً می‌بینید و آزمون فشار مدل هم بسیار ساده‌تر می‌شود.
یک گام بالاتر هم هست: بخشی برای «حالت کنترل». نتیجه‌ی یک سناریوی مرجع را در آن کپی می‌کنید و سپس هر تغییر را با آن مقایسه می‌کنید. ستون واریانس هر خط را نشان می‌دهد و هم‌زمان ابزاری برای اطمینان از درستی مدل است. برای ساخت چنین سازوکاری، مدل مالی پویا با بلوک‌های سناریو را ببینید.
جریان اطلاعات؛ یک حلقه
اطلاعات در این مدل در یک حلقه می‌چرخد:
- از خلاصه و مفروضات به نیروی انسانی: مفروضات حقوق، افزایش سالانه، پاداش و مانند آن.
- از خلاصه و مفروضات به تب ساخت SaaS: قیمت قرارداد، نحوه‌ی صورت‌حساب، ریزش مشتری، ترافیک وب‌سایت، ظرفیت فروش.
- از خلاصه و مفروضات به مدل عملیاتی: سایر هزینه‌ها و فرض‌های ترازنامه.
سپس خروجی تب‌های میانی دوباره به مدل عملیاتی برمی‌گردد:
- داده‌های واقعی تاریخی از فهرست حساب‌ها سابقه‌ی مدل را پر می‌کند.
- محاسبات نیروی انسانی، حقوق، پاداش و مالیات حقوق را به مدل می‌دهد.
- تب ساخت SaaS درآمد، مبالغ صورت‌حساب‌شده و درآمد معوق را تأمین می‌کند.
زیبایی مدل‌سازی سه‌صورتی همین‌جاست: ساختار مدل صرف‌نظر از صنعت و اندازه‌ی شرکت یکی است. محرک‌های سفارشی درآمد و هزینه به همان قالب سه‌صورتی وارد می‌شوند و جریان نقد هم با روش غیرمستقیم محاسبه می‌شود، دقیقاً مثل یک شرکت دارای موجودی کالا. اگر در این بخش تردید دارید، خطای شماره یک در مدل سه صورت مالی را بخوانید.
تحلیل کوهورت
تحلیل کوهورت یک خروجی است و نه یک بخش محاسباتی جدا. مشتریان را بر اساس ماه ثبت‌نامشان گروه‌بندی می‌کنید و ماندگاری هر گروه را در طول زمان پی می‌گیرید. معمولاً در ماه دوازدهم، یعنی زمان تمدید قرارداد سالانه، افتی در تعداد مشتریان می‌بینید؛ چون بعضی مشتریان تصمیم می‌گیرند تمدید نکنند. دیدن این الگو برای پیش‌بینی ریزش و تنظیم مفروضات بسیار مفید است.
خلاصه‌ی اجرایی
علی‌رغم همه‌ی جزئیات ماهانه، مدیران عامل «نمای ۵۰ هزار فوتی» می‌خواهند. در خلاصه‌ی اجرایی فقط مهم‌ترین اقلام را به صورت سالانه نشان می‌دهید و همان سه بخش را می‌گذارید:
- سناریوی جاری
- سناریوی کنترل
- واریانس بین آن دو
اگر مدیر بپرسد «اگر فلان کار را بکنیم چه می‌شود؟»، پاسخی بصری و فوری دارید.
تب‌های پشتیبان
باقی مدل کارکرد پشتیبانی دارد:
- سلب مسئولیت: توضیحات و محدودیت‌های مدل.
- نقشه‌ی مدل: تصویر کلی تب‌ها و ارتباطشان.
- کنترل خطا: بررسی می‌کند چه چیزی ممکن است در فایل غلط باشد.
- فهرست‌ها: برچسب‌گذاری اقلام برای نگاشت آسان بین تب‌ها.
پرسش‌های متداول
چرا مفروضات و خلاصه را در یک صفحه آوردیم؟
چون اثر هر تغییر مفروضات را بلافاصله می‌بینید و نیازی نیست بین صفحه‌ها بپرید. این روش آزمایش مدل را سریع‌تر و دقیق‌تر می‌کند.
آیا ۱۱ تب برای همه‌ی شرکت‌ها لازم است؟
نه. تعداد تب‌ها بستگی به پیچیدگی دارد. نکته‌ی اصلی جدا کردن ورودی، محاسبه و خروجی است، نه تعداد دقیق تب‌ها.
کنترل خطا دقیقاً چه چیزی را بررسی می‌کند؟
معمولاً چند آزمون ساده: برابری دارایی‌ها با بدهی‌ها و حقوق صاحبان سهام، تطابق مانده‌ی نقد در صورت جریان وجوه نقد و ترازنامه، و نبود مقادیر عجیب در ورودی‌ها.
تحلیل کوهورت برای شرکت‌های غیرنرم‌افزاری هم مفید است؟
بله. هر کسب‌وکار اشتراکی یا تکرارشونده، مثل باشگاه ورزشی یا خدمات دوره‌ای، می‌تواند از آن استفاده کند.
جمع‌بندی
یک مدل SaaS خوب با چیدمان خوب شروع می‌شود: یک مرکز کنترل برای مفروضات و خلاصه، تب‌های محاسباتی که به هم وصل‌اند، حلقه‌ی روشن اطلاعات و خروجی‌هایی مثل کوهورت و خلاصه‌ی اجرایی. اگر این ساختار را درست بچینید، حتی مدل بزرگ هم برای مدیران قابل‌فهم و برای شما قابل‌ممیزی می‌ماند.