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