دِک استراتژی توصیف میکند که قصد داری به کجا بروی. سیستم عملیاتی تعیین میکند که هر روز، قدمِ بعدی واقعاً چه باشد، چه کسی به استراتژی فکر کند چه نکند. وقتی این دو با هم نمیخوانند، سیستم عملیاتی میبرد. همیشه میبرد.
کل اصل همین است. بیشترِ چیزی که شبیه مسئلهٔ استراتژی به نظر میرسد، در اصل این است که هیچکس نمیتواند بلند بگوید یک استعلام سهشنبه بعدازظهر چه سرنوشتی پیدا میکند.
Shalize واقعاً چه بود
Shalize کسبوکاری فیزیکی در طلا و نقره بود که روی پیامهای واتساپ، حافظه و اعتماد میچرخید. این را به انتقاد نمیگویم. کار میکرد، تا روزی که دیگر نکرد. حجم کار زودتر از آنچه فرایند تاب بیاورد بالا میرفت، و این دقیقاً همان شکلِ شکستِ کسبوکارهایی است که روی آدمهای خوب ساخته شدهاند: آدمها مشکلی ندارند، بار مشکل دارد.
بهجای استراتژی تازه، سیستم عملیاتی را سر تا ته از نو ساختیم: استعلام، سفارش، صدور فاکتور، تأیید پرداخت، ارسال، پیگیری و بازخرید، و زیرش یک CRM. هفت قدم. هر کدام با اسم. هر کدام با یک صاحب. هر کدام با تعریفی از اینکه «انجامشده» یعنی چه، تا دو نفر نتوانند هر دو خیال کنند پرداخت تأیید شده و هر دو منتظرِ دیگری بمانند.
حجم روزانه از ۰٫۵ به ۱۰ کیلوگرم در روز رسید. بیش از ۴٬۰۰۰ مشتری خریدارِ تأییدشده. اینجا میخواهم محتاط باشم: رقمهای پولیای که گروه گزارش میکند ارزش ناخالص معاملاتاند و خودِ شرکت گزارششان کرده؛ حسابرسی نشدهاند، درآمد نیستند و حاشیهٔ سود خالص هم نیستند. هر رقم روی این سایت میگوید از کجا آمده و آیا حسابرسی شده یا نه، و بیشترشان نشدهاند. گفتنش هزینهای ندارد.
چیزی که بیاما و اگر ادعایش میکنم سازوکار است. حجم به این خاطر بالا نرفت که استدلالِ بهتری پیدا کردیم. بالا رفت چون فرایند دیگر چیزی را گم نمیکرد.
راهاندازیِ واقعی وبسایت نبود
بخشی که آدمها دستکم میگیرند این است که چه کسی باید عوض شود. در Shalize فروش باید دست از کار با حافظه برمیداشت. راهاندازیِ واقعی همین بود: جاافتادنِ CRM، و آنلاین شدنِ یک صفحه در درجهٔ بعد. کسی که سالها معامله را از توی ذهن خودش بسته، یک سامانهٔ ثبت را اول توهین حس میکند و بعد حافظهای که از کار نمیافتد.
برای همین «آدمها» سومین سؤال از پنج سؤالی است که پیش از ساختن هر چیزی همراستا میکنم: برای اینکه این کار کند، چه کسی باید رفتارش را عوض کند؟ هر محصولی درخواستی است که کسی جور دیگری رفتار کند. کاربرها، بله، ولی تیم فروش هم، تیم ارسال هم، و آدمی که باید روش قدیمی را کنار بگذارد. دِک هیچوقت مجبور نیست به این سؤال جواب دهد. سیستم عملیاتی نمیتواند از آن فرار کند.
چیز دیگری که سیستم عملیاتی مجبورت میکند دربارهاش صادق باشی، بازاری است که واقعاً در آن هستی. بازار طلای ایران فیزیکی تسویه میشود. همین لجستیک و امانتداری را مسئلهٔ محصول میکند و از پشتصحنهٔ اداری بیرون میآورد. با یک اپ قشنگتر نمیشود این را از طراحی حذف کرد.
آنکه کار نکرد
Mokaab همان ایده بود، و زودتر آمد: ۲۰۲۴ تا ۲۰۲۵، در حالی که Shalize مال ۲۰۲۵ تا ۲۰۲۶ است. هیچوقت عرضه نشد.
پلتفرم کاملِ سرمایهگذاری را معماری کردم: خرید، فروش، نگهداری، بازخرید، قیمتگذاری، فاکتور، تحویل و مسیرهای حساب کاربری. تعهدِ بازخرید را از روز اول در طراحی گذاشتم، بهجای آنکه بعداً به آن وصلش کنم. هنوز فکر میکنم درست بود. بازار خودِ شکافِ اعتماد است و فناوری در درجهٔ بعد میآید: در ایران، طلا خریدن به نیت سرمایهگذاری یعنی اعتماد به یک مغازه، به قیمتی که نمیتوانی راستیآزماییاش کنی، و به قولِ بازخریدی که کسی جایی ننوشته.
عرضه نشد. اولویتهای گروهِ مادر پیش از آماده شدنِ پلتفرم به سمت عملیات فیزیکی رفت. درسِ ناخوشایند اینجاست، و به ضررِ این اصل تمام میشود و نه به نفعش: سیستم عملیاتیِ خوشطراحی تو را از تصمیمِ کس دیگری دربارهٔ اینکه پول کجا برود حفظ نمیکند. سیستم را داشتم. اختیارش را نداشتم. هر کس انضباط عملیاتی را بهعنوان تضمین به تو میفروشد، دارد چیزی به تو میفروشد.
آنچه ماند معماری و مدل بازار بود که در سیستم عملیاتی Shalize جا گرفت. پس جملهٔ «Mokaab شکست خورد» کل ماجرا را نمیگوید. روایتِ صادقانه این است: Mokaab کارِ طراحی بود و Shalize جایی که آن طراحی اجرا شد.
همان شکل، در جاهایی که هیچ شباهتی به هم ندارند
Mehrabani پلتفرم تأمین مالی جمعیِ خیریه است و ربطی به کسبوکار طلا ندارد، ولی ساختارش عیناً همان است. کمکِ خیریه از هر دو سر میلنگد: اهداکننده نمیتواند نیاز را راستیآزمایی کند، مددکار نمیتواند نتیجه را ثابت کند، و اعتماد وسطِ راه فرو میریزد. پس کارت Mehrabani را به شکل یک شیء طراحی کردم که نیازِ تأییدشده، داستانِ مددجو، کمک و نتیجه را با هم حمل میکند، و Soha را زیرش بهعنوان لایهٔ دادهٔ نیازهای تأییدشده ساختم. بعد بخشی که مهم است: گردشکارِ عملیاتیای که مددکارها واقعاً از آن استفاده میکنند. همان که واقعاً به کار میبرند، و نه آنکه باید به کار ببرند.
Ketabno در حدود سه ماه عرضه شد. کنارش HisTory اجرا شد، یک کمپین رشدِ محصولمحور که به شکل یک حرکتِ پیوسته ساخته شده بود: ثبتنام، تکمیل پروفایل و خرید کتاب الکترونیک، بهجای سه کمپین که کار را بد به هم تحویل میدهند. Invest Iran همین انضباط است در یک سازمانِ ترویج سرمایهگذاری، که بدون حضور دیجیتال یک شمارهٔ تلفن است: کشف فرصت، سنجش مزیت رقابتی، اعلام علاقه، تعامل با سازمان، مدیریت درخواست، خدمات پس از سرمایهگذاری. باز هم قدمهایی با اسم.
CompanyHouse، در ۲۰۱۵، جایی بود که اولین بار به مرزِ این ایده خوردم. دانشِ ضمنیِ کارشناسهای ثبت را در یک گردشکارِ راهنما و پرسشمحور مدل کردیم که مدارکِ ثبت را خودش تولید میکرد، و قاعدهها، نقطههای تصمیم و استثناها را به منطقِ محصول تبدیل کردیم. یک سال کار کرد و بسته شد. درسش: محصولکردنِ دانشِ کارشناس خیلی پیش از آنکه مسئلهٔ نرمافزار باشد، مسئلهٔ بیرونکشیدنِ دانش است. میتوانی تکتکِ قدمهای سیستم را تعریف کنی و باز هم استثناهایی را که کارشناس میداند و هیچوقت به زبان نمیآورد به دست نیاورده باشی، چون برای او اینها استثنا به حساب نمیآیند.
چرا حق دارم این را بگویم
ساختنِ شرکت، حکمرانی و بزرگکردنِ عملیات را در عقیق یاد گرفتم، با اینکه هر سه را اول بد انجام دادم، و بعد سازمان را از اجرای پروژه به سمت طراحی محصولِ پایدار بردم. مدل کاریای که آنجا ساختم پرزرقوبرق نبود و هر بار همان فهرست است: دریافت بریف، تعریف خروجی، تقسیم کار، پیگیری، بازخورد، اصلاح، تحویل.
اسمش سیستم است، و با استراتژی فرق دارد. و تنها چیزی در اینجاست که از برخورد با بازارهای واقعی سالم بیرون آمده.