یکی از نشانههای ساده اما مهم ضعف خدمات دیجیتال این است که کاربر مجبور باشد اطلاعاتی را که دولت از قبل در اختیار دارد، دوباره وارد کند. شماره ملی، مشخصات هویتی، نشانی، اطلاعات سازمانی یا مدارکی که پیشتر در یک سامانه ثبت شدهاند، گاهی در سامانهای دیگر دوباره از همان فرد خواسته میشوند؛ انگار هر سامانه از نقطه صفر با کاربر آشنا میشود.
اصل Once-Only دقیقاً از همین مسئله آغاز میشود: اگر یک داده معتبر قبلاً در اختیار بخش عمومی قرار گرفته و امکان قانونی و فنی استفاده مجدد از آن وجود دارد، چرا مسئولیت انتقال دوباره آن باید بر دوش شهروند، کارمند یا مدیر محلی باشد؟
در دولت دیجیتال واقعی، کاربر نباید نقش «واسط انتقال داده» میان سامانههای مختلف دولت را بازی کند. این سامانهها هستند که باید بتوانند با رعایت سطح دسترسی و الزامات امنیتی، اطلاعات مورد نیاز را از منابع معتبر دریافت کنند.
اصل Once-Only چیست؟
Once-Only Principle یا «اصل یک بار ارائه اطلاعات» یکی از مفاهیم مهم در طراحی خدمات عمومی دیجیتال است. در سادهترین تعریف، شهروندان و کسبوکارها نباید مجبور باشند اطلاعات استانداردی را که قبلاً در اختیار یک نهاد عمومی قرار دادهاند، مرتباً به نهادهای دیگر ارائه کنند.
در این مدل، داده از منبع معتبر خود دریافت میشود و در صورت وجود مبنای قانونی و دسترسی مجاز، برای ارائه خدمت دیگری مورد استفاده قرار میگیرد.
Once-Only را میتوان اینطور خلاصه کرد: «دولت اطلاعاتی را که خودش دارد، دوباره از مردم نپرسد.»
اما همین جمله ساده، پیامدهای بزرگی در معماری سامانهها دارد.
Once-Only با ورود یکپارچه یا SSO یکسان نیست. SSO تعداد دفعات احراز هویت کاربر را کاهش میدهد؛ Once-Only تعداد دفعاتی را که کاربر مجبور است یک داده یا مدرک واحد را دوباره ارائه کند.
مشکل فقط چند دقیقه وقت کاربر نیست
شاید در نگاه اول، وارد کردن دوباره چند فیلد اطلاعاتی مسئله بزرگی به نظر نرسد. اما وقتی این رفتار در صدها خدمت، هزاران سازمان و میلیونها درخواست تکرار شود، با یک مسئله ساختاری روبرو هستیم.
فرض کنیم دهیار یک بار اطلاعات مربوط به مشخصات دهیاری، حسابهای بانکی، جمعیت روستا یا اطلاعات هویتی خود را در یک سامانه ثبت کرده است. اگر برای هر فرایند جدید دوباره همان اطلاعات از او خواسته شود، سه اتفاق میافتد:
بخشی از زمان کاربر صرف کاری میشود که هیچ ارزش جدیدی تولید نمیکند.
نسخههای مختلفی از یک داده در سامانههای مختلف ایجاد میشود و منابع به هدر میرود.
احتمال مغایرت بالا میرود. ممکن است شماره تماس در یک سامانه بهروز شده باشد اما در سامانه دیگر همچنان نسخه قدیمی باقی مانده باشد.
بنابراین مسئله Once-Only فقط «راحتترشدن فرمها» نیست؛ مسئله، کیفیت معماری اطلاعات است.
مطالعات اتحادیه اروپا نیز Once-Only را یکی از ابزارهای کاهش بار اداری قلمداد میکنند زیرا بهجای آن که یک شهروند یا کسبوکار اطلاعات را میان دستگاهها جابجا کند، دستگاههای عمومی مسئول استفاده مجدد و تبادل اطلاعات میشوند.
قاعده «یک بار ورود اطلاعات» در ایران
این مفهوم در مقررات دولت الکترونیکی ایران نیز بهصراحت دیده میشود.
در مصوبه شورای اجرایی فناوری اطلاعات درباره پنجره ملی خدمات دولت هوشمند، بر رعایت «اصل یک بار ورود اطلاعات» تأکید شده است. در دستورالعمل اجرایی بعدی نیز ماده ۳۱ دستگاههای اجرایی را مکلف میکند با استفاده از دادههای پایگاههای اطلاعات پایه و با «حداکثر یک بار ورود داده و اطلاعات اشخاص»، از دریافت تکراری و غیرضروری اطلاعات خودداری کنند. ماده ۳۲ همان دستورالعمل نیز حذف اخذ مکرر مدارک، رونوشتها و مستندات غیرالکترونیکی را هدف قرار میدهد.
این جهتگیری با قانون مدیریت دادهها و اطلاعات ملی نیز همسو است. در این قانون، «مرکز ملی تبادل اطلاعات» بهعنوان بستر تبادل داده میان دستگاههای مشمول تعریف شده و بر یکپارچگی، بهروزرسانی و تبادل نظاممند داده تأکید شده است.
در نتیجه، Once-Only در ایران را نمیتوان صرفاً یک تجربه اروپایی دانست. منطق اصلی آن در معماری دولت هوشمند کشور نیز قابل مشاهده است.
پشت هر فرم ساده، مسئله «منبع معتبر داده» قرار دارد
فرض کنیم سامانهای قرار است تاریخ تولد فرد را نمایش دهد. روش ساده این است که یک کادر ایجاد کنیم و از کاربر بخواهیم تاریخ تولدش را وارد کند.
اما در معماری Once-Only سؤال دیگری مطرح میشود: «مرجع رسمی این داده کجاست؟»
اگر این اطلاعات در یک پایگاه اطلاعات پایه معتبر وجود دارد، ایجاد یک نسخه مستقل از همان داده در هر سامانه میتواند منبع اختلاف باشد.
همین مسئله درباره اطلاعات سازمانی، نشانی، مشخصات جغرافیایی، شناسه اشخاص حقوقی و بسیاری از دادههای دیگر نیز وجود دارد.
به همین دلیل یکی از پیشنیازهای Once-Only، تعیین Authoritative Source یا منبع معتبر هر داده است.
سامانه خدمتدهنده لازم نیست مالک همه دادههایی باشد که نمایش میدهد. گاهی وظیفه آن فقط این است که بداند داده معتبر را از کجا، با چه مجوزی و در چه زمانی دریافت کند.
Once-Only یعنی تبادل داده، نه تکثیر بیپایان داده
یک برداشت اشتباه این است که برای اجرای Once-Only، همه سازمانها باید تمام اطلاعات یکدیگر را در پایگاههای خود کپی کنند.
چنین معماریای حتی میتواند مشکل را بدتر کند. اگر ده سامانه هرکدام یک نسخه از اطلاعات یک فرد داشته باشند، مشخص نیست پس از تغییر اطلاعات کدام نسخه معتبر است.
مدل مطلوبتر معمولاً بر ارتباط با منابع معتبر تکیه میکند:
این یعنی تعاملپذیری بهجای کپیکاری.
هدف Once-Only ساخت یک پایگاه عظیم حاوی همه اطلاعات نیست؛ هدف این است که هر داده منبع معتبر خود را داشته باشد و سامانههای مجاز بتوانند در زمان نیاز به آن دسترسی پیدا کنند.
Once-Only به معنای دسترسی آزاد همه دستگاهها نیست
اینجا یکی از مهمترین مرزهای این مفهوم قرار دارد. این که دولت اطلاعاتی را قبلاً دریافت کرده، به این معنا نیست که هر سامانه و هر کارمند دولتی باید بتواند به آن دسترسی داشته باشد.
پیادهسازی درست Once-Only به همان اندازه که مسئله تعاملپذیری است، مسئله حکمرانی دسترسی نیز هست.
باید مشخص باشد چه دستگاهی مالک یا متولی داده است، کدام دستگاه مجاز به دریافت آن است، برای چه هدفی داده دریافت میشود، چه اقلامی واقعاً برای آن خدمت لازماند، دسترسی چگونه ثبت و ممیزی میشود و داده چه مدت نگهداری خواهد شد.
در مدل اروپایی OOTS نیز تبادل داده و مدارک بر مبنای درخواست کاربر و در چارچوب امنیتی و قانونی مشخص انجام میشود؛ یعنی Once-Only با حذف کنترل کاربر یا نادیدهگرفتن حفاظت از داده مترادف نیست.
چرا اجرای Once-Only دشوار است؟
حذف یک فیلد از فرم ساده است. ساخت زیرساختی که واقعاً بتوان آن فیلد را حذف کرد، بسیار دشوارتر است. برای نمونه باید بتوان پاسخ داد:
بنابراین Once-Only پروژهای برای «کوتاهکردن فرم» نیست. اجرای واقعی آن نیازمند معماری داده، استاندارد مشترک، API، احراز هویت، کنترل دسترسی، ثبت رویداد و حکمرانی مشخص است.
مسئله در مدیریت روستایی ملموستر میشود
مدیریت روستایی بهطور طبیعی با سطوح مختلف سازمانی در ارتباط است: دهیاری، بخشداری، فرمانداری، استانداری، دستگاههای ملی و مجموعهای از سامانههای تخصصی. در چنین محیطی، خطر ورود چندباره داده بسیار بالاست.
احتمال دارد اطلاعات یک روستا ابتدا در سطح دهیاری ثبت شود، سپس برای گزارشی در بخشداری دوباره جمعآوری شود، در سطح استان در فایل دیگری تجمیع شود و برای یک فرایند ملی بار دیگر درخواست شود.
اینجا اصل Once-Only معنای مهمتری پیدا میکند:
اگر اطلاعات معتبر یک بار در نزدیکترین نقطه به منبع تولید شده است، چرا باید همان داده در هر سطح مدیریتی دوباره تولید شود؟
در معماری مطلوب، داده میتواند در محل درست خود ثبت شود و سطوح بالاتر، متناسب با مأموریت و سطح دسترسی، از همان جریان داده استفاده کنند.
این مسئله با رویکردی که در مطالعات اولیه سماد نیز بر یکپارچگی داده و اتصال جریان اطلاعات از سطح دهیاری تا بخشداری و استان تأکید داشته، همجهت است.
یک مثال ساده؛ اطلاعات روستا
فرض کنیم مشخصات پایه یک روستا شامل کد روستا، موقعیت جغرافیایی، جمعیت، بخش، شهرستان و استان در یک منبع معتبر وجود دارد.
در مدل سنتی هر سامانهای فرم خودش را میسازد و اطلاعات لازم را از کاربر میگیرد، شامل نام روستا، استان، شهرستان و جمعیت.
یعنی کاربر عملاً بخشی از پایگاه داده دولت را با دست بازسازی میکند.
در مدل Once-Only، پس از انتخاب یا احراز هویت واحد مربوط، بخش اعظم اطلاعات میتواند از منبع معتبر فراخوانی شود.
در حالت مطلوب، کاربر عمدتاً اطلاعاتی را وارد میکند که در همان فرایند جدید تولید میشوند یا نیازمند تأیید او هستند.
این تغییر کوچک در ظاهر، تفاوت بزرگی در فلسفه طراحی سامانه ایجاد میکند: فرم دیگر نقطه جمعآوری همه اطلاعات نیست؛ بخشی از یک شبکه داده است.
نقش API و تعاملپذیری
Once-Only بدون تعاملپذیری عملاً قابلاجرا نیست.
اگر سامانهها نتوانند به زبان مشترک با یکدیگر صحبت کنند، حتی اگر همه اطلاعات مورد نیاز در دولت وجود داشته باشد، کاربر همچنان مجبور خواهد بود آنها را دستی منتقل کند.
به همین دلیل API، استاندارد داده و زیرساخت تبادل اطلاعات جزئیات فنی حاشیهای نیستند؛ مستقیماً بر تجربه شهروند اثر میگذارند.
وقتی کاربر از تکرار یک فیلد در فرم خلاص میشود، ممکن است پشت همان حذف ساده چندین سرویس، استاندارد داده، کنترل دسترسی و ارتباط بینسامانهای فعالیت کنند.
این شاید یکی از بهترین مثالها برای تفاوت «دیجیتالیکردن خدمت» و «طراحی دولت دیجیتال» باشد.
آیا همه اطلاعات باید Once-Only باشند؟
خیر. اصل Once-Only را هم نباید افراطی تفسیر کرد.
بعضی اطلاعات ذاتاً مربوط به همان درخواست خاص هستند و باید هر بار تولید شوند. توضیح یک حادثه، گزارش وضعیت فعلی پروژه، مبلغ پیشنهادی یک قرارداد یا پاسخ یک پرسش تخصصی را نمیتوان صرفاً از یک پایگاه پایه دریافت کرد.
گاهی نیز لازم است کاربر اطلاعات قبلی را تأیید یا بروزرسانی کند. بنابراین سؤال درست این نیست که چطور تمام فرم را حذف کنیم؟ بلکه:
کدام داده واقعاً باید از کاربر خواسته شود و کدام داده را سیستم میتواند از یک منبع معتبر به دست آورد؟
همین سؤال ساده میتواند کیفیت طراحی بسیاری از خدمات دیجیتال را تغییر دهد.
جمعبندی
«یک بار ثبت، چند بار استفاده» شاید یکی از سادهترین جملات در ادبیات دولت دیجیتال باشد، اما اجرای آن نیازمند بلوغ قابلتوجه در معماری سامانههاست.
اصل Once-Only همزمان چند مسئله را هدف قرار میدهد: کاهش بار اداری، سادهترشدن خدمات، کاهش ورود دستی اطلاعات، ارتقای کیفیت داده، کاهش نسخههای متناقض و تقویت تعاملپذیری میان دستگاهها.
اما ارزش اصلی آن شاید در تغییر زاویه نگاه باشد.
در طراحی سنتی، سؤال این است: در این فرم چه اطلاعاتی از کاربر بگیریم؟
در طراحی مبتنی بر Once-Only، سؤال قبل از آن مطرح میشود: کدامیک از این اطلاعات را دولت از قبل بهصورت معتبر در اختیار دارد؟
همین تغییر سؤال، مرز میان یک فرم الکترونیکی و یک خدمت واقعاً دیجیتال را مشخص میکند.
شرکت دانشبنیان تدبیرنگر، توسعهدهنده راهکارهای هوشمند، سامانههای اتوماسیون و خدمات یکپارچه دیجیتال در مسیر تحول و توانمندسازی سازمانی کارآمد.
آدرس
ارومیه – خیابان برق از سمت بلوار شهید بهشتی، کوچه ۳، پلاک ۱۲
ایمیل
hello@tadbirnegar.ir
tadbirnegar.com@gmail.com
