‏از ایمیل و اکسل تا یه ITSM واقعی: تجربه‌ی Ace Hardware

این مطلب براساس یه ارائه تو رویداد Team '26 اطلسین نوشته شده و داستان مدرن‌سازی ITSM شرکت Ace Hardware‌ـه؛ یه تعاونی (co-op) سخت‌افزاری ۱۰۲ ساله که فروشگاه‌هاش در واقع صاحب شرکت مادرن. مقیاسش هم بزرگه: ۱۲ هزار کارمند شرکتی، ۵۲۰۰ فروشگاه داخلی و حضور تو ۶۰ کشور. به گفته‌ی ارائه‌دهنده‌ها، وقتی ITSM تو شرکتی این‌قدر بزرگ خراب بشه، اثرش به هزاران فروشگاه و میلیون‌ها مشتری می‌رسه.

نقطه‌ی شکست، سیستم تیکتینگ قدیمیشون بود که حدود هشت سال کار کرده بود. اولین درد این بود که تیکت فقط به یه نفر داخل تیم یا دپارتمان ازپیش‌تعریف‌شده می‌خورد؛ همین باعث شد آدم‌ها کلاً سیستم رو ول کنن و به‌جاش یه ایمیل بزنن که «حلش کردم». نتیجه‌ش این بود که هیچ تاریخچه و الگویی از مشکلات تکراری نمی‌موند. مشکل دوم اینکه ابزار client-side بود و فیلترهای سنگین کل سیستم رو برای همه کند یا کرش می‌کرد، محیط sandbox هم نداشتن و تغییرات مستقیم تو production انجام می‌شد.

برای جایگزین، نیازهاشون رو دقیق مشخص کردن: یه سیستم end-to-end برای incident و problem و service request و مدیریت دارایی و تغییر، یکپارچگی با Salesforce (چون بیشتر تیکت‌ها از care center میومد)، یه پورتال self-service که کاربر واقعاً بخواد ازش استفاده کنه، و یه پلتفرم که چند سال باهاشون رشد کنه. Jira Service Management همه‌ی این‌ها رو تیک زد و با شریک تخصصی Stratacom پیش رفتن.

اصل کار یکپارچه‌سازی‌ها بود. Azure AD داده‌ی کاربر و مدیر رو میاره تا گردش‌کار تأییدها خودکار بشه، Intune هر شب داده‌ی سخت‌افزار رو import می‌کنه، Azure DevOps با یه یکپارچگی دوطرفه‌ی PowerShell وضعیت باگ و تست QA رو بی‌درنگ همگام می‌کنه، و IBM Workload Automation برای ۴۲ هزار جاب روزانه‌ی خودکار تیکت می‌سازه. ولی مهم‌ترینش Salesforce بود؛ یه webhook دوطرفه فیلدهای اصلی رو بین دو پلتفرم همگام می‌کنه و یه دکمه‌ی Escalate تیکت رو به تیم درست هل می‌ده، طوری که خیلی از کاربرهای Salesforce اصلاً نمی‌فهمن دوتا سیستم پشت صحنه کار می‌کنن.

رول‌اوت به‌جای big-bang تو سه فاز انجام شد: اول مدیریت تغییر، بعد incident و request، و دو هفته بعد release management. یه دوره‌ی هم‌پوشانی دوماهه گذاشتن تا تیکت‌های باز تو سیستم قدیمی بسته بشن. یه نکته‌ی جالب استانداردسازی بود: Jeff اول ۳۵ فرم جدا ساخته بود، یکی برای هر تیم، ولی بعد فهمیدن همه یه اطلاعات رو می‌گیرن جز فیلد تیم؛ پس همه رو به یه فرم واحد تبدیل کردن تا تغییرات فقط یه جا اعمال بشه.

نویسنده درس‌های واقعی‌شون رو هم صادقانه می‌گه: فیلدهای اجباری مهمن، چون اگه فیلد ردیابی اجباری نباشه تیکت‌ها گم می‌شن؛ فیلدهای مشترک شعاع تأثیر زیادی دارن و تغییرشون رو همه‌ی فرم‌ها اثر می‌ذاره؛ فرم‌ها و automationها undo ندارن پس تست مهم‌تر می‌شه؛ و credentialهای API منقضی می‌شن، پس باید تاریخ ساختشون رو مستند کنی و یادآور تقویمی بذاری تا یهو بی‌سروصدا از کار نیفتن. قدم بعدی‌شون هم استفاده از Rovo (ابزار AI اطلسین) برای بالا آوردن مرورهای پساحادثه از موارد مشابه گذشته‌ست.

نکات کلیدی:

• سیستم قدیمی تیکت رو فقط به تیم‌های ازپیش‌تعریف‌شده می‌داد و آدم‌ها به‌جاش ایمیل می‌زدن، پس هیچ تاریخچه‌ای نمی‌موند
• یکپارچگی دوطرفه با Salesforce مهم‌ترین بخش بود و تقریباً همه‌ی تیکت‌های ورودی رو مدیریت می‌کنه
• استانداردسازی ۳۵ فرم جدا به یه فرم واحد، نگهداری رو ساده کرد
• رول‌اوت فازبندی‌شده (تغییر، بعد incident، بعد release) با دوره‌ی هم‌پوشانی دوماهه انجام شد
• درس‌های کلیدی: فیلدهای اجباری، شعاع تأثیر فیلدهای مشترک، نبود undo، و انقضای credentialهای API