تفاوتِ پرتال با سایتِ معمولی در یک جمله جا می‌شود: سایت جایی است که می‌خوانید و می‌روید؛ پرتال جایی است که کار انجام می‌شود. کاربر وارد حسابش می‌شود، درخواستی ثبت می‌کند، وضعیتش را می‌بیند، یا خدمتی می‌گیرد.

ولی این تعریف تصمیم‌سازِ شما نیست. تصمیمِ واقعی یک قدم عقب‌تر است و در ادامه از همان شروع می‌کنیم.

مطالبی که در ادامه می خوانید:

این نکته کلِ تصمیم را روشن می‌کند. پرتال کارِ تازه‌ای نمی‌سازد؛ کاری را که تا امروز کارمندِ شما انجام می‌داده، به خودِ ذی‌نفع می‌دهد. یعنی سؤالِ درست این نیست که «پرتال بسازیم یا نه»، این است:

کدام کار را چه کسی باید خودش انجام دهد؟

کارامروز چه کسی انجامش می‌دهدبا پرتال چه کسی
پیگیریِ وضعیتِ درخواستکارمند، پشتِ تلفنخودِ ذی‌نفع، هر ساعتِ شبانه‌روز
ثبتِ درخواست و پیوستِ مدارکحضوری یا ایمیل، بعد ورودِ دستیخودِ ذی‌نفع، یک بار و کامل
گرفتنِ فرم یا گواهیِ تکراریکارمند، هر بار از اولخودِ ذی‌نفع، دانلود
اعلامِ نقصِ مدارکتماسِ تلفنیِ رفت‌وبرگشتیسیستم، همان لحظه‌ی ثبت

پس هر پرتال در واقع یک انتقالِ کار است. و از همین‌جا معلوم می‌شود چه کاری ارزشِ پرتال دارد و چه کاری نه.

این سه اصطلاح مرتب جای هم به‌کار می‌روند و همین باعثِ سفارش‌های اشتباه می‌شود. تفکیکشان ساده است:

و نتیجه‌ی مهمی که از این تفکیک درمی‌آید: پرتال اغلب روی اتوماسیون می‌نشیند، نه به‌جای آن. اگر فرایندِ داخلی‌تان هنوز دستی و کاغذی است، پرتال فقط درخواست‌ها را سریع‌تر به همان صفِ دستی می‌ریزد — و مشکل را بدتر نشان می‌دهد، نه بهتر.

یک کار وقتی به پرتال می‌ارزد که هر سه شرط را داشته باشد:

  1. تکرارِ زیاد. کاری که ماهی دو بار پیش می‌آید، پرتال نمی‌خواهد.
  2. قاعده‌مند بودن. جوابش باید از قاعده دربیاید، نه از قضاوتِ یک آدم.
  3. دادهٔ موجود در سیستم. اگر جواب در سیستمی نیست که پرتال به آن دسترسی دارد، پرتال نمی‌تواند جواب بدهد.

شرطِ دوم مهم‌ترین و پرت‌شده‌ترین است. یک مثالِ نقض: استعلامِ قیمتِ یک پروژه‌ی سفارشی تکرارِ زیادی دارد و داده‌اش هم موجود است، ولی قاعده‌مند نیست — قیمت به مقدار و زمان‌بندی و شرایط بستگی دارد و کسی باید تصمیم بگیرد. پرتال این کار را خودکار نمی‌کند؛ فقط فرمش را آنلاین می‌کند و همان آدم باید جواب بدهد.

نکته

قاعده‌ی جمع‌بندی — پرتال کارِ قاعده‌مند را خودکار می‌کند و کارِ قضاوتی را فقط جابه‌جا می‌کند. جابه‌جاکردنش هم بی‌فایده نیست (ثبت می‌شود، گم نمی‌شود، سابقه دارد)، ولی انتظارِ کاهشِ بارِ کاری از آن نداشته باشید.

به‌جای «حجمِ درخواست زیاد است»، عدد بگذارید. حساب ساده است:

فرض کنید ماهی ۴۰۰ تماس فقط برای «وضعیتِ درخواستم چه شد؟» می‌گیرید و هر تماس با احتسابِ قطع‌شدنِ کارِ کارمند حدودِ ۴ دقیقه طول می‌کشد. یعنی حدودِ ۲۷ ساعت در ماه — تقریباً یک‌پنجمِ وقتِ یک نفرِ تمام‌وقت، صرفِ کاری که خودِ ذی‌نفع می‌توانست در ده ثانیه ببیند.

همین محاسبه را برای دو یا سه کارِ پرتکرارِ خودتان انجام دهید؛ جمعشان معمولاً از انتظار بزرگ‌تر است. ولی یک نکته را صادقانه بدانید: این ساعت‌ها آزاد می‌شوند، حذف نمی‌شوند. اگر از قبل تصمیم نگرفته باشید آن وقت کجا صرف شود، صرفه‌جویی روی کاغذ می‌ماند و کسی تفاوتی حس نمی‌کند. روشِ برآوردِ هزینه‌ی خودِ پروژه هم در برآوردِ هزینه‌ی نرم‌افزار اختصاصی آمده.

این بخش تفاوتِ پرتالِ زنده با پرتالِ خالی را می‌سازد.

کسی که نمی‌خواهد حضوری بیاید یا در صفِ تلفن بماند، خودش سراغِ پرتال می‌آید. پذیرش این‌جا آسان‌تر است، ولی یک شرطِ سخت دارد: باید بدونِ آموزش قابلِ استفاده باشد. کاربرِ بیرونی ممکن است سالی یک بار بیاید، راهنما نمی‌خواند و اگر گیر کند تلفن را برمی‌دارد — یعنی همان تماسی که می‌خواستید حذف کنید.

این حالتِ سخت است. کارمند روشِ فعلی را می‌شناسد و برایش کار می‌کند؛ پرتال از دیدِ او کارِ اضافه است، نه تسهیل. نتیجه‌اش پرتالی است که ساخته می‌شود و کسی از آن استفاده نمی‌کند.

راهِ حل یک جمله است: مسیرِ قدیمی باید بسته شود. تا وقتی می‌شود همان کار را با یک تماس یا یک کاغذ انجام داد، پرتال خالی می‌ماند — هر چقدر هم خوب ساخته شده باشد. پس در برنامه‌ی راه‌اندازی، «از تاریخِ فلان، این درخواست فقط از پرتال پذیرفته می‌شود» باید تصمیمِ روشنی باشد، نه توصیه.

دو کارِ کمکیِ دیگر: هر ثبت باید همان لحظه به خودِ ثبت‌کننده چیزی بدهد (کدِ رهگیری، تأییدِ دریافت، تخمینِ زمان)، و یک مسئولِ داخلی با اختیارِ تصمیم داشته باشید که سؤال‌ها روی زمین نمانند.

پرتال با داده‌ی واقعیِ آدم‌ها کار می‌کند، پس «ورودِ امن و پشتیبان‌گیری» حرفِ کلی کافی نیست. این چهار مورد پرتکرارترین‌اند:

  1. آدرسِ شماره‌ایِ قابلِ حدس. اگر صفحه‌ی پیگیری با نشانی‌ای مثل ?id=1043 باز می‌شود و کاربر با عوض‌کردنش به 1044 پرونده‌ی شخصِ دیگری را می‌بیند، شما داده‌ی همه‌ی کاربرانتان را با یک عددِ ساده افشا کرده‌اید. هر درخواست باید بررسی کند این پرونده مالِ همین کاربرِ وارد‌شده است. این شایع‌ترین ایرادِ امنیتیِ پرتال‌هاست.
  2. کدِ رهگیریِ ترتیبی. کدی که پشتِ سرِ هم شماره می‌خورد، هم قابلِ حدس است هم حجمِ کارِ شما را به رقیب می‌گوید. کدِ تصادفی بدهید.
  3. «همه همه‌چیز را ببینند» به‌عنوانِ پیش‌فرض. ساده‌ترین تنظیم در روزِ راه‌اندازی، و خطرناک‌ترین. دسترسی باید بر اساسِ نقش باشد و هر نقش فقط آن‌چه برای کارش لازم است ببیند.
  4. خروجیِ انبوهِ بی‌حساب. امکانِ گرفتنِ خروجیِ کلِ داده باید محدود و ثبت‌شده باشد؛ وگرنه کلِ پایگاهِ اطلاعاتِ شما یک کلیک فاصله دارد.

به این‌ها اضافه کنید ورودِ ساده و امن برای کاربرِ بیرونی (تأییدِ پیامکی معمولاً از رمزِ فراموش‌شدنی بهتر جواب می‌دهد)، اتصالِ امن و گواهیِ معتبر (اصولش)، و همان قواعدِ نگه‌داریِ داده‌ی کاربر که در الزامات قانونی آمده — از جمله این‌که هر نفر حسابِ کاربریِ خودش را داشته باشد، نه رمزِ مشترک.

حواستان باشد

و یک نکته‌ی ساختاری — پرتالی که به سیستم‌های واقعیِ سازمان وصل نیست، صندوقِ پستی است نه پرتال. اگر درخواست در پرتال ثبت شود و بعد کسی آن را دستی به سیستمِ دیگری وارد کند، شما یک مرحله اضافه کرده‌اید. ارزشِ پرتال در همین اتصال است.

  1. دو یا سه کارِ پرتکرارِ قاعده‌مند را انتخاب کنید — همان‌هایی که آزمونِ سه‌شرطی را رد می‌کنند. نه بیشتر.
  2. پیگیریِ وضعیت را اول بسازید. کم‌هزینه‌ترین و پرمصرف‌ترین قابلیت است و بیشترین تماس را حذف می‌کند.
  3. اتصال به سیستمِ مقصد را در فازِ اول ببینید، نه بعد — چون بدونِ آن پرتال صندوقِ پستی است.
  4. دسترسی‌های نقش‌محور و کدِ تصادفی را از روزِ اول، نه به‌عنوانِ بهبودِ بعدی.
  5. تاریخِ بستنِ مسیرِ قدیمی را تعیین کنید و اعلام کنید.

اگر مجموعه‌ی چندشرکتی دارید، جای پرتال در ساختارِ دامنه‌هایتان در سایت شرکتی یا هلدینگ توضیح داده شده — و همان‌جا گفته‌ایم که پرتالِ درون‌سازمانی معمولاً باید آخر از همه ساخته شود. نمونه‌های نزدیک هم: نوبت‌دهیِ آنلاین ساده‌ترین شکلِ خودخدمتیِ بیرونی است، مدیریتِ انبار نمونه‌ی سیستمِ مقصدی است که پرتال به آن وصل می‌شود، و برای مجموعه‌های صنعتی سایت کارخانه بخشِ رو‌به‌بیرونِ ماجرا را پوشش می‌دهد. ترتیبِ عملیِ سفارش هم در راهنمای سفارش نرم‌افزار هست.

هزینه‌ی کار در ادزو چقدر است؟
  • سایت فروشگاهیاز ۱۲٫۹ میلیون تومان
  • سایت شرکتی / خدماتیاز ۸٫۹ میلیون تومان
  • سئو (ماهانه)از ۷٫۹ میلیون تومان
دیدن جزئیات پکیج‌ها

سه چیز را ببرید. اول: پرتال یک نوعِ نرم‌افزار نیست، یک لایه‌ی دسترسی است — پس تصمیم این نیست که «بسازیم یا نه»، این است که «چه کاری را چه کسی خودش انجام دهد». دوم: کارِ قاعده‌مند خودکار می‌شود و کارِ قضاوتی فقط جابه‌جا؛ آزمونِ سه‌شرطی را قبل از هر قابلیت اجرا کنید. سوم: برای پرتالِ درونی، پذیرش خطرِ اصلی است و راهِ حلش بستنِ مسیرِ قدیمی است، نه آموزشِ بیشتر.

و یک سنجه‌ی ساده برای اینکه بدانید پرتالتان زنده است یا نه: چند درصدِ آن درخواست‌ها که قبلاً تلفنی می‌آمد، حالا از پرتال می‌آید؟ اگر این عدد بالا نمی‌رود، مسئله فنی نیست. امکانات و نمونه‌ها هم در صفحه‌ی طراحی پرتال سازمانی هست.

فهرستِ کارهای پرتکرارتان را با هم مرور کنیم و ببینیم کدامشان واقعاً به پرتال می‌ارزد.برآورد هزینه و زمان را در یک تماس کوتاه می‌گیرید.