بپرسید چرا وبسایت عمومی، دایرکتوری پروفایل اساتید، میز خدمت فناوری و سامانهٔ بیمهٔ کارکنان یک دانشگاه یک ورود مشترک ندارند، جواب صادقانه بهندرت فنی است. تاریخچهٔ تدارکات است: وبسایت را روابط عمومی در یک سال خریده، میز خدمت را فناوری اطلاعات در سالی دیگر، بیمه را منابع انسانی در سالی سوم — هرکدام بهتنهایی تصمیمی منطقی، هرکدام فقط برای همان دفتری که خریدهاش بهینه شده.
هزینهاش بهعنوان مشکل بقیه ظاهر میشود
یک کارمند جدید قبل از پایان هفتهٔ اولش به پنج حساب جدا نیاز دارد. یک درخواست ارتقای استاد باید دستی در سه سامانه دوباره وارد شود چون هیچکدام schema مشترکی ندارند. یک تیکت فناوری اطلاعات دربارهٔ ورود خراب سامانهٔ بیمه به میز خدمت میرود، که هیچ دیدی روی سامانهٔ بیمه ندارد و فقط میتواند فوروارد کند — به دفتری که ممکن است روزها جواب ندهد.
کسی که این درد را حس میکرد، کسی نبود که میتوانست حلش کند
روابط عمومی که وبسایت را خریده دلیلی ندارد به یکپارچگی میز خدمت فکر کند. فناوری اطلاعات، که بار پشتیبانی پنج ورود جدا را حس میکند، خریدار نرمافزار بیمه نبوده. این پراکندگی در هر تصمیم خرید منفرد منطقی است و در مجموع غیرمنطقی — دقیقاً همان نوع مشکلی که هیچ دفتری بهتنهایی نمیتواند حلش کند.
«یکپارچه» واقعاً چه معنایی باید داشته باشد
نه یک اپلیکیشن یکپارچهٔ واحد — این فقط همان مشکل را با یک تأمینکننده بهجای پنجتا بازتولید میکند. چیزی که واقعاً شکاف را میبندد، یک لایهٔ هویت است که همهٔ سامانهها پشتش مینشینند، تا درخواست ارتقا، تیکت خدمات و سابقهٔ بیمه سه نمای یک نفر باشند نه سه حساب نامرتبط که اتفاقاً یک اسم دارند. بقیه — وبسایت، دایرکتوری اساتید، تیکتینگ، بیمه — میتوانند زیرش از نظر منطقی جدا بمانند، تا وقتی هیچکدام از دانشجو یا کارمند نخواهند دو بار وارد شوند.
ما دقیقاً همین را برای یک دانشگاه دولتی ساختیم: یک SSO پشت پنج سامانهٔ قبلاً جدا. گزارش کامل با اعداد واقعی در مطالعهٔ موردی دانشگاه لرستان است.
