یه سیستم خوب که فقط یه بخش ازش استفاده می‌کنه
خیلی از سازمان‌ها یه مسیر مشخص رو طی می‌کنن: تیم IT از حجم تیکت‌های پراکنده روی ایمیل و تلگرام خسته می‌شه، یه ابزار تیکتینگ درست می‌خره، SLA تعریف می‌کنه، و بعد از چند ماه همه چی مرتب می‌شه. مشکل اینجاست که این مرتب‌شدن معمولاً همون‌جا متوقف می‌مونه.
HR، تدارکات، تسهیلات، امور پژوهشی، همه‌شون هنوز دارن با همون روش قدیمی کار می‌کنن. یه کارمند برای مرخصی زنگ می‌زنه، یه استاد برای سالن کنفرانس پیام می‌ده، یه دانشجو برای گواهی برای بار سوم میاد حضوری دنبالش می‌گرده. هیچ‌کدوم از این‌ها توی سیستم تیکتینگ IT ثبت نمی‌شن، چون اصلاً ربطی به IT ندارن.
سه نشونه که یه بخش هنوز بیرون سیستمه
- پیگیری فقط با تماس تلفنی ممکنه. اگه تنها راه فهمیدن وضعیت درخواست، زنگ زدن به یه نفر مشخصه، اون درخواست جایی ثبت نشده.
- وقتی مسئول عوض می‌شه، تاریخچه از بین می‌ره. درخواست‌های قبلی توی چت شخصی یا ایمیل یه نفره‌ن که دیگه اونجا کار نمی‌کنه.
- هیچ گزارشی از حجم کار وجود نداره. مدیر بخش نمی‌تونه بگه ماه گذشته چند درخواست اومده، چقدر طول کشیده جواب داده بشه، یا کجا گیر کرده.
این همان شکافی است که مدیریت خدمات سازمانی می‌خواهد پر کند. در ترند ۲۰۲۶: یک پنجره برای همهٔ بخش‌ها توضیح داده‌ایم چرا مسئله ابزار تیکتینگ بهتر نیست.
چرا «همون ابزار IT رو بده بقیه بخش‌ها» جواب نمی‌ده
راه‌حل اول که به ذهن می‌رسه اینه: چون ابزار تیکتینگ IT کار می‌کنه، بقیه بخش‌ها هم همون رو استفاده کنن. اما HR نمی‌خواد فرمهای سخت‌افزاری IT رو ببینه، و IT نباید درخواست مرخصی رو توی صف خودش داشته باشه. اگه همه‌چیز توی یه کاتالوگ مشترک بریزه، هر بخش غرق درخواست‌های بی‌ربط بخش‌های دیگه می‌شه و دقیقاً همون شلوغی قبلی برمی‌گرده، فقط این بار توی یه ابزار گرون‌تر.
چیزی که واقعاً لازمه یه پنجره واحد برای کاربر نهاییه، کارمند یا دانشجو یه جا می‌ره و درخواستش رو ثبت می‌کنه، اما پشت اون پنجره، هر بخش کاتالوگ، صف و مسئول مخصوص خودش رو داره. کارمند نیازی نداره بدونه درخواست تعمیر پریز برق باید بره پیش تسهیلات و درخواست گواهی اشتغال بره پیش HR؛ سیستم این مسیریابی رو انجام می‌ده.
فن‌سرو دقیقاً همین جدایی رو با یه موتور مشترک انجام می‌ده
فن‌سرو روی همون موتور تیکتینگ فن‌دسک ساخته شده (پایش SLA، گفتگو، پایگاه دانش، گزارش‌گیری)، اما به هر گروه توی سازمان یه کاتالوگ نقش‌محور جدا می‌ده. هر درخواست، از هر بخشی که بیاد، به یه تیکت قابل‌پیگیری با وضعیت، مسئول و مهلت پاسخ تبدیل می‌شه، بدون اینکه بخش‌ها کاتالوگ همدیگه رو ببینن.
این دقیقاً همون مدلیه که توی یه دانشگاه دولتی برای خدمات آموزشی، دانشجویی، پژوهشی، رفاهی و فرهنگی پیاده شده: پنج حوزه‌ی کاملاً متفاوت، یه پنجره‌ی ورودی مشترک برای دانشجو، و یه گزارش‌گیری واحد برای مدیریت که بدونه هر حوزه چقدر بار کاری داره.
نکته کلیدی
مشکل بخش‌های بیرون سیستم، مشکل ابزار نیست، مشکل نداشتن یه لایه مسیریابی بین درخواست‌کننده و بخش‌های مختلفه. وقتی این لایه اضافه بشه، هر بخش می‌تونه با گردش‌کار خودش کار کنه، بدون اینکه دوباره برگرده به تماس تلفنی و پیام شخصی.
پرسش‌های متداول
از کجا بفهمیم یک واحد هنوز بیرون از سیستم تیکتینگ است؟
سه نشانه دارد. پیگیری وضعیت فقط با تماس با یک فرد خاص ممکن است، پس درخواست هیچ‌وقت ثبت نشده است. سابقهٔ درخواست‌ها با رفتن مسئول از بین می‌رود، چون در چت یا ایمیل شخصی او بوده است. و مدیر واحد نمی‌تواند بگوید ماه گذشته چند درخواست آمد، چقدر طول کشید و کجا گیر کرده است.
چرا همان ابزار تیکتینگ IT را به همهٔ واحدها نمیدهیم؟
منابع انسانی نمیخواهد فرمهای درخواست سختافزار IT را ببیند و درخواست مرخصی هم نباید در صف IT باشد. اگر همهٔ واحدها در یک کاتالوگ مشترک ریخته شوند، هر تیم زیر درخواستهایی غرق میشود که ربطی به آن ندارد. نتیجه همان آشفتگی قبلی است، فقط داخل ابزاری گرانتر.
چه ساختاری برای منابع انسانی، پشتیبانی و واحدهای غیر IT جواب می‌دهد؟
یک پنجرهٔ واحد برای کاربر نهایی و پشت آن، برای هر واحد کاتالوگ، صف و مسئول جداگانه. کارمند یا دانشجو همهٔ درخواست‌ها را در یک جا ثبت می‌کند و سیستم مسیر را تعیین می‌کند؛ لازم نیست کسی بداند پریز خراب به تأسیسات می‌رود و گواهی اشتغال به منابع انسانی. هر درخواست تیکتی قابل پیگیری با وضعیت، مسئول و مهلت پاسخ میشود.
واحد منابع انسانی نمونهٔ خوبی از این هزینه است: HR دانشگاه‌ها هنوز هفته‌ای حدود ۹ ساعت صرف سؤال‌های بیمه می‌کند که یک فرایند خودخدمت می‌توانست پاسخ دهد.
دانشگاه‌ها این مشکل را بیشتر از همه در هفته‌های اول سال تحصیلی حس می‌کنند؛ درباره صف درخواست‌های دانشجویی در شروع ترم نوشته‌ایم.
