نرمافزار سکتور عامه با وظیفه قانونی نهاد آغاز میشود
سیستم معلوماتی دولتی باید یک روند تأییدشده عامه را روشنتر، کنترولشدهتر و قابل نظارت بسازد. نقطه آغاز نمایش محصول نیست؛ بلکه وظیفه قانونی نهاد، بخشهای مسئول، کاربران، اسناد، تأییدیها، مسئولیت خدمات، سلسله گزارشدهی و تصمیمهایی است که سیستم باید پشتیبانی کند.
Fida Technologies میتواند MIS دولتی، پلتفرم اداری، رجستری، سیستم گردش کار، پورتال گزارشدهی و خدمات یکپارچهسازی را در صورتی ارزیابی و توسعه دهد که نهاد مسئول نیازمندیها را تعریف و تأیید کند. ما بهجای مرجع مسئول، قواعد پالیسی، حقوقی یا مقرراتی را فرض نمیکنیم.
مشکلات عملیاتی که سیستم عامه ممکن است حل کند
- فایل کاغذی، اکسل و دیتابیسهای جداگانه بخشها
- ثبت تکراری یک شخص، سازمان، دارایی، پروژه یا معامله
- مسئولیت نامشخص برای بررسی، تأیید، رد و اصلاح
- تأخیر گزارش میان مرکز، ولایت یا ولسوالی
- دید محدود بر بودجه، تدارکات، قرارداد، دارایی یا اجرای برنامه
- سیستمهای قدیمی که معلومات تأییدشده را بهصورت امن تبادله نمیکند
- درخواست عامه بدون مسیر روشن ثبت، وضعیت و پاسخ
مرحله شناخت باید پیش از پیشنهاد راهکار، موجودیت واقعی مشکل، علت آن و کاربران متأثر را تأیید کند.
قابلیتهای MIS دولتی و اداره داخلی
مطابق محدوده تأییدشده، پلتفرم سکتور عامه میتواند پلان، بودجه، مالی، تدارکات، موجودی، دارایی، منابع بشری، معلومات معاش، مکاتبات، اسناد، قرارداد، پروژه، تفتیش، شکایت، تأییدی و گزارش مدیریتی را وصل کند. هر ماژول به مسئول مشخص معلومات و مسئول روند نیاز دارد.
روند مالی و تدارکاتی باید از قواعدی پیروی کند که تیمهای مجاز مالی، تدارکات، حقوقی و تفتیش نهاد تأیید کردهاند. نرمافزار میتواند روند تأییدشده را اجرا و شواهد را حفظ کند؛ اما قاعده حاکم را مستقلانه تعیین نمیکند.
رجستری، جواز و مدیریت قضیه
پلتفرم رجستری یا مدیریت قضیه میتواند درخواست، نهاد، طبقهبندی، اسناد، تصدیق، مراحل بررسی، تصمیم، تمدید، تعلیق، تاریخچه وضعیت و گزارش مجاز را تنظیم کند. پیش از معماری باید ثبت مرجع، شناسه یکتا، مدیریت تکرار، حق اصلاح، مدت نگهداری و معلومات قابل تبادله تعریف شود.
خدمات دیجیتال عامه و پورتال نهادی
در صورت مناسب بودن، پورتال عامه میتواند معلومات روشن خدمت، فورم درخواست، اسناد لازم، شماره مرجع، بررسی وضعیت، اطلاعرسانی، وقت ملاقات، پرداخت از طریق ارائهکننده تأییدشده و مسیر بازخورد را فراهم کند. رابط عامه و روند داخلی باید یکجا طراحی شود تا پورتال به فورمی تبدیل نشود که کارمند دوباره آن را دستی ثبت کند.
رابط انگلیسی، دری و پشتو، چیدمان راستبهچپ، متن خوانا، دسترسی موبایل و کارکرد مناسب با انترنت ضعیف میتواند در صورت نیاز شامل شود. دسترسپذیری، تصدیق هویت و خدمت کمکی باید مطابق کاربران واقعی تأیید گردد.
حاکمیت معلومات و یکپارچهسازی
سیستمهای دولتی گاهی به تبادل معلومات میان بخشها یا پلتفرمهای مجاز نیاز دارد. پلان یکپارچهسازی باید منبع مرجع، مالک معلومات، هدف مجاز، فیلدهای مشترک، شناسه، اعتبارسنجی، احراز هویت، ثبت فعالیت، مدیریت خطا، دسترسپذیری و مسئول هر رابط را مشخص کند.
API نباید هر سند را برای هر سیستم باز کند. حداقلسازی معلومات، هدف مشخص و صلاحیت کنترولشده باید پیش از تبادله طراحی شود. معلومات مرجع، طبقهبندی و شناسه نیز به حاکمیت نیاز دارد تا گزارشها در زمان و موقعیت قابل مقایسه باشد.
امنیت، پاسخگویی و تداوم
- دسترسی مبتنی بر نقش مطابق مسئولیت رسمی
- تفکیک آمادهسازی، بررسی، تأیید و مدیریت
- تاریخچه فعالیت و audit log برای اقدامات حساس
- credentials محافظتشده، انتقال رمزگذاریشده و export کنترولشده
- محیط جداگانه توسعه، آزمایش و اصلی
- بکاپ، آزمایش بازیابی و مسئولیت مستند
- نظارت، نگهداری update و روش escalation رویداد
کنترول لازم به طبقهبندی معلومات، اهمیت خدمت، زیربنا و پالیسی امنیتی تأییدشده نهاد وابسته است. میزبانی میتواند در زیربنای دولت، میزبانی خصوصی تأییدشده، cloud یا محیط on-premise انجام شود، اگر معماری و شرایط تدارکات اجازه دهد.
آمادگی نیازمندی و تدارکات
RFP یا شرایط مرجع مفید باید مشکل تجارتی را از فهرست امکانات از قبل انتخابشده جدا کند. این سند میتواند افراد مسئول، سیستم فعلی، نیازمندی عملیاتی و غیرعملیاتی، یکپارچهسازی، انتقال معلومات، محیطها، امنیت، زبانها، اسناد، شرایط source code یا license، آموزش، پشتیبانی، SLA، پذیرش و تحویل نهایی را مشخص سازد.
ارزیابی باید فروشندگان را با معیارهای یکسان مستند مقایسه کند. نمایش باید از روندهای نمونه بدون افشای معلومات محافظتشده استفاده کند. فرضیه، موارد خارج، وابستگی و مسئولیتها باید در پیشنهاد تخنیکی و مالی روشن باشد.
تطبیق و مالکیت نهادی
- آغاز: حاکمیت، افراد مسئول، ارتباط، خروجی و صلاحیت تصمیم تأیید میشود.
- شناخت: روند فعلی، اسناد، کنترول، گزارش، زیربنا و محدودیت ادغام مستند میگردد.
- نیازمندی و معماری: روند، معلومات، امنیت، نصب، انتقال و معیار پذیرش توافق میشود.
- تحویل مرحلهای: نسخههای قابل بررسی به مسئولان روند نمایش و تصمیمهای تأییدشده ثبت میشود.
- انتقال و ادغام: معلومات پاک، نقشه، آزمایش و مطابقت و هر رابط مجاز تأیید میشود.
- QA و UAT: کار عادی، استثنا، صلاحیت، گزارش، سرعت و بازیابی آزمایش میگردد.
- آموزش و تحویل: اډمین، کاربران، اسناد، دسترسی اصلی و مسیر پشتیبانی آماده میشود.
- عملیات: مسئولیت نگهداری، نظارت، رویداد و SLA تطبیق میگردد.
مالکیت نهادی تنها دریافت source code یا رمز اډمین نیست. نهاد به مسئول محصول و معلومات، متخصص روند، تنظیمات مستند، اډمین آموزشدیده، دسترسی به معلومات و روند پایدار مدیریت تغییر نیاز دارد.
دعوت فیدا به تدارکات تکنالوژی دولتی
concept note، RFP، شرایط مرجع یا مشکل عملیاتی تأییدشده را شریک سازید. فیدا میتواند بررسی کند همکاری به تحلیل نیازمندی، توسعه MIS، یکپارچهسازی، انتقال معلومات، پورتال عامه یا پلتفرم مرحلهای نیاز دارد. هر پیشنهاد بر اساس محدوده و شرایط تدارکاتی تأییدشده تهیه میشود.