مسئلهای که در هومص دیدیم
«عیار» را برای ساختن چند اسلاید زیباتر توسعه ندادیم. مسئلهای که در هومص با آن مواجه شدیم، فاصله میان یک فناوری امیدوارکننده و پروندهای بود که بتوان درباره سرمایهگذاری روی آن تصمیم گرفت.
در یک سال، ۳۳۸ پرونده در حوزه هوش مصنوعی صنعتی شناسایی کردیم. از این تعداد، ۲۲۳ مورد وارد بررسی اولیه شدند، ۱۵۹ مورد واقعاً تیم داشتند، ۴۶ مورد چیزی قابل ارزیابی ارائه کردند، ۳۷ تیم به جلسه ارزیابی رسیدند و در نهایت فقط ۸ پرونده وارد بررسی موشکافانه شدند.
من این قیف را نشانه موفقیت در سختگیری نمیدانم. نسبت ۳۳۸ به ۸ برای یک اکوسیستم قابل قبول نیست. معنایش هم این نیست که ۳۳۰ تیم بد بودند. بسیاری از آنها دانش فنی، ایده یا نمونهای آزمایشگاهی داشتند، اما هنوز نتوانسته بودند آن را به پروندهای قابل دفاع تبدیل کنند.
در جلسات ارزیابی معمولاً یک الگو تکرار میشد. تیم درباره فناوری با تسلط حرف میزد و گاهی نمونه محصول هم واقعاً امیدوارکننده بود. اما وقتی سؤالها از «چه ساختهاید؟» به «چه کسبوکاری ساختهاید؟» میرسید، انسجام پرونده از بین میرفت.
مشتری دقیقاً چه کسی است؟ چه کسی از محصول استفاده میکند و چه کسی پول میدهد؟ هزینه ادامه وضع موجود برای مشتری چقدر است؟ تیم دقیقاً چه میزان سرمایه میخواهد؟ این سرمایه کجا مصرف میشود و کسبوکار را به کدام نقطه قابلاندازهگیری میرساند؟ فرضهای درآمد و رشد از کجا آمدهاند؟ ارزشگذاری بر چه مبنایی انجام شده است؟
اینها پرسشهای عجیب یا سختگیرانهای نیستند. هر سرمایهگذار جدی دیر یا زود همین سؤالها را مطرح میکند. مشکل این بود که پاسخها اغلب کلی بودند یا میان پیچدک، فایل مالی، مستندات و توضیحات بنیانگذار با هم نمیخواندند.
مسئله فقط مربوط به ایران نیست
این شکاف را نباید یک ضعف محلی یا مختص استارتاپهای ایرانی دانست. پژوهشهای DocSend درباره نحوه بررسی پیچدکها و راهنماهای Y Combinator برای مراحل Seed و Series A نیز بر یک نکته مشترک تأکید دارند: پیچدک فقط دروازه ورود است.
سرمایهگذار در چند دقیقه نخست تصمیم میگیرد که آیا پرونده ارزش بررسی بیشتر دارد یا نه؛ اما با عبور از این دروازه، دیگر چند اسلاید کافی نیست. تیم باید بتواند شواهد بازار، مدل کسبوکار، صورتهای مالی، برنامه مصرف سرمایه و منطق ارزشگذاری خود را ارائه و از آنها دفاع کند.
بنابراین مشکل جهانی است، اما نسبت ۳۳۸ به ۸ مسئلهای بود که ما نمیتوانستیم فقط دربارهاش حرف بزنیم. از همینجا توسعه عیار شروع شد.
عیار دقیقاً چیست؟
عیار یک دستیار هوشمند برای آمادهسازی و ارزیابی پرونده سرمایهگذاری است؛ دستیاری که در یک سوی مسیر به بنیانگذار کمک میکند کسبوکارش را دقیقتر ببیند و در سوی دیگر، پروندهای منسجمتر و قابلبررسیتر در اختیار سرمایهگذار قرار میدهد.
تأکید روی واژه «دستیار» عمدی است. عیار نه به جای بنیانگذار تصمیم میگیرد و نه به جای سرمایهگذار. قرار نیست با چند سؤال، یک پرونده ناقص را به متنی ظاهراً کامل تبدیل کند. قرار است شکافها را پیدا کند، تناقضها را نشان دهد و تیم را وادار کند برای ادعاهایش عدد، سند و منطق ارائه کند.
عیار یک چتبات عمومی هم نیست که تمام اطلاعات کسبوکار در تاریخچه گفتوگو با آن دفن شود. هسته محصول، یک پرونده ساختیافته و ماندگار است. هر ادعا، عدد، سند، بازخورد و نسخه اصلاحشده باید جای مشخصی در این پرونده داشته باشد و در مراحل بعد دوباره قابل استفاده و بررسی باشد.
این تفاوت از نظر معماری محصول مهم است. اگر همهچیز را به تاریخچه یک چت بسپاریم، بعد از چند رفتوبرگشت معلوم نیست کدام پاسخ نسخه نهایی است، کدام عدد اصلاح شده، چه ادعایی شاهد دارد و کدام تناقض هنوز باز مانده است.
برای همین عیار را حول داده ساختیافته طراحی کردیم، نه حول تولید متن.
چرا عیار ۹ مرحله دارد؟
مسیر اصلی آمادگی سرمایهگذاری در عیار ۹ مرحله دارد:
- معرفی اولیه؛
- هویت کسبوکار؛
- مسئله و محصول؛
- تیم و شواهد؛
- رقبا و ریسکها؛
- بوم مدل کسبوکار؛
- آمادگی مالی؛
- آمادهسازی پیچ؛
- ارزیابی نهایی و تعیین مسیر.
این تقسیمبندی برای زیاد کردن فرمها نیست. هر مرحله بخشی از منطق مرحله بعد را میسازد.
اگر در بخش مسئله گفتهاید خطای وزنکشی کامیونها برای یک معدن هزینه ایجاد میکند، در بخش مشتری باید روشن شود چه کسی این هزینه را تحمل میکند و چه کسی اختیار خرید دارد. در بخش محصول باید نشان دهید راهحل شما دقیقاً کدام بخش از خطا را کم میکند. در بخش شواهد باید داده، قرارداد، آزمایش یا تأییدیهای برای این ادعا وجود داشته باشد. در بخش مالی نیز اثر همان ادعا باید در درآمد، صرفهجویی یا هزینه استقرار دیده شود.
فرم معمولی فقط پر یا خالی بودن خانهها را میبیند. عیار ارتباط میان خانهها را هم میسنجد.
ممکن است تمام فیلدهای یک پرونده پر شده باشند، اما پرونده همچنان قابل دفاع نباشد؛ چون مشتری در یک بخش «معدن» معرفی شده و در بخش دیگر «پیمانکار»، هزینه استقرار در فایل مالی دیده نشده یا وعده محصول با توان اجرایی تیم همخوان نیست.
هدف این است که در پایان مسیر با ۹ جزیره متنی مواجه نباشیم؛ یک روایت بههمپیوسته داشته باشیم که بتوان آن را بررسی کرد.
چرا عیار جای خالی را پر نمیکند؟
یکی از وسوسههای جدی در محصولات مبتنی بر مدلهای زبانی این است که هر ورودی ناقصی را به متنی کامل و روان تبدیل کنند. نتیجه از دور خوب به نظر میرسد، اما در پرونده سرمایهگذاری خطرناک است.
اگر اندازه بازار معلوم نیست، تولید یک عدد تقریبی مشکل را حل نمیکند. اگر مشتری هنوز تأیید نشده، بازنویسی حرفهای او را واقعی نمیکند. اگر تیم داده مالی ندارد، صفر گذاشتن یا ساختن یک پیشبینی نمونه فقط ظاهر پرونده را کامل میکند.
ما در عیار یک اصل ساده داریم:
«نامعلوم» یک وضعیت معتبر است. جای خالی از ادعای ساختگی قابلاعتمادتر است.
سیستم باید بتواند کمبود داده را نشان دهد، سؤال بعدی را پیشنهاد کند و اثر این کمبود را بر آمادگی پرونده توضیح دهد. وظیفه عیار پوشاندن شکاف نیست؛ مرئی کردن آن است.
هوش مصنوعی در عیار چگونه استفاده میشود؟
در عیار همه وظایف را به یک مدل و یک دستور عمومی نسپردهایم. هوش مصنوعی در چند جریان متفاوت استفاده میشود:
- استخراج اطلاعات از پاسخها و فایلها؛
- گفتوگوی سریع و راهنمایی در لحظه؛
- بررسی ارتباط میان ادعاها، اعداد و شواهد؛
- ارزیابی عمیق و دوباره کل پرونده.
دلیل این تفکیک فقط فنی نیست. استخراج یک عدد از فایل مالی با نقد منطق بازار یک کار نیست. پیشنهاد یک نمونه پاسخ کوتاه نیز با کشف تناقض میان چند بخش پرونده تفاوت دارد. هرکدام زمینه، ابزار، سطح دقت و هزینه پردازشی متفاوتی میخواهد.
اگر برای همه این کارها از یک مدل و یک دستور استفاده کنیم، یا پاسخها کند و پرهزینه میشوند یا تحلیل در سطح باقی میماند.
ممکن است کاربر در رابط عیار فقط دکمه «بررسی عیار» یا «گفتوگو با عیار» را ببیند، اما پشت این دکمهها جریانهای متفاوتی اجرا میشوند. این تفکیک به ما اجازه میدهد سرعت، دقت و هزینه را برای هر وظیفه جداگانه کنترل کنیم.
عیار فقط جواب نمیدهد؛ جواب را به چالش میکشد
وقتی کاربر پاسخی ثبت میکند، عیار فقط املا یا روانی متن را بررسی نمیکند. پاسخ به چند جزء شکسته میشود: ادعای اصلی چیست؟ بازیگران چه کسانیاند؟ معیار قابلاندازهگیری کدام است؟ چه شاهدی ارائه شده؟ راهحل فعلی مشتری چیست و چرا کافی نیست؟
اگر نوشتهاید «خطا زیاد است»، عیار میپرسد زیاد یعنی چقدر و نسبت به چه مبنایی. اگر گفتهاید «بازار بزرگی داریم»، روش محاسبه را میخواهد. اگر هزینهای در روایت محصول آمده اما در مدل مالی نیست، تناقض را علامت میزند.
بعد از اصلاح پاسخ نیز ارزیابی باید دوباره انجام شود. قرار نیست یک نمره قدیمی کنار نسخهای تازه باقی بماند.
اینجا مرز مهمی وجود دارد: عیار نباید به جای بنیانگذار ادعا بسازد. میتواند سؤال دقیقتری بپرسد، ایراد را توضیح دهد، ساختار پاسخ را نشان دهد و به فایلهای همان پرونده ارجاع دهد؛ اما مالکیت پاسخ با تیم است.
در جلسه واقعی نیز بنیانگذار باید از عدد و ادعای خود دفاع کند، نه مدل زبانی.
فایلها تزئین پرونده نیستند
یکی از ضعفهای رایج ابزارهای هوش مصنوعی این است که فایل را دریافت میکنند، چند خط از آن را خلاصه میکنند و بعد تقریباً فراموشش میکنند. در عیار، هر فایل باید به یک ادعا و بخش مشخص از پرونده متصل شود.
تصویر محصول، رزومه تیم، قرارداد پایلوت، نامه مشتری و فایل مالی از یک جنس نیستند و نباید یکسان پردازش شوند.
اسناد مالی با فرمتهایی مانند PDF، Excel یا CSV خوانده میشوند تا اعداد و جدولهای اصلی استخراج شوند. شواهد بازار باید به ادعای کشش یا مشتری متصل شوند. تصاویر محصول باید در بخش راهحل دیده شوند و سوابق تیم در ارزیابی توان اجرا اثر بگذارند.
این اتصال یکی از بخشهای دشوار محصول است. سند خوب فقط فایلی نیست که آپلود شده باشد؛ باید معلوم باشد چه چیزی را اثبات میکند و اعتبارش چقدر است.
چرا بخش مالی عیار جداست؟
بیشترین ضعف را در همین قسمت دیده بودیم. تیمها معمولاً میدانستند پول لازم دارند، اما نمیدانستند دقیقاً چقدر، برای چند ماه و برای رسیدن به کدام نقطه.
گاهی مبلغ درخواست سرمایه با برنامه هزینهکرد ارتباطی نداشت. گاهی فروش هر سال با درصدی دلخواه رشد میکرد، هزینهها تقریباً ثابت میماند و ارزشگذاری نیز از مقایسهای دور و نامرتبط گرفته میشد.
کارگاه مالی عیار برای تولید جدولهای بیشتر ساخته نشده است. تیم ابتدا تصویر مالی امروز را روشن میکند و سپس پیشبینی، نقطه سربهسر، ارزشگذاری و روایت مالی پیچ را میسازد.
عیار بررسی میکند که فروش، هزینه، حاشیه سود، رشد، سرمایه درخواستی و نقطه عطف بعدی یک داستان واحد میگویند یا نه.
نمونهای دیگر از اهمیت روش محاسبه در تصمیم مالی را در یادداشت سبدگردانی اشتراکی رمزارز شرح دادهام؛ موضوع آن تقسیم سهم و سود میان سرمایهگذاران است، نه ارزشگذاری استارتاپ.
اینجا نیز سیستم قرار نیست عدد بسازد. اگر دادهای وجود ندارد، باید نامشخص بماند. اگر فرضی خوشبینانه است، باید با همین عنوان دیده شود. اگر دو فایل با هم نمیخوانند، بهتر است تیم پیش از جلسه این تناقض را ببیند تا سرمایهگذار وسط مذاکره آن را کشف نکند.
یک پرونده، چند خروجی
وقتی دادهها ساختیافته باشند، لازم نیست برای هر خروجی دوباره از صفر شروع کنیم. خلاصه یکصفحهای، گذرنامه کسبوکار، روایت پیچ، فایل ارائه و ارزیابی آمادگی میتوانند از یک پرونده واحد ساخته شوند.
اگر عدد فروش اصلاح شود، نباید یک عدد در پیچدک، عددی دیگر در خلاصه پرونده و عدد سوم در فایل مالی باقی بماند.
این موضوع از تولید خودکار اسلاید مهمتر است. ارزش فنی عیار در داشتن یک منبع واحد برای اطلاعات پرونده است؛ جایی که هویت کسبوکار، مسئله، شواهد، مدل مالی و روایت ارائه از هم جدا نیستند.
خروجی ممکن است PDF، پاورپوینت یا صفحه وب باشد، اما پشت همه آنها باید یک پرونده واحد قرار داشته باشد.
عیار برای سرمایهگذار چه تغییری ایجاد میکند؟
تمرکز عیار فقط روی سمت استارتاپ نیست. سرمایهگذار نیز با مسئلهای واقعی روبهرو است: تعداد زیادی پرونده با قالبها، تعاریف و سطوح متفاوت آمادگی.
عیار قرار نیست سرمایهگذار را با یک عدد از خواندن پرونده بینیاز کند. هدف این است که پیش از مصرف زمان انسانی، حداقل اطلاعات موردنیاز مشخص شده باشد، تناقضهای اصلی دیده شوند و معلوم باشد هر ادعا به چه سندی متصل است.
در این صورت سرمایهگذار میتواند زمان خود را بهجای جمعآوری اطلاعات پراکنده، صرف ارزیابی ریسک، گفتوگو با تیم و تصمیمگیری کند.
استاندارد شدن پرونده به معنای یکسان شدن استارتاپها نیست. یک کسبوکار معدنی، یک محصول نرمافزاری سازمانی و یک تیم سختافزاری شواهد و اقتصاد یکسانی ندارند. استاندارد کردن پرونده یعنی سؤالها، ارتباط دادهها و حداقل شواهد روشن باشند؛ نه اینکه پاسخ همه یکی شود.
امتیاز، پایان کار نیست
عیار به بخشهای پرونده امتیاز میدهد، اما قرار نیست با یک عدد بگوید استارتاپ خوب است یا بد. امتیاز باید نشان دهد کدام قسمت پرونده قابل دفاع است و کدام بخش هنوز به کار نیاز دارد.
براساس همین وضعیت، مسیر بعدی پیشنهاد میشود: ادامه راهنمایی، گفتوگو با منتور، آمادگی برای ارائه روی استیج یا ورود به Fast Track برای پروندههای آمادهتر.
این مسیرها کاملاً ماشینی نیستند. هرجا تصمیمی حساس یا دارای اثر واقعی بر دسترسی به سرمایه و رویداد گرفته شود، تأیید انسانی لازم است.
ما هوش مصنوعی را جای داور ننشاندهایم؛ پیش از داور، کنار بنیانگذار گذاشتهایم.
عیار چه چیزی نیست؟
عیار سرمایهگذار نیست و جای منتور یا داور را نمیگیرد. برای استارتاپ مشتری پیدا نمیکند، فناوری ضعیف را به محصول خوب تبدیل نمیکند و جذب سرمایه را تضمین نمیکند.
عیار یک پیچدکساز یککلیکی هم نیست.
ممکن است نتیجه استفاده از آن این باشد که تیم بفهمد هنوز زمان مناسبی برای جذب سرمایه نیست. از نظر من این شکست نیست. جلوگیری از چند ماه مذاکره بینتیجه، هزینهکرد بیهدف و ارزشگذاری خیالی، خودش نتیجه مفیدی است.
عیار قرار نیست پاسخ درست را از بیرون به تیم بدهد. کمک میکند تیم ادعاهای خودش را ببیند، شکافهای پرونده را پیدا کند و برای هر عدد و تصمیم، توضیح قابل دفاعی داشته باشد.
حالا نوبت استفاده واقعی است
عیار از دل ۳۳۸ پرونده و ۳۷ جلسه ارزیابی ساخته شد، اما توسعه آن با همان پروندهها تمام نمیشود.
بخش مهم کار از اینجا به بعد اتفاق میافتد؛ وقتی تیمهای واقعی با دادههای ناقص، فایلهای نامرتب، مدلهای درآمدی متفاوت و سؤالهایی که ما پیشبینی نکردهایم وارد محصول شوند.
قرار نیست ادعا کنیم نسخه فعلی همهچیز را حل کرده است. میخواهیم دقیق ببینیم عیار کجا اشتباه میکند، کجا سؤال اضافه میپرسد، کدام تناقض را نمیبیند و در چه نقطهای مسیر را برای کاربر سخت کردهایم.
اگر در حال ساخت یک کسبوکار فناورانه هستید و میخواهید پیش از جلسه سرمایهگذاری بفهمید پروندهتان کجا محکم است و کجا هنوز به سند، عدد یا فکر بیشتری نیاز دارد، در ayar.hoomas.ai ثبتنام کنید و یک پرونده واقعی بسازید.
بازخورد صریح شما برای تیم فنی ما از تعریف کلی ارزشمندتر است.
در الکامپ و اینوتکس هم منتظرتان هستیم؛ نه فقط برای نمایش محصول، بلکه برای اینکه پروندهتان را باز کنیم، با هم روی سؤالهای سخت آن بایستیم و ببینیم عیار در مواجهه با یک کسبوکار واقعی چقدر عیار دارد.
