داستان ساده سازی وب سایت IBM، فقط یک وبسایت معمولی بساز

آقای Bryan Casey، مدیر دیجیتال مارکتینگ IBM، بزرگ ترین شرکت ماشین های تجاری در دنیا، طی یک رشته توییت از اقدامی بزرگ در سطح کل marketing footprint برند خبر داد.

این شرکت توانست طی مدت 9 ماه از سپتامبر 2022 تا می 2023، بیش از 80 درصد از کل محتوای وبسایت خود، شامل 100 ها هزار صفحه را حذف و ساده سازی کند. این پروژه بزرگ در نهایت تبدیل به یک موفقیت عظیم شد که با افزایش ترافیک و میزان رضایت مندی مشتریان و مخاطبین - NPS همراه بود.

در این مقاله به بررسی گزارش آقای Bryan Casey درخصوص ابعاد این اقدام خواهیم پرداخت، تا بتوانیم از تجربه ارزشمند بدست آمده برای بهبود وضعیت استراتژی و بازاریابی محتوایی کسب و کار مان بهره ببریم.

آقای Bryan Casey می گوید:

قبل از هرچیز حتما این سوال برای شما پیش می آید که اصلا چرا باید این پروژه را انجام می دادیم؟

خُب، پاسخ ساده است، زیرا مدیریت سایت برای تیم های ما غیرممکن شده بود و مشتریان ما به سختی وبسایت را درک و از آن استفاده می کردند. این یعنی در واقع ما برای "پیچیدگی" هزینه می کردیم.

پیچیدگی هایی که در وبسایت ما وجود دارد هرگز بدون دلایل اصولی و منطقی نیست، زیرا IBM در بیش از 100 کشور دنیا فعالیت می کند و در نتیجه وب سایت ما نیز دنیای گسترده‌ای از پیوندها مانند /cc-lc/s داشت که با بیش از 160+ زبان مختلف در نتایج بود. ما یک شرکت بزرگ هستیم با ده ها میلیارد دلار درآمد و با صدها نوع محصول و خدمات متنوع.

این پیچیدگی ها باعث شد بسیاری از مردم احساس کنند نشان دادن کل وبسایت IBM به یک مشتری جدید، آن هم برای بازاریابی تنها یک محصول، بسیار دشوار باشد، که البته انگیزه آنها قابل درک هم هست.

در نتیجه وبسایت IBM یا IBM.com به یک هلدینگ از وب سایت ها یا چیزی مثل مجموعه ای از سایت ها درون یک وبسایت تبدیل شده بود. این یعنی در حالیکه ما IBM.com بودیم، به آیینه ای تمام نما از IBM.org شباهت داشتیم.

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

نکته:

ساختار IBM قبل از تغییرات اخیر منطقی به نظر می رسید و تعریف صحیحی برای قانون Conway بود، با اینحال آنها تصمیم گرفتند ساختار شکنی کنند و با چالش فوق روبرو شوند. برای همین منظور است که آقای Bryan Casey اصطلاحا می گوید: با اینکه ساختار وبسایت ما، شکل سازمانی سیستم ما را بر اساس قانون Conway تعریف می کرد، کارایی مناسبی برای ما نداشت.

قانون کانوی - Conway's Law به اسم متخصص توسعه نرم افزار، ملکوم کانوی - Melvin Conway نام گذاری و در سال 1967 مطرح شد. این قانون می گوید: شکل سازمانی یک سیستم، ساختار آن سیستم را تعیین می‌کند.

به عبارت ساده تر، Conway Law می گوید که سیستم نرم افزاری سازمان ها مستقیما بر ساختار و طراحی آن تأثیرگذار است. به عنوان مثال، اگر یک سازمان دارای چندین تیم توسعه بوده و هر تیم مسوول بخش خاصی از سیستم باشد، احتمالا آن سیستم شامل چندین بخش مستقل با طراحی های مختلف خواهد بود که ارتباطات مجزایی با هم دارند.

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

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

قانون کانوی می گوید سازمان ها سیستم هایی را طراحی می کنند که ساختار ارتباطی خودشان را منعکس می کند. بنابراین، Conway's Law به شرکت ها کمک می کند تا در طراحی و توسعه سیستم های نرم افزاری، به ساختار سازمان خود توجه کرده و تلاش کنند سازمان را به گونه ای طراحی کنند که تیم های مختلف بتوانند به خوبی با هم هماهنگ شده و سیستم نرم‌افزاری بهینه تری را توسعه دهند. ایجاد گروه های کاری مستقل برای بخش های مختلف سیستم و توسعه یک فرهنگ همکاری و ارتباط بین این گروه ها می‌تواند در کیفیت و بهره وری سیستم، باعث بهبودی شود.

یکی دیگر از دلایلی که به این نتیجه رسیدیم روش ما به خوبی کار نمی کرد این است که همه ی واحدهای کسب و کار به صورت یکسان در طبقه بندی های بازاریابی، به صورت استاندارد قرار ندارند، به خصوص در مقایسه با بخش امنیت.

به عبارت دیگر، بخش‌های دیگر شرکت ممکن است با توجه به نوع فعالیت های شان به دسته بندی های بازاریابی متفاوتی نیاز داشته باشند که با دسته بندی استاندارد بازار همخوانی ندارد.

بخش محاسبات و ذخیره سازی، جزو زیرساخت های یک سازمان است، اما کاربران ما انتظار دارند این بخش ها را ببینند و تجربه کنند. به طور دقیق تر، کاربران برای دسترسی به سرویس های محاسباتی و ذخیره سازی، به یک رابط کاربری نیاز دارند که برای آنها قابل دسترسی و استفاده باشد.

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

اگر بخواهم یک جمع بندی داشته باشم، آنچه که ما داریم، وب سایتی است که در سطح گسترده ای به قسمت های جداگانه تقسیم شده بود. وب سایتی که ساختار آن بر اساس واحدهای مختلف کسب و کار ما بوده و بیش از 160 نسخه کامل از آن به زبان های مختلف در در تمام بازارهای مان در سطوح مختلف وجود دارد.

اینجا بود که تصمیم گرفتیم آن را درست کنیم...

پروژه بزرگ ما فقط ساده سازی بود!

برای همین نام رمز پروژه مان را "فقط یک وب سایت معمولی بساز - just build a normal website" گذاشتیم که در سه شاخه اصلی تعریف می شود:

ناوبری - navigation
ساده سازی هسته - core simplification
ساده‌سازی جغرافیایی - geo simplification

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

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

داده‌های NPS می‌گویند ناوبری در سایت یکی از بزرگترین مشکلات تجربه مشتری در شرکت است.
دسته بندی محصول ما 10 برابر بزرگتر از مارک های مشابه بود و مانند بابی اسفنجی پف کرده است.
این صفحات تنها درصد کمی از ارزش را برای مشتریان فراهم می‌کنند و اصل پارتو ( به معنای اینکه بخش کوچکی از عوامل موثر بیشترین ارزش را ایجاد می‌کنند ) بسیار پررنگ به نظر می رسد.

نکته:

شاخص NPS مخفف عبارت Net Promoter Score است که به شاخص خالص ترویج کنندگان نیز شناخته می شود. منظور از Promoter کسی است که یک کسب و کار را برای دوستان و آشنایان اش تبلیغ می کند و به آنها پیشنهاد می کند از محصولات آن کسب و کار استفاده کنند.

ما همیشه به مردم می گفتیم ساختار ضعیف سایت ما مانع موفقیت بیشتر تیم‌ها می‌شود و می توانیم آن را در حالی که کمتر از 2٪ نتایج را در معرض خطر قرار دهد، درست کنیم.

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

پروژه شروع شد...

مردم درجریان اقدامات ما قرار گرفتند، پروژه شروع به حرکت کرد و ما سراغ داده ها رفتیم.

ما تمام صفحات و بخش های وب سایت را بررسی و آنها را ثبت کردیم.
برای هر صفحه، مجموعه ای از شاخص های عملکرد و SEO را تعریف کردیم.
برای هر صفحه پیشنهادات اولیه ای برای حفظ، حذف و یا ادغام صفحات را ارایه دادیم.

در نهایت یک طبقه بندی جدید مقدماتی ایجاد شد.

ما تمام جلسات مان را طی 2 هفته بصورت تمام وقت برنامه ریزی و با تمام بخش های شرکت پشت سرهم مذاکره داشتیم.

من جلسه را با این جمله شروع می کردم: "اینجا کارگاه نیست"، بلکه باید در 8 ساعت پیش روی هرجلسه، بیش از 200 تصمیم بگیریم، زیرا هر بخشی از وبسایت که مربوط به هرکدام از جلسات بود، بطور کامل از بین می رفت.

بله، این کاری است که ما انجام دادیم. در عرض دو هفته، هسته وبسایت IBM.com را بطور کامل دوباره تعریف کردیم. سپس طی یک فراخوان از هر تیم در شرکت دعوت کردیم تا استراتژی و برنامه زمان بندی حذف و یکپارچه سازی برای 1000 صفحه را جهت ساختار جدید وبسایت ارایه دهد.

بعد از حدود 3 ماه، پروژه بصورت زنده در دسترس قرار گرفت. ساختار ناوبری جدید طی 1 روز در بیش از 160 منطقه دنیا آنلاین بود که بالغ بر 100,000 آدرس متفاوت از هم را در تمام مناطق جغرافیایی شامل می شد.

"" بعد از این جریان، شاخص NPS در IBM.com بلافاصله 30 درصد افزایش یافت و نکته بسیار جالب این بود که امتیازات تجربه کاربری ما در خصوص کیفیت محتوا نیز به همان میزان بهبود داشت.""

این یک درس بزرگ بود که فرضیه ما را ثابت می کرد: ساختار سایت بر درک شما از همه چیز در آن تأثیر می گذارد.

چیزی که من به آن اشاره نکردم این بود که ما فقط 1000 صفحه را حذف نکردیم، بلکه بسیاری از چیزهای مهم را حفظ و تجمیع کردیم. اما از طرفی به عنوان مثال 3 صفحه داشتیم که برای یک کلمه کلیدی تارگت شده بود، پس تصمیم گرفتیم آنها را یکی کنیم.

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

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

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

به نظر من کلید واقعی این است که بدانیم باید کجا تسلیم شویم و کجا خط مقدم را حفظ کنیم، و این درسی است که در هر شرایطی و در هر زمانی متفاوت است.

بیایید به مناطق جغرافیایی بپردازیم...

در مورد سایت های جغرافیایی، ما واقعا الگوی بخصوص یا تاثیری بر ثبات بازار ندیدیم. بعضی از سایت ها مانند GCP و AWS ساده هستند اما SAP بسیار سنگین بود و زبان های زیادی دارد. هرچند HubSpot تنها چندین زبان را پوشش می‌دهد اما آنها را به طور جامع ترجمه می‌کند. ( مانند ترجمه کامل صفحات محصول )

نکته:

پلتفرم رایانش ابری گوگل - GCP - Google Cloud Platform
سرویس های ابری آمازون - AWS - Amazon Web Services
سیستم بین المللی نرم افزارهای تجاری - SAP - Systems, Applications, and Products

هیچ اتفاق نظری در مورد اینکه چه چیزی خوب است یا کاربران چه انتظاراتی دارند وجود ندارد. با این تصور، ما فقط با چند کار ساده سراغ پروژه رفتیم:

مدیریت سایت آسان تر شود.
به عملکرد کلی وب سایت در دنیا آسیبی نرسد.

ما برای این دو مورد تحقیق زیادی انجام دادیم و داده های مختلفی را تحلیل کردیم، زیرا به دنبال پاسخ به چند سوال کلیدی بودیم:

فقط زبان ها در برابر ( کشورها و زبان ها )
کدام زبان و کشور
کیفیت ترجمه ها
فراگیر بودن ترجمه ها

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

نتیجه این بود که سایت us-en مان در واقع نسخه انگلیسی جهانی ما بود در حالی که وانمود می‌کردیم اینطور نیست. برای همین بر اساس کاربر و کشور، شروع به تجزیه و تحلیل همه چیز در کل وبسایت مان کردیم و متوجه شدیم که بیشتر مخاطبین ما در جایی که ما می‌خواستیم فرود نمی آیند.

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

هرچند برنامه های موجود در IBM.com همچنان از آن استفاده می کنند، اما ما را قادر می سازد تا کانتکست کشور را بر اساس قیمت گذاری و مناطقی که چت می کنند، برای صفحات اصلی بدست آوریم.

هرچند درصورتیکه حس مان نسبت به اتوماسیون ها بهتر شود ( ما اکنون بر روی یک CMS جدید کار می کنیم )، ممکن است در آینده بعضی کشورها را به سیستم اتوماسیون برگردانیم، اما فکر می کنیم کاری که الان کردیم ساختار بهتری برای کار کردن باشد.

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

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

بر اساس استدلال اخلاقی، به این نتیجه رسیدیم که باید در هر کشوری که تجارت می کنیم، از یک زبان رسمی برای آن منطقه پشتیبانی کنیم. این امر واقعا از نظر اقتصادی سخت بود مگر اینکه بخواهیم از ترجمه ماشینی بدرد نخور بهره ببریم.

آقای Bryan Casey می گوید: فقط در صورتیکه هیچ شانسی در جهنم ندارید از ترجمه آشغال ماشینی استفاده کنید.

این موضوع ما را به نکته مهمی رساند: ترجمه بد، بدتر از نداشتن ترجمه است.

ما تحقیقات وسیعی میان کاربران مان انجام دادیم و جای تعجب هم نبود که مردم از ترجمه ماشینی بد واقعا متنفر هستند. موضوع مهمی که بی توجهی به آن باعث از بین رفتن اعتبار و اعتماد می شود.

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

در نهایت، به دو دلیل به این نتیجه رسیدیم که وب، مجموعه بزرگی از فعالیت‌های مبتنی بر ترجمه است:

1- دارایی ها، دموها، ایمیل ها و موارد مشابه، همگی چیزهای خوبی هستند، اما اگر وب ترجمه نشود، به هیچ وجه قابل مشاهده نخواهد بود.

2- مهم ترین نیازهای محتوا از طریق وب ارایه می‌شود (به عنوان مثال، قیمت‌ها).

ما یک چالش بسیار واضح داشتیم که برای عملیاتی کردن آن نتوانستیم راهی پیدا کنیم. ضرورت ترجمه در زبان‌های double-byte مانند کره‌ای، ژاپنی و چینی در مقایسه با اسپانیایی یا آلمانی بسیار بالاتر است. بدین ترتیب در حالت ایده آل شما کارهای بیشتری در آن بازارها انجام خواهید داد.

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

بطور خلاصه ما از 165 محل به 10 زبان رسیدیم! زبان های پشتیبانی شده در وب را جای دیگری مانند کمپین ها، رسانه ها، دارایی ها و غیره پشتیبانی می کنیم و تمایل داریم تا کیفیت ترجمه طبیعی را نسبت به حجم بالای محتوای ترجمه شده توسط ماشین، اولویت بدهیم.

ما باید این تغییرات را در ۳ سیستم مدیریت محتوای مختلف اجرا کنیم. برای همین منظور، یک پلتفرم را در یک زمان مناسب انتخاب کردیم و به تدریج با وبسایت های هر کشور مشغول شدیم. ما در نیمه اول سال ۲۰۲۳ هفته‌ای ۵ وب سایت داخلی را حذف می کردیم. برای این منظور با بازارهای کوچک شروع کردیم و سپس به سمت بازارهای بزرگ تر مانند انگلستان و هند پیش رفتیم.

این استراتژی خوبی بود زیرا با مسایل پیچیده ای در ریدایرکت ها داشتیم، مانند تداخل و بازگردانی مداوم لینک ها. به همین ترتیب در ابتدا بسیاری از چیزها خراب شد و نیاز به بهبود داشت. سپس زمانی که به هند و انگلیس رسیدیم اوضاع خوب بود، چون تجربه سایت های کوچک تر به کارمان آمد.

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

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

ما به بعضی تیم ها اجازه دادیم تجربیات کمپین ها و رویدادهای محلی را حفظ کنند، زیرا:

نمی‌خواستیم 50 صفحه ما را از انجام کاری که می‌خواستیم با 50000 انجام دهیم باز دارد.

نتیجه خالص تمام کارهایی که انجام دادیم

عملکرد بهتر برای ما (ترافیک، تبدیل)
تجربه بهتر برای کاربران (یونیک، تکمیل سفر مشتری، درک کلی از سایت و کیفیت محتوا)
مدیریت سایت آسان تر و تیم چابک تر (کارهای کمتر، بهتر)

اسم رمز پروژه ما در IBM "ساخت یک وب سایت معمولی" بود که خنده دار به نظر می رسد اما بسیار مهم است.

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

توضیحات:

پروژه تغییرات وبسایت IBM یک کار تمام وقت نبود. برای هر صفحه در تمام زبان ها، 6 هفته بصورت نیمه وقت صدها نفر کار می کردند.