عملیات پس از فروشی که هیچ‌کس مکتوبش نکرده بود، از نقشه‌ی کلان تا دستورالعمل کاری ترسیم شد؛ اما فقط تا جایی که شواهد اجازه می‌داد.
01زمینه
یاراوان برند گارانتی و خدمات پس از فروش یک خرده‌فروش تلفن همراه در ایران است. در سال ۲۰۲۴ یک آژانس بیرونی هویت برند آن را نوشت، اما بعد از آن چیزی روی این هویت ساخته نشد. کار از ژوئیه‌ی ۲۰۲۶ این بود که این هویت به خدمتی تبدیل شود که واقعاً کار می‌کند: یک وب‌سایت عمومی، یک پنل مشتری و یک پنل کارکنان، و پشت همه‌ی آن‌ها عملیاتی که باید به وعده‌های برند عمل می‌کرد.
صف تیکت‌ها و عملیات تعمیر در دست سامانه‌ی پشتیبانی فعلی است. در فرایندهایی که مالکشان یاراوان است، رابطه برعکس است: یاراوان مرجع عملیات است و سامانه‌ی پشتیبانی فرایند را ثبت می‌کند، اما اجرایش نمی‌کند. این مطالعه‌ی موردی درباره‌ی همین عملیات است؛ محصولی که روی آن ساخته شد، مطالعه‌ی موردی جداگانه‌ای دارد.
02مسئله
عملیات هیچ‌وقت مکتوب نشده بود. سند نیازمندی‌ها و مشخصات کارکردی هر دو به دو سند مرجع استناد می‌کردند، یعنی سند نیازمندی‌های خدمات پس از فروش و گزارش فرایندهای CRM، و آن‌ها را منشأ فرایندهای واقعی تیکتینگ، تعمیر و گارانتی می‌دانستند. هیچ‌کدام در هیچ مخزنی وجود نداشت.
پس هیچ نقشه‌ی فرایندی نمی‌توانست وضعیت موجود را ثبت کند؛ هر نقشه باید وضعیت مطلوب را طراحی می‌کرد، و مجموعه‌ی فرایندها همین هشدار را در صفحه‌ی اولش دارد. در همین حال، وعده‌های عمومی برند از توان عملیات جلو افتاده بود: بررسی نیازمندی‌ها نشان داد ادعاهای اصلی سایت قدیمی در عملیات واقعیت نداشتند و هیچ پایگاه داده‌ی واقعی‌ای برای گارانتی وجود نداشت.
این وضعیت پرسش طراحی عملیات را مشخص کرد: چطور می‌شود فرایندی را که هنوز هیچ‌کس نمی‌تواند تأییدش کند ترسیم کرد و چیزی از خود نساخت؟
نقش من
طراحی خدمت را رهبری کردم: ممیزی آمادگی، معماری فرایند، مدل نقش‌ها و اقتصاد گارانتی. مالکیت کسب‌وکار در دست کارفرما ماند؛ تصمیم‌های تجاری با مسئول کسب‌وکار کارفرما بود، و عملیات پشتیبانی و بازبینی نقشه‌ها با مسئول خدمات پس از فروش.
این فایل با کمک هوش مصنوعی ساخته شد: یک ایجنت از طریق یکپارچه‌سازی Figma اصلاحات بازبینی را اعمال کرد و هر اصلاح در رشتهی نظر خودش ثبت شد. قواعد ترسیم و ردههای شواهدی که ایجنت باید رعایت می‌کرد، قبل از همه‌ی اینها نوشته شده بود.
04رویکرد
هیچ مرحلهای با تحویل یک سند تمام نمیشد؛ هر مرحله به یک دروازه میرسید. برای نیازمندی‌ها پنجاه پرسش چندگزینهای مستقیم از مسئول کسب‌وکار پرسیده شد، اسناد برند و اسناد مرجع بازبینی شد و نُه رقیب بنچمارک شدند. محک موفقیت فقط یکی بود: تیم مهندسی بتواند کار را شروع کند بی‌آنکه لازم باشد هیچ پرسش بنیادینی را دوباره بپرسد.
بعد ممیزی آمادگی اجرا شد و رد شد. نتیجه‌ی ممیزی روی ۵۹ منبع و ۳۱ فرایند NOT_READY بود: ۱۲ مانع، ۴ تعارض حلنشده و نقشهایی که در سه طبقهبندی ناسازگار تعریف شده بودند. دور دوم با این حکم بحث نکرد؛ دامنه را به ۱۳ فرایندی محدود کرد که برند واقعاً مالکشان است. بعدها یک اصلاحیه دامنه را به ۲۲ فرایند رساند و پذیرش، عیبیابی، تعمیر، ارسال بازگشتی و قطعات را به آن اضافه کرد.
با محدود شدن دامنه، آمادگی ساختاری از ۴۹٪ به ۷۸٪ و اطمینان شواهد از ۵۸٪ به ۹۲٪ رسید؛ چون فرایندهایی که در دامنه ماندند از روی کد اجرایی و تستهای موفق قابل خواندن بودند.
«NOT_READY نباید با هیچ درصد مثبت یا روایت خوشبینانهای جایگزین شود.»
05پژوهش
فایل Figma هیچ صفحه‌ی رابط کاربری‌ای ندارد. رابط کاربری به‌صورت مکتوب مشخص شد و تلاش طراحی صرف بخشی شد که هیچ‌کس نمی‌توانست توصیفش کند: خود عملیات. صفحه‌ی اول فایل جلد نیست، صفحه‌ی قواعد است: یک کتابخانه‌ی اجزای چهارده‌بخشی و شش قاعده‌ی داخلی. جریان، مثل خود زبان، از راست به چپ پیش می‌رود. جاهای خالی با «نیازمند تعیین» علامت می‌خورند و هیچ‌وقت با نام یا عددی حدسی پر نمی‌شوند. تعارض‌ها ثبت می‌شوند، اما حل نمی‌شوند. رنگ هیچ‌وقت به‌تنهایی معنایی را نمی‌رساند و همیشه با یک شکل و یک آیکون همراه است.
شکل کل فایل را یک قاعده تعیین می‌کند: اینکه چه چیزی را می‌شود ترسیم کرد، به شواهد پشت هر ادعا بستگی دارد. شواهد پنج رده دارند. بالاترین رده کد اجرایی است که اجازه‌ی یک سوئیم‌لین کامل را می‌دهد؛ در پایین‌ترین رده هیچ منبعی وجود ندارد، ترسیم ممنوع است و فقط یک اطلاعیه می‌آید. هرچه رده پایین‌تر باشد، چیز کمتری می‌شود ترسیم کرد.
برای همین، فایل درباره‌ی چیزهایی که ندارد صادق است. هر جا سطحی ناتمام می‌ماند، یک تابلوی اطلاعیه می‌گوید چه چیزی کم است و چرا، و اطلاعیه‌های نقشه‌ی خدمات و سوئیم‌لین شمارش را تا ۲۲ کامل می‌کنند. نموداری که برای یک توالی مستندنشده کشیده شود، همان چیز ساختگی‌ای است که قواعد منع می‌کنند، فقط باورپذیرتر.
06شش سطح
این معماری شش سطح دارد و هر سطح به یک پرسش جداگانه جواب می‌دهد. فعال‌سازی گارانتی توسط مشتری از معدود فرایندهایی است که در همه‌ی سطوح ترسیم شده، برای همین کل ساختار را نشان می‌دهد. در نقشه‌ی کلان، این فرایند یک کارت است با یک مالک، یک خروجی و یک وضعیت. در سطح ۱ به یک کارت سرتاسری تبدیل می‌شود: رویداد آغازگر، مالک، رویدادهای شروع و پایان، چهار فاز، دروازه‌های تصمیم، ورودی‌ها و خروجی‌هایش، کنترل‌هایی که کد اعمال می‌کند، و یک KPI و SLA با علامت «نیازمند تعیین»، چون هیچ منبعی فرمول یا زمان تأییدشده‌ای برایشان ندارد.
سطح ۲ یک بلوپرینت خدمت است: اقدام‌های مشتری، نقاط تماس، و کارهایی که کارکنان و سامانه‌ها در هر طرف خطوط تعامل، دیدپذیری و تعامل داخلی انجام می‌دهند، تا سوابق و کنترل‌هایی که از هر گام باقی می‌ماند. این سطح نشان می‌دهد برچسب چاپی‌ای که مشتری کار را با آن شروع می‌کند، نقطه‌ی تماسی بیرون از کنترل سامانه است، چون چاپ بیرون از سامانه انجام می‌شود. فایل این نقطه‌ی تماس را هم ترسیم کرده است: یک کارت گارانتی قابل چاپ، رو و پشت، در ده گونه. سطح ۳ همین توالی را به سوئیم‌لینی تبدیل می‌کند که برای هر کنشگر یک مسیر دارد.
سطوح ۴ و ۵ برای کسانی است که فرایند را اجرا می‌کنند. رویه هم‌زمان چهار فرایند را پوشش می‌دهد؛ رویه‌ها و فرایندها یک‌به‌یک با هم متناظر نیستند. روی رویه مهر «تأییدنشده» خورده و تأییدکننده و تاریخ بازبینی‌اش «نیازمند تعیین» مانده است. دستورالعمل کاری همان هفت گامی است که خود مشتری برمی‌دارد، با چک‌لیستی که برای مشتری نوشته شده: در الفبای کد صفر، حرف O، یک، حرف I و حرف L نیست تا چیزی روی برچسب چاپی اشتباه خوانده نشود.
هر سطح می‌تواند جایی متوقف شود. از ۲۲ فرایند، فقط چهارده فرایند سوئیم‌لین دارند و فقط شش فرایند بلوپرینت. بقیه اطلاعیه‌ای دارند که دلیلش را می‌گوید، و اطلاعیه‌ها شمارش را تا ۲۲ کامل می‌کنند.
07آنچه نقشه‌ها یافتند
ترسیم عملیات چیزهایی را نشان داد که در هیچ سندی نبود. از چهارده فرایندی که به‌صورت سوئیم‌لین ترسیم شدند، فقط دو فرایند اصلاً پیامک می‌فرستند: کد ورود و فعال‌سازی گارانتی. برای همین پیش‌نویس متن پیامک‌ها فقط به همین دو نقشه اضافه شد. چهار فرایند در نقشه‌ی کلان کارت ندارند، چون منابعی که برایشان ذکر شده وجود ندارند.
هر جا نشود سطحی را صادقانه ترسیم کرد، یک اطلاعیه جای آن را می‌گیرد. شش دستورالعمل کاری هنوز قابل نوشتن نیستند و هر کدام دلیل مشخصی دارد: نبود سازوکار بازنشانی، نبود مسیری برای اختلاف بر سر مالکیت، نبود قالب شماره‌ی فاکتور، یک تعارض باز، نبود استاندارد عکس و نبود سیاستی برای کالاهای مطالبه‌نشده. رویه‌ی کیفیت تعمیر اصلاً شماره‌ی دستورالعمل کاری نگرفت؛ رزرو کردن شماره برای رویه‌ای که هنوز معلوم نیست چه کسی اجرایش می‌کند، خودش یک ادعا می‌شد.
فایل خودش را هم ممیزی می‌کند. یک ماتریس پوشش هر یک از ۲۲ فرایند را کنار منبعش، سطوحی که دارد و چیزهایی که کم دارد می‌گذارد: شش کامل، شش ناقص، یکی در تعارض و نُه نیازمند تعیین. ماتریس سه شکافی را که بسته علامت خورده بودند دوباره باز می‌کند، چون بسته شدن یک شکاف با حل شدنش در سازمان یکی نیست. هر جا هم معلوم شد منبعی چیزی را که به آن استناد شده بود نمی‌گوید، ماتریس استناد خودش را پس می‌گیرد.
08نقش‌ها
هشت کارت نقش برای هر نقش هدف، وظایف، اختیارات انحصاری، استثناهای عامدانه و شکاف‌ها را مشخص می‌کنند، و KPI و SLA روی همه‌ی کارت‌ها «نیازمند تعیین» علامت خورده‌اند. بعضی کارت‌ها بیشتر پرسش‌اند تا جواب. یک نقش در کد وجود دارد و دسترسی هم دارد، اما هیچ سند کسب‌وکاری، نمودار سازمانی یا رویه‌ای آن را تعریف نمی‌کند. برای همین مسیر این نقش خط‌چین ترسیم شده و همین‌طور می‌ماند تا کسب‌وکار تصمیم بگیرد که این نقش واقعی است یا نام دیگری برای یکی از نقشهای موجود.
ماتریس مسئولیت را فقط تا سه‌چهارم می‌شد از کد استخراج کرد. ستون‌های مسئول اجرا، مشورت‌شونده و مطلع‌شونده از کد به دست آمدند، اما ستون پاسخ‌گو نه؛ چون کد می‌گوید چه کسی می‌تواند کاری را انجام دهد، نه اینکه چه کسی پاسخ‌گوی نتیجه‌ی آن است. ماتریس با همین ستون باز و نواری که این را توضیح می‌دهد منتشر می‌شود. استثناهای عامدانه، یعنی تفکیک وظایف، با رنگ قرمز علامت خورده‌اند تا با جای خالی اشتباه گرفته نشوند: نقشی که سقف ابطال را تعیین می‌کند نمی‌تواند ابطال‌ها را تأیید کند، چون در آن صورت می‌توانست سقف خودش را بالا ببرد.
مدل دسترسی هم همین‌طور بررسی شد. یک صفحه هشت کنترل ساختاری را که کد اعمال می‌کند فهرست می‌کند، مثل منع به‌صورت پیش‌فرض، خطای 404 به‌جای 403 تا هیچ نقشی نفهمد صفحه‌ای وجود دارد، و نبود هر پیش‌فرض ساختگی؛ چون «ساختن یک پیش‌فرض یعنی انتشار بی‌صدای سیاستی که هیچ‌کس تأییدش نکرده است.» کنار آن، پیشنهادی که خود کارکنان خدمات پس از فروش برای نقش‌ها داده‌اند، یعنی هشت نقش و ۷۶ مورد، مورد به مورد و کنار هم با کد مقایسه می‌شود، «نه ادغام، نه تطبیق». از این ۷۶ مورد، سه مورد کامل ساخته شده‌اند و بیست مورد با یک تصمیم معماری تأییدشده در تعارض‌اند. صفحه محدودیت خودش را هم می‌گوید: درباره‌ی درست بودن پیشنهاد هیچ حکمی نمی‌دهد.
09تصمیم‌های کلیدی
بیشتر این روش درباره‌ی چیزهایی است که فایل از ترسیمشان سر باز می‌زند.
پنج رده‌ی شواهد مشخص می‌کنند چه چیزی را می‌شود ترسیم کرد، و رده برای هر ادعا جداگانه تعیین می‌شود، نه برای کل یک سند. کد اجرایی اجازه‌ی یک سوئیم‌لین کامل را می‌دهد و نبود هیچ منبعی فقط اجازه‌ی یک اطلاعیه را. نمودار ادعا می‌کند توالی، شرط‌ها، مسیرهای خطا و مرز مسیرها را می‌داند؛ کشیدن نمودار بدون شواهد یعنی چیزی را از خود ساختن، فقط با ظاهری باورپذیرتر.
هیچ اطلاعات کسب‌وکاری از خود ساخته نشد. هر جا نام، عدد یا زمانی کم بود، در فیلدش «نیازمند تعیین» نوشته شد؛ روی همه‌ی KPIها، همه‌ی SLAها و بیشتر تأییدکننده‌ها. این‌طور شکاف‌ها را می‌شود شمرد و به کسی سپرد.
هر جا دو منبع با هم اختلاف داشتند، فایل یکی را برنده نمی‌کند؛ تعارض و جای آن را ثبت می‌کند. حل کردن بی‌سروصدای تعارض یعنی گرفتن تصمیمی به‌جای کسب‌وکار.
مسئول اجرا، مشورت‌شونده و مطلع‌شونده را می‌شد از روی کد خواند؛ پاسخ‌گو را نه. پر کردن آن از روی مجوزها، کسی را که می‌تواند اقدام کند با کسی که پاسخ‌گوی نتیجه است یکی می‌گرفت.
هر سوئیم‌لین حکم CRM خودش را با دلیلش دارد. حکم یکی «افزوده شود، اولویت بالا» است، چون مشتری فقط با تماس تلفنی می‌تواند درخواستش را لغو کند. چهار سوئیم‌لین حکم مشروط دارند و نُه سوئیم‌لین نیازی به آن ندارند.
جریان از راست به چپ است و همه‌ی برچسب‌هایی که دیده می‌شوند فارسی‌اند، پس کسانی که عملیات را اداره می‌کنند نقشه‌ها را به زبان خودشان می‌خوانند. شناسه‌های لاتین در نام فریم‌ها آمده‌اند تا هر بورد را بشود تا کد و اسناد دنبال کرد.
10اقتصاد
عملیات باید به این پرسش هم جواب می‌داد که وعده‌ی اصلی‌اش چه هزینه‌ای دارد. گارانتی در روز صدورش هیچ خدمتی ارائه نمی‌دهد؛ فقط وعده می‌دهد که اگر دستگاه در دوره‌ای معین از کار بیفتد، کسی هزینه را می‌پردازد. اینکه آیا مطالبه‌ای می‌رسد، کی، و چه هزینه‌ای دارد، همه در آن روز نامعلوم‌اند؛ پس باید از همین حالا برایش پول کنار گذاشت، وگرنه این وعده هیچ پشتوانه‌ای ندارد.
ارائه این تعهد را از صدور تا بسته شدن دنبال می‌کند و نشان می‌دهد چه کسانی می‌توانند هزینه‌اش را بدهند. هر جواب هم مشخص می‌کند برند چه چیزی است: اگر خرده‌فروش هزینه را خودش بدهد، برند یک مرکز هزینه است؛ اگر فروشندگان کدها را بخرند، یک کسب‌وکار مستقل؛ و اگر واردکننده بپردازد، شریکی که شبکه را اداره می‌کند. توصیه‌ی ارائه با برچسب «یک پیشنهاد، نه یک تصمیم» آمده است.
ارائه در پایان کنترل‌ها را به ترتیب هزینه می‌آورد، که ارزان‌ترینشان فقط یک فیلد است. بعد ده تصمیم با مالک و گزینه‌هایشان می‌آید که هشت‌تایشان را می‌شود همین امروز، بدون هیچ عددی، گرفت.
در این ارائه فقط این عددها مجازند: عددی که از کد استخراج شده، عدد فرضی‌ای که برچسب فرضی خورده، یا بنچمارک بیرونی همراه با منبع، جامعه‌ی آماری، تاریخ و میزان اطمینانش. هر اسلاید نشانی دارد که می‌گوید عددهایش از کدام نوع است.
11نتایج
هیچ شاخص کسب‌وکاری در کار نیست و نباید هم باشد: محصول روی محیط آزمایشی است و شاخص‌های توافق‌شده هنوز فرمول یا منبع داده‌ی تأییدشده‌ای ندارند. چیزی که این کار تغییر داد، شناخت سازمان از خودش است. در ژوئیه هیچ روایت مکتوبی از عملیات خدمات پس از فروش وجود نداشت؛ حالا روایتی ترسیم‌شده هست که در آن هر شکاف علامت خورده، شمرده شده و به کسی سپرده شده است. سه موردی هم که یکپارچه‌سازی را متوقف کرده‌اند کار مهندسی نیستند؛ به‌عنوان تصمیم نام برده شده‌اند.
12آنچه یاد گرفتم
همه‌ی خروجیها همین رویکرد را دارند: NOT_READY به‌جای یک درصد، «نیازمند تعیین» روی کارت‌های فرایند، ستون خالی «پاسخ‌گو» با نواری که همین را می‌گوید، و نشان شواهد روی هر اسلاید.
ترسیم چیزی که هیچ‌کس نمی‌توانست توصیفش کند، چیزهایی را نشان داد که در هیچ سندی نبود: کدام فرایندها واقعاً به مشتری پیام می‌دهند، کدام نقش‌ها فقط در کد وجود دارند و کدام ستون را نمیشود از روی مجوزها پر کرد. نقشهای که مجبور است کامل به نظر برسد، فقط تزئین است.
ممیزی اول رد شد، چون عملیاتی را میسنجید که این محصول مالکش نیست. محدود کردن ممیزی به فرایندهایی که برند مالکشان است استاندارد را پایین نیاورد؛ اطمینان شواهد را به ۹۲٪ رساند.
جواب دادن به یک نظر فقط یک نود را درست می‌کند؛ اما اگر قاعده‌ی پشت آن نام بگیرد، همه‌ی نودهای بعدی هم درست می‌شوند. یک یادداشت درباره‌ی املای فارسی به یک قاعده‌ی نامدار تبدیل شد و بعد در یک دور، ۱٬۰۸۸ نود متنی در هر سیزده صفحه یکجا اصلاح شد.