بینوبان یک سال پس از معرفی؛ از زیرساخت داده تا پلتفرم سازمانی

حدود یک سال از معرفی عمومی بینوبان می‌گذرد. در این مدت، محصول از تمرکز اولیه بر داده و شناخت مشتری بهحوزههایی مانند تعامل با مشتری و Retail Media رسیده است. محصول را نزدیک‌تر دیدیم و با مزدک پاکزاد، هم‌بنیانگذار و مدیرعامل بینوبان، درباره آنچه واقعا ساخته شده، منطق «ساخت یا خرید» و آزمون پیش روی این پلتفرم گفت‌وگو کردیم.

حدود یک سال پیش، بینوبان با ایده‌ای نسبتا بلندپروازانه معرفی شد: سازمان‌ها داده‌های زیادی دارند، اما انباشت داده الزاما به شناخت بهتر مشتری، تصمیم بهتر یا درآمد بیشتر منجر نمی‌شود. در ماه‌های اخیر فرصتی پیدا کردیم تا از معرفی اولیه فاصله بگیریم و بخش‌هایی از محصول را نزدیکتر ببینیم. همین مواجهه، چند سوال را جدی‌تر کرد.

بینوبان امروز دقیقا چیست؟ چه مقدار از آنچه درباره‌اش گفته می‌شود در محصول عملیاتی وجود دارد؟ چرا دامنۀ آن از دادۀ مشتری به Marketing Automation ،Retail Media و AdTech رسیده است؟ و سازمانی که خودش تیم فناوری قدرتمندی دارد، چرا باید چنین پلتفرمی را بخرد؟ این سوال آخر شاید از همه مهم‌تر باشد.

بینوبان را امروز می‌توان پلتفرمی سازمانی برای تبدیل دادۀ مشتری به شناخت، اقدام و نتیجۀ قابل اندازه‌گیری توصیف کرد. داده از منابع مختلف وارد می‌شود، هویت‌های پراکندۀ مشتری به یکدیگر متصل می‌شوند، مخاطب ساخته می‌شود و همان شناخت می‌تواند در Journey ،Campaign تجربه‌های O2O یا تبلیغات به کار گرفته شود. این تعریف البته بیشتر از آن که جواب باشد، سوال‌های تازه‌ای می‌سازد.

روایت اولیه بینوبان بیشتر حول CDXP، دادۀ مشتری و شناخت رفتار کاربران شکل گرفته بود. این بخش هم‌چنان هستۀ محصول است، اما چیزی که امروز زیر نام Binoban توسعه پیدا می‌کند به آن محدود نمی‌شود. در یک سوی محصول، دریافت و پردازش رخدادها، پروفایل، Identity Resolution و بخش‌بندی مخاطبان قرار دارد. در سوی دیگرJourney، Campaign و ابزارهای تعامل با مشتری دیده می‌شوند و بخشی دیگر به Retail Media ،Advertiser Portal و فناوری تبلیغات مربوط است.

از پاکزاد می‌پرسیم اگر امروز قرار بود بینوبان را دوباره معرفی کند، آیا باز هم از CDXP شروع می‌کرد؟ جواب می‌دهد: «احتمالا نه با همان تاکید. مسالۀ سازمان‌ها فقط پراکندگی داده نیست؛ خیلی وقت‌ها داده جمع شده، انبار داده هم ساخته شده و Dashboard هم وجود دارد، اما فاصلۀ زیادی تا تصمیم و اقدام باقی مانده است. برای ما ارزش زمانی ساخته می‌شود که داده بتواند وارد عملیات کسب‌وکار شود.»

این نگاه توضیح می‌دهد چرا دامنۀ محصول بزرگتر شده است؛ اما توجیه کافی برای بزرگ کردن یک محصول نیست. محصولات سازمانی به‌سادگی می‌توانند در دام گسترش بی‌پایان قابلیت‌ها بیفتند. هر مشتری مساله‌ای جدید مطرح می‌کند، قابلیت دیگری اضافه می‌شود و چند سال بعد با محصولی روبه‌رو می‌شویم که از نظر فنی قدرتمند و برای کاربر مبهم است.

به نظر می‌رسد خود تیم بینوبان هم با بخشی از این مساله مواجه شده است: «در بعضی قسمت‌ها موتور را جلوتر از کابین ساخته‌ایم. این که فناوری عمیقی داشته باشیم کافی نیست. کاربر نباید برای استفاده از محصول مجبور باشد معماری پشت آن را بفهمد.» در نتیجه، بخشی از تمرکز فعلی بینوبان به جای افزودن حوزه‌های تازه، روی منسجم‌تر کردن تجربۀ کاربری، ساده‌تر کردن مسیرها و تبدیل فناوری‌های موجود به محصولی قابل‌فهم‌تر برای نقش‌های مختلف قرار گرفته است. این شاید یکی از مهم‌ترین تغییرات یک سال گذشته باشد: ساختن موتور با ساختن محصول یکسان نیست.

وقتی با معماری نسبتا بزرگی روبه‌رو می‌شویم، مهم است محصول موجود را با چشم‌انداز آینده مخلوط نکنیم. همۀ آنچه بینوبان برای آینده ترسیم کرده امروز در یک سطح از بلوغ نیست. بخش‌هایی از کنترل عملیاتی، حکمرانی، اندازه‌گیری اثر و تصمیم‌گیری هوشمند هم‌چنان در مسیر توسعه‌اند. اما محصول هم مجموعه‌ای از اسلایدها و برنامه‌های آینده نیست.

در یک سال گذشته، سازمان‌هایی بخش‌های مختلف بینوبان را وارد عملیات خود کرده‌اند؛ سازمان‌هایی که بعضی از آن‌ها چند میلیون کاربر فعال ماهانه دارند و در برخی استقرارها، زیرساخت بینوبان ماهانه با میلیاردها رخداد رفتاری و تراکنشی سروکار دارد. حجم پردازش البته به‌تنهایی معیار چندان جذابی برای موفقیت نیست.

نمونه ملموس دیگر از مسیری که بینوبان طی کرده Retail Media است. کسب‌وکارهای دیجیتال بزرگ معمول از قبل چند دارایی مهم دارند: ترافیک، کاربر، Catalog، فضای نمایش و حجم قابل توجهی از دادۀ دست‌اول. این دارایی‌ها برای کسب‌وکار اصلی ساخته شدهاند، اما در مقیاس کافی میتوانند پایۀ یک کسب‌وکار تبلیغاتی مستقل هم باشند. در برخی از استقرارهای بینوبان، این مدل از مرحلۀ آزمایش عبور کرده و به گفتۀ شرکت، فروش تبلیغات به چند ده میلیارد تومان در ماه رسیده است.

موضوع در اینجا صرفا فروش بنر نیست. دادۀ دست‌اول می‌تواند برای شناخت مخاطب، انتخاب محصول، هدف‌گیری، مدیریت Inventory و سنجش عملکرد تبلیغ استفاده شود. سازمان در عمل تلاش می‌کند ترافیک و فضایی را که پیشتر عمدتا بخشی از هزینه و تجربۀ محصول اصلی بوده است، به دارایی درآمدزا تبدیل کند:

«سازمان از قبل کاربر، ترافیک Catalog ،Inventory و دادۀ دست‌اول دارد. سؤال این است که چطور می‌توان از همین دارایی‌ها، بدون ساختن یک کسب‌وکار کامل مجزا از صفر، یک جریان درآمدی قابل‌اندازه‌گیری ایجاد کرد.» نکتۀ مهم دیگر، مدل شروع چنین پروژه‌هایی است.

بینوبان می‌گوید ترجیحش این است که سازمان پیش از ورود به یک سرمایه‌گذاری بزرگ، دامنۀ مساله را محدود کند: چند Use Case مشخص، بخشی از Inventory یا گروه محدودی از کاربران؛ نتیجه را اندازه بگیرد و سپس دربارۀ توسعۀ سرمایه‌گذاری تصمیم بگیرد. این رویکرد در پروژه‌های سازمانی اهمیت دارد. بسیاری از پروژه‌های فناوری زمانی پرریسک می‌شوند که قرار است پیش از ایجاد اولین ارزش، نسخۀ نهایی معماری ساخته شود.

سوال مهم اما اینجاست: سازمانی که چند میلیون کاربر، میلیاردها رخداد و ظرفیت ایجاد ده‌ها میلیارد تومان درآمد ماهانۀ تبلیغاتی دارد، احتمالا تیم فناوری کوچک یا کم‌توانی هم ندارد. چرا خودش این زیرساخت را نسازد؟ «رقیب ما همیشه یک Vendor دیگر نیست. خیلی وقت‌ها تصمیم سازمان این است که می‌گوید خودمان می‌سازیم. ممکن است هم تصمیم درستی باشد. سوال این است که آیا ساختن آن، بهترین استفاده از سرمایه، استعداد و تمرکز سازمان است یا نه.» بحث «ساخت یا خرید» در همۀ دسته‌های نرم‌افزار به یک اندازه مطرح نیست.

برای نمونه، در حوزۀ نرم‌افزارهای مالی و حسابداری، خرید مجوز یک محصول تخصصی سال‌هاست به انتخاب معمول بسیاری از سازمان‌ها تبدیل شده است. کمتر سازمان بزرگی صرفا به این دلیل که تیم فناوری توانمندی دارد، تصمیم می‌گیرد سیستم مالی و حسابداری خود را از صفر توسعه دهد. این رفتار یک‌شبه شکل نگرفته است. بازار در طول زمان پذیرفته که ارزش یک سیستم مالی فقط در ثبت سند و ساخت گزارش نیست. مقررات تغییر می‌کند، کنترل دسترسی اهمیت دارد Audit، لازم است، سیستم باید پایدار بماند، ارتقا پیدا کند و با بخش‌های دیگر سازمان یکپارچه شود.

در نتیجه، سوال به‌تدریج از «آیا می‌توانیم خودمان بسازیم؟» به «کدام محصول هزینه و ریسک مناسب‌تری برای ما دارد؟» تغییر کرده است. در CDXP ،MarTech و AdTech این نگاه هنوز به همان اندازه جاافتاده نیست. بخشی از دلیل آن هم جوان‌تر بودن این دسته از محصولات است. سازمان ممکن است به اجزای اولیه نگاه کند و نتیجه بگیرد ساختشان دشوار نیست: یک مخزن، Profile یک موتور، Segment ،API ،Campaign. داشبرد این ارزیابی الزاما غلط نیست؛ اما نسخۀ اولیه فقط نقطۀ شروع است.

اشتباه رایج در محاسبۀ «ساخت یا تولید» این است که قیمت نرم‌افزار با هزینۀ ساخت نخستین نسخه مقایسه شود. فرض کنیم سازمان با یک تیم ده نفره می تواند طی 6 یا 9 ماه نسخۀ اولیه ای بسازد. این هزینه کامل قابل محاسبه است. اما بعد از انتشار نسخۀ اول، هزینه متوقف نمی شود؛ مالکیت آغاز می شود. کسی باید مالک محصول باقی بماند. تیم باید حفظ شود. کد باید نگهداری شود. امنیت، دسترسی و Audit باید مدیریت شوند. زیرساخت نیاز به پایش دارد. خطاها باید رفع شوند. نسخه ها باید ارتقا پیدا کنند. مستندات باید زنده بمانند و دانش سیستم نباید با خروج چند نیروی کلیدی از سازمان از بین برود.

مجموع این هزینه ها بخشی از هزینۀ کل مالکیت یا TCO است. هرچه محصول سازمانی تر و عمر آن طولانی تر شود، فاصلۀ میان «هزینۀ ساخت» و «هزینۀ مالکیت» بیشتر می‌شود. «امروز کمتر مدیری قیمت یک نرم‌افزار مالی را با حقوق چند برنامه‌نویس برای ساخت چند فرم حسابداری مقایسه می‌کند، چون بازار فهمیده که محصول، همان نسخۀ اول نیست. در حوزۀ داده MarTech و AdTech هم باید کل چرخۀ عمر را دید.» این قیاس البته کامل نیست. سیستم مالی و CDXP محصولات متفاوتی‌اند و بلوغ بازارشان هم یکسان نیست. اما نکتۀ اصلی دربارۀ اقتصاد مالکیت قابل تأمل است.

شاید یکی از نشانههای بلوغ هر دستۀ نرمافزاری همین باشد: سازمان بهجای اینکه فقط بپرسد »آیا توان ساخت داریم؟«، بپرسد »آیا مالکیت فناوری این حوزه واقعاً بخشی از مزیت رقابتی ماست؟«

هزینه‌ای که در بودجه نمی‌آید حتی TCO مالی هم تمام داستان نیست. مسالۀ دیگر، هزینۀ فرصت است. فرض کنیم ساخت داخلی از نظر مالی کامل ممکن باشد؛ چه کسانی قرار است آن را بسازند؟ اگر بخشی از بهترین مدیران محصول، مهندسان، معماران نرم‌افزار، متخصصان داده و مدیران فنی یک سازمان دو یا سه سال درگیر ساخت و سپس نگهداری چنین زیرساختی شوند، چه چیزی در همان مدت ساخته نشده است؟

برای یک خرده‌فروش، مزیت رقابتی شاید تجربۀ خرید، عملیات، لجستیک یا زنجیرۀ تامین باشد. برای یک کسب‌وکار مالی ممکن است اعتبار، پرداخت یا مدیریت ریسک باشد. اگر بهترین استعدادهای فناوری بخش بزرگی از ظرفیت خود را صرف ساخت Journey Builder ،Permission، Audit ،Identity یا زیرساخت عمومی AdTech کنند، این سؤال مطرح می‌شود که آیا سازمان سرمایۀ انسانی خود را در مهم‌ترین نقطۀ ممکن به کار گرفته است.

مسالۀ زمان هم کم‌اهمیت نیست. پروژهای که با برآورد ۶ماهه شروع شده، ممکن است یک یا دو سال بعد هنوز در حال رسیدن به بلوغ مورد انتظار باشد. در همین فاصله، واحدهای کسب‌وکار منتظر قابلیت‌هایی می‌مانند که قرار بوده زیرساخت جدید در اختیارشان بگذارد. نوعی Feature Freeze پنهان شکل می‌گیرد: ابتدا باید خود پلتفرم ساخته شود، بعد نیازهای کسب‌وکار روی آن اجرا شوند.

«گاهی سازمان فکر می‌کند یک قابلیت را داخل شرکت ساخته است، در حالی که عمل یک شرکت نرم‌افزاری کوچک دیگر داخل خودش ساخته؛ با تیم، نقشۀ راه، نگهداری، بدهی فنی و ریسک نیروی کلیدی خودش.» با این حال، نتیجۀ این بحث نباید این باشد که Buy همیشه تصمیم درست است. اگر فناوری مورد نظر مستقیما مزیت رقابتی اصلی سازمان را می‌سازد، استقلال معماری اهمیت راهبردی دارد، تیم تخصصی پایدار وجود دارد و TCOچندسالۀ ساخت داخلی قابل دفاع است Build، می‌تواند گزینۀ بهتر باشد.

خرید هم بدون ریسک نیست. وابستگی به تامین‌کننده، قابلیت انتقال داده، کیفیت APIها، امکان خروج، شرایط قرارداد و حتی دوام خود Vendor باید در تصمیم لحاظ شود. بنابراین، سوال واقعی این نیست که «آیا می‌توانیم بسازیم؟» سوال دقیق‌تر این است: در افق سه تا پنج سال، کدام مدل مالکیت هزینه و ریسک کمتری دارد و تمرکز بیشتری برای ساخت مزیت رقابتی اصلی سازمان باقی میگذارد؟

اگر بینوبان نتواند در عمل پاسخ مناسبی به این سوال بدهد، عمق فنی محصول بهتنهایی برای موفقیت در بازار سازمانی کافی نخواهد بود.

یکی از ویژگی‌های مهم بینوبان، امکان استقرار در زیرساخت خود سازمان است. برای برخی سازمان‌ها، مالکیت داده، الزامات امنیتی یا سیاست‌های زیرساختی باعث می‌شود استفاده از SaaS عمومی گزینۀ ساده‌ای نباشد. اما On-Premise برای سازندۀ محصول مسیر ساده‌تر یا ارزان‌تری نیست. استقرارهای مختلف می‌توانند سخت‌افزار، نسخه، محدودیت شبکه و سیاست‌های امنیتی متفاوتی داشته باشند.

ارتقا، نگهداری و پشتیبانی نیز پیچیده‌تر می‌شود. پاکزاد می‌گوید تصور این که «سرور را مشتری می‌دهد، بنابراین هزینۀ Vendorکمتر است» با واقعیت فاصله دارد؛ بخشی از هزینه از زیرساخت Cloud به سمت استقرار، نگهداری، ارتقا و عملیات منتقل می‌شود. همین تجربه ظاهر °یکی از درس‌های سال اول بینوبان بوده است: عملیات محصول سازمانی را هم باید تا جای ممکن به خود محصول تبدیل کرد و وابستگی آن را به فایل، پیام، جلسه و حافظۀ افراد کاهش داد.

پاسخ او به سوال بالا دربارۀ قابلیت فنی تازه نیست، بلکه می‌گوید «زودتر روی Product Clarity سرمایه‌گذاری می‌کردم. وقتی تیم فنی قوی باشد، وسوسۀ ساخت موتورهای بیشتر زیاد است. اما مشتری موتور نمی‌خرد؛ محصول می‌خرد.» این نقد شاید یکی از مهم‌ترین نقدهایی باشد که می‌توان به خود بینوبان هم وارد کرد.

پلتفرمی با این دامنه خیلی زود می‌تواند برای تیم سازنده کامل منطقی و برای کاربر بیش از اندازه پیچیده شود. مهندسان می‌دانند سرویس‌ها چطور به هم متصل‌اند، اما مدیر CRM یا داده یا Retail Media نباید برای انجام کار روزمره‌اش معماری سیستم را یاد بگیرد. بخش قابل توجهی از تمرکز فعلی تیم به همین موضوع اختصاص یافته: وضوح بیشتر محصول، تجربۀ متناسب با نقش کاربران، پیادهسازی قابل‌تکرارتر و کوتاه‌تر کردن مسیر رسیدن مشتری به نخستین ارزش. این کار شاید به‌اندازۀ معرفی یک قابلیت AI تازه جذابیت خبری نداشته باشد، اما برای یک محصول سازمانی احتمال مهم‌تر است.

بینوبان برای آینده برنامه‌های متعددی دارد. بخشی از آن‌ها به بالغ‌تر شدن عملیات و کنترل محصول مربوط می‌شوند و بخشی دیگر به سنجش بهتر اثر و استفاده از AI در تصمیم‌گیری و پیشنهاددهی. اما فهرست قابلیت‌های آینده احتمالی مهم‌ترین بخش داستان نیست.

سوال اصلی این است که در پایان سال دوم چه چیزی باید تغییر کرده باشد. پاکزاد می‌گوید: «اگر سال بعد فقط بتوانیم بگوییم Feature بیشتری ساخته‌ایم، برای من موفقیت نیست. مشتری باید زودتر به Value برسد، استفادۀ واقعی بیشتری از محصول داشته باشد و بتوانیم نشان بدهیم نتیجه‌ای که گرفته قابل‌اندازه‌گیری بوده است.» این شاید معیار مناسبی برای قضاوت سال بعد باشد.

یک سال پیش، سوال بیشتر این بود که آیا ایدۀ بینوبان به محصول تبدیل خواهد شد یا نه. امروز بخشی از آن سوال پاسخ گرفته است. محصول در مقیاس چند میلیون کاربر و میلیاردها رخداد کار کرده و دست‌کم بر اساس اعدادی که بینوبان ارائه می‌کند، در برخی سناریوها به GMV چندهمتی و جریان درآمد تبلیغاتی چندده‌میلیاردتومانی در ماه متصل شده است. اما همین نقطه سوال سخت‌تری را جایگزین سوال قبلی می‌کند. آیا بینوبان می‌تواند این عمق فنی را به محصولی تبدیل کند که سازمان‌ها بتوانند با هزینه و ریسک قابل کنترل وارد عملیاتشان کنند، در مقیاس گسترش دهند و اثر اقتصادی آن را به‌طور مستمر بسنجند؟

اگر پاسخ مثبت باشد، آنچه طی سال اول ساخته شده بیشتر شبیه زیرساخت آغاز یک مسیر خواهد بود تا پایان آن. اگر نه، افزایش تعداد فناوری‌ها و قابلیت‌ها به‌تنهایی تفاوت چندانی ایجاد نخواهد کرد. در نهایت، شاید بهترین معیار قضاوت دربارۀ بینوبان همان معیاری باشد که دربارۀ هر فناوری سازمانی باید پرسید: این محصول چه ارزشی ساخته است، و ساخت همان ارزش از مسیر دیگری چه هزینه‌ای برای سازمان داشت؟