ساخت یا خرید؛ چرا CDXP سازمانی دشوارتر از چیزی است که به نظر می‌رسد؟

گرایش به ساخت داخلی لایهٔ دادهٔ مشتری، کار واقعی، شامل هویت، رضایت، یکپارچه‌سازی، حاکمیت و نگهداشت، را دست‌کم می‌گیرد. ساخت CDXP، ساخت داشبورد نیست.

هر سازمان مهندسی توانمند سرانجام به‌درستی می‌پرسد: وقتی می‌توانیم پلتفرم دادهٔ مشتری را بسازیم، چرا آن را بخریم؟ داده متعلق به ماست، نیازها مشخص‌اند و سامانه‌های دشواری را هم‌اکنون راهبری می‌کنیم. غریزه درست است، اما برآورد معمولاً نادرست؛ زیرا بخش قابل‌مشاهدهٔ CDXP، یعنی بخشی که نمونهٔ اولیه در یک اسپرینت ثابت می‌کند، قسمت آسان است.

پاسخ مستقیم

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

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

کاری که در نمونهٔ اولیه دیده نمی‌شود

برآوردهای ساخت معمولاً مسیر بی‌دردسر را قیمت‌گذاری می‌کنند. هزینه در بخش‌هایی نهفته است که با ورود داده، رضایت و مقیاس واقعی ظاهر می‌شوند.

  • یکپارچه‌سازی هویت‌ها. تطبیق یک فرد در دستگاه‌ها، کانال‌ها و سوابق ناقص، یک اتصال ساده نیست؛ مجموعه‌قواعدی با حاکمیت پیوسته است که باید قابل‌حسابرسی و اصلاح‌پذیر باشد، زیرا گاهی به‌شکلی مهم اشتباه خواهد کرد.
  • رضایت و حاکمیت. هر پروفایل وضعیت رضایتی دارد که باید در همهٔ موارد استفاده اعمال شود. یک‌بار ساختنش دشوار است؛ درست نگه‌داشتنش با تغییر مقررات و منابع، کار اصلی است.
  • یکپارچه‌سازی‌هایی که تغییر می‌کنند. هر منبع طرح‌واره، تناوب و حالت‌های شکست خود را دارد. اتصال‌دهنده‌ها یک‌بار ساخته نمی‌شوند؛ همیشه نگهداشت می‌شوند و بی‌سروصدا از کار می‌افتند.
  • فعال‌سازی و تصمیم‌گیری. تبدیل پروفایل به تصمیم بلادرنگ و اقدام پایین‌دستی، موتور مستقلی است با الزام‌های تأخیر، قابلیت اعتماد و صحت که سامانه‌های گزارش‌گیری هرگز با آن روبه‌رو نیستند.
ساخت CDXP، ساخت داشبورد نیست؛ ساخت یک لایهٔ عملیاتی تحت حاکمیت، مقیاس‌پذیر و میان‌وظیفه‌ای و سپس مالکیت دائمی آن است. واقعیت ساخت

هزینه در نگهداشت است، نه عرضه

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

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

چه زمانی ساخت هنوز منطقی است؟

این استدلال نمی‌گوید هیچ‌کس هرگز نباید بسازد؛ می‌گوید باید صادقانه محاسبه کرد. در شرایط روشن، ساخت می‌تواند انتخاب درست باشد و فروشندهٔ خوب نیز همین را به شما خواهد گفت.

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

برآورد صادقانه. پیش از تأیید ساخت، هزینهٔ سه سال عملیات را حساب کنید، نه سه ماه توسعه: حاکمیت هویت، اعمال رضایت، نگهداشت اتصال‌دهنده، آماده‌باش و زمان مهندسان ارشدی که از محصول اصلی دور می‌شوند. آن را با پلتفرمی تحت کنترل خود مقایسه کنید؛ تصمیم معمولاً تغییر می‌کند.

کنترل بدون بازساخت لوله‌کشی

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

گام بعدی

پیش از تأمین بودجهٔ اسپرینت نخست، یک طرح معماری بگیرید.

Explore Platform

نوشتهٔ

علیرضا مظلومی

مدیر فناوری بین‌وبان

علیرضا معماری و مهندسی استقرار بین‌وبان را هدایت می‌کند و بر کنترل در استقرار on-premises، مقیاس‌پذیری و عمق یکپارچه‌سازی تمرکز دارد.

ساخت یا خریدمعماریحاکمیت دادهراهبرد
همهٔ دیدگاه‌ها