یک پرونده، چند واحد؛ اطلاعات چگونه باید در شهرداری جریان داشته باشد؟
در یک شهرداری، بسیاری از پرونده‌ها فقط به یک واحد سازمانی مربوط نمی‌شوند. یک پرونده ملکی ممکن است از شهرسازی شروع شود، به درآمد برسد، با نوسازی ارتباط پیدا کند، اطلاعات مکانی آن در GIS ثبت شود، بخشی از آن به کمیسیون‌ها مرتبط باشد و در نهایت اطلاعات مورد نیاز آن در خدمات شهروندی یا داشبورد مدیریتی مورد استفاده قرار گیرد.
اما یک سؤال اساسی وجود دارد: اگر یک پرونده میان چند واحد جریان دارد، آیا اطلاعات آن هم باید هر بار از ابتدا در هر واحد ثبت شود؟ پاسخ، در یک معماری یکپارچه شهری، خیر است.
هدف مدیریت دیجیتال و یکپارچه در شهرداری این است که اطلاعات یک پرونده، یک بار و در جای درست ثبت شود و سپس در طول فرآیند، به شکل کنترل‌شده و امن در اختیار واحدهای مجاز قرار گیرد.
در این مقاله بررسی می‌کنیم یک پرونده شهری چگونه باید میان واحدهای مختلف جریان داشته باشد، چه مشکلاتی در مدل جزیره‌ای ایجاد می‌شود و چگونه می‌توان با یکپارچه‌سازی سامانه‌ها، تبادل اطلاعات و ایجاد مرجع معتبر داده، فرآیندها را ساده‌تر و دقیق‌تر کرد.
یک پرونده شهری چرا به چند واحد مرتبط می‌شود؟
شهرداری یک سازمان تک‌واحدی نیست. فرآیندهای شهری معمولاً به یکدیگر وابسته‌اند. برای مثال، یک ملک می‌تواند هم‌زمان اطلاعاتی در حوزه‌های زیر داشته باشد:
- اطلاعات شهرسازی
- اطلاعات مالک
- اطلاعات ملک
- اطلاعات مکانی
- سوابق نوسازی
- بدهی و عوارض
- پروانه ساختمانی
- پایان کار
- تخلفات
- کمیسیون‌ها
- درخواست‌های شهروندی
- اسناد و مدارک
- سوابق پرداخت
بنابراین اگر هر واحد فقط اطلاعات خودش را ببیند و اطلاعات مورد نیاز را دوباره ثبت کند، سازمان عملاً با چند نسخه از یک پرونده مواجه خواهد شد. در مقابل، در یک سیستم یکپارچه، پرونده می‌تواند یک جریان اطلاعاتی مشترک داشته باشد.
منظور از «جریان اطلاعات» در شهرداری چیست؟
جریان اطلاعات یعنی داده از زمان ایجاد تا زمان استفاده، اصلاح، تحلیل و بایگانی، مسیر مشخص و کنترل‌شده‌ای داشته باشد. برای یک پرونده شهری می‌توان این مسیر را به شکل زیر تصور کرد:
ایجاد پرونده → ثبت اطلاعات → بررسی → ارجاع → استفاده توسط واحدهای مرتبط → به‌روزرسانی → ثبت سوابق → گزارش‌گیری → بایگانی
در این مدل، اطلاعات نباید بدون کنترل بین سامانه‌ها کپی شود. بلکه باید مشخص باشد:
- اطلاعات از کجا ایجاد شده؟
- چه کسی آن را ثبت کرده؟
- مرجع اصلی داده کدام است؟
- چه واحدهایی به آن نیاز دارند؟
- چه اطلاعاتی باید منتقل شود؟
- چه کسی اجازه تغییر دارد؟
- تغییرات چگونه ثبت می‌شوند؟
این موارد پایه یک جریان اطلاعاتی قابل اعتماد هستند.
مدل سنتی: هر واحد یک نسخه از پرونده
در بسیاری از سازمان‌ها، مدل سنتی به شکل زیر است: شهرسازی → ثبت اطلاعات
سپس: درآمد → ثبت مجدد اطلاعات
بعد: نوسازی → ثبت مجدد
و در ادامه: GIS → ایجاد اطلاعات جداگانه
یا: خدمات شهروندی → دریافت دوباره اطلاعات
در ظاهر، هر واحد سیستم خودش را دارد.
اما در سطح سازمان، یک مشکل ایجاد شده است: یک پرونده، چند نسخه
هر بار که اطلاعات مجدداً وارد می‌شود، احتمال ایجاد تفاوت میان نسخه‌ها افزایش پیدا می‌کند.
مثلاً: مساحت ملک در شهرسازی: ۵۰۰ متر
درآمد: ۴۸۰ متر
نوسازی: ۵۲۰ متر
در این شرایط، مدیر یا کارشناس قبل از انجام هر کاری باید بررسی کند: کدام اطلاعات معتبر است؟
مشکل اصلی فقط دوباره‌کاری نیست
وقتی اطلاعات بین واحدها جریان مناسبی نداشته باشد، مشکلات فقط به ورود مجدد داده محدود نمی‌شوند.
۱. مغایرت اطلاعات
نسخه‌های مختلف پرونده ممکن است با هم تفاوت داشته باشند.
۲. افزایش زمان رسیدگی
کارشناس برای پیدا کردن اطلاعات باید با واحدهای دیگر تماس بگیرد یا اطلاعات را دوباره بررسی کند.
۳. افزایش خطای انسانی
هر بار ورود مجدد داده، یک نقطه جدید برای اشتباه ایجاد می‌کند.
۴. کاهش شفافیت فرآیند
مشخص نیست پرونده در چه مرحله‌ای قرار دارد و آخرین اقدام توسط چه واحدی انجام شده است.
۵. دشواری گزارش‌گیری
مدیر نمی‌تواند به‌راحتی یک تصویر کامل از وضعیت پرونده به دست آورد.
۶. وابستگی به افراد
اگر اطلاعات در فایل‌های شخصی، پوشه‌ها یا سیستم‌های جداگانه باشد، دسترسی به اطلاعات ممکن است به حضور یک کارشناس خاص وابسته شود.
یک پرونده باید چگونه در شهرداری جریان داشته باشد؟
در یک معماری مناسب، جریان پرونده باید بر اساس فرآیند واقعی سازمان طراحی شود، نه صرفاً بر اساس ساختار نرم‌افزارها. یک نمونه ساده:
شهروند / کارشناس → ایجاد پرونده → شهرسازی → درآمد → نوسازی → کمیسیون در صورت نیاز → نتیجه → خدمات شهروندی
اما در پشت این جریان، داده‌های مشترک باید میان واحدها قابل دسترسی باشند. برای مثال، اگر پرونده مربوط به یک ملک است، مشخصات پایه ملک نباید در هر واحد دوباره ایجاد شود.
اصل مهم: «یک بار ثبت، چند بار استفاده»
یکی از مهم‌ترین اصول در مدیریت اطلاعات شهری این است: اطلاعات باید تا حد امکان یک بار در نقطه مناسب ثبت شود و سپس توسط واحدهای مجاز مورد استفاده قرار گیرد.
این اصل می‌تواند بخش قابل توجهی از دوباره‌کاری‌های اطلاعاتی را کاهش دهد. برای مثال، اگر مشخصات پایه یک ملک قبلاً ثبت شده باشد، واحد درآمد نباید دوباره همان مشخصات را از ابتدا وارد کند. بلکه باید بتواند اطلاعات معتبر مورد نیاز خود را دریافت کند.
چه اطلاعاتی باید میان واحدها جریان داشته باشد؟
همه اطلاعات یک پرونده الزاماً نباید در اختیار همه واحدها قرار بگیرد. این نکته بسیار مهم است. جریان اطلاعات باید بر اساس نیاز سازمانی و سطح دسترسی طراحی شود. برای مثال:
شهرسازی
ممکن است به اطلاعات:
- ملک
- مالک
- کاربری
- مساحت
- پروانه
- پایان کار
- ضوابط
- سوابق پرونده
نیاز داشته باشد.
درآمد
ممکن است به:
- شناسه ملک
- مالک
- کاربری
- مساحت
- اطلاعات مؤثر بر محاسبه عوارض
- سوابق بدهی و پرداخت
نیاز داشته باشد.
GIS
ممکن است به:
- شناسه ملک
- موقعیت مکانی
- هندسه
- کاربری
- لایه‌های مکانی مرتبط
نیاز داشته باشد.
خدمات شهروندی
ممکن است به:
- وضعیت پرونده
- درخواست‌ها
- مراحل انجام کار
- پاسخ‌ها
- اطلاعات مورد نیاز شهروند
دسترسی داشته باشد.
بنابراین هدف: اشتراک‌گذاری کنترل‌شده اطلاعات است، نه دسترسی نامحدود همه به همه داده‌ها.
مرجع اصلی اطلاعات کجاست؟
یکی از مهم‌ترین سؤالات در یکپارچه‌سازی پرونده‌های شهری این است: کدام سامانه مرجع اصلی هر اطلاعات است؟ برای مثال:
- اطلاعات مکانی → GIS
- اطلاعات تخصصی پرونده شهرسازی → سامانه شهرسازی
- اطلاعات درآمدی → سامانه درآمد
- اطلاعات اسناد → سامانه مدیریت اسناد
- اطلاعات درخواست شهروندی → سامانه خدمات شهروندی
ممکن است معماری هر شهرداری متفاوت باشد. اما باید برای هر نوع داده، مرجع مشخص وجود داشته باشد. این موضوع با مفهوم Single Source of Truth ارتباط مستقیم دارد.
یک پرونده، یک شناسه
یکی از پایه‌های مهم جریان اطلاعات، وجود شناسه‌های یکتا است. برای مثال در پرونده‌های مرتبط با ملک، یک شناسه مشخص می‌تواند به ارتباط میان سامانه‌های مختلف کمک کند.
به جای اینکه هر سامانه برای یک ملک شناسه متفاوت ایجاد کند، می‌توان از شناسه مشترک برای ارتباط میان اطلاعات استفاده کرد.
در نتیجه: شناسه ملک → شهرسازی → درآمد → نوسازی → GIS → گزارش مدیریتی
به جای اینکه هر واحد پرونده‌ای کاملاً جداگانه ایجاد کند، اطلاعات می‌تواند حول یک موجودیت مشترک جریان داشته باشد.
نقش API در جریان اطلاعات شهری
برای اینکه اطلاعات بتواند بین سامانه‌های مختلف حرکت کند، باید راه ارتباطی استاندارد وجود داشته باشد. یکی از ابزارهای مهم در این زمینه API است.
برای مثال: سامانه درآمد → درخواست اطلاعات ملک → API → سامانه مرجع → پاسخ → محاسبه عوارض
در این مدل، سامانه درآمد الزاماً مجبور نیست تمام اطلاعات ملک را در پایگاه داده خودش نگهداری کند. می‌تواند اطلاعات مورد نیاز را از مرجع معتبر دریافت کند.
این معماری می‌تواند به کاهش:
- کپی اطلاعات
- ورود مجدد
- مغایرت
- خطای انسانی
کمک کند.
تفاوت «تبادل اطلاعات» با «کپی اطلاعات»
این دو مفهوم نباید با یکدیگر اشتباه گرفته شوند.
کپی اطلاعات
یعنی داده از یک سامانه گرفته شود و یک نسخه مستقل و جداگانه در سامانه دیگر ذخیره شود. در این حالت احتمال قدیمی شدن نسخه دوم وجود دارد.
تبادل اطلاعات
یعنی سامانه‌ها بتوانند اطلاعات مورد نیاز خود را از منبع معتبر دریافت کنند یا تغییرات لازم را به شکل کنترل‌شده منتقل کنند. هدف معماری یکپارچه این نیست که تمام اطلاعات در همه سامانه‌ها کپی شود.
بلکه باید مشخص شود: چه داده‌ای، از چه منبعی، برای چه فرآیندی و با چه سطح دسترسی منتقل شود.
مثال واقعی: پرونده یک ملک در شهرداری
برای درک بهتر موضوع، یک پرونده فرضی را دنبال کنیم. فرض کنید شهروند برای یک ملک درخواست ساختمانی ثبت می‌کند.
مرحله اول: ایجاد پرونده
پرونده در سامانه شهرسازی ایجاد می‌شود. اطلاعات اولیه ثبت می‌شود:
- مشخصات ملک
- مالک
- موقعیت
- کاربری
- مشخصات پرونده
مرحله دوم: بررسی اطلاعات
کارشناس شهرسازی اطلاعات پرونده را بررسی می‌کند. در صورت نیاز، اطلاعات مکانی از GIS دریافت می‌شود.
مرحله سوم: ارتباط با درآمد
پس از رسیدن پرونده به مرحله مرتبط، اطلاعات مورد نیاز برای محاسبه عوارض در اختیار سامانه درآمد قرار می‌گیرد. درآمد نباید مجبور باشد اطلاعات پایه پرونده را از ابتدا وارد کند.
مرحله چهارم: نوسازی
اگر فرآیند پرونده به اطلاعات نوسازی نیاز داشته باشد، سامانه مربوطه می‌تواند اطلاعات مورد نیاز خود را از منابع معتبر دریافت کند.
مرحله پنجم: کمیسیون
اگر پرونده به کمیسیون ارجاع شود، سوابق و اطلاعات لازم باید همراه پرونده در دسترس قرار گیرد. کارشناس نباید مجبور باشد اطلاعات را از چند سیستم جداگانه جمع‌آوری کند.
مرحله ششم: خدمات شهروندی
شهروند بتواند وضعیت پرونده را از مسیر خدمات الکترونیکی مشاهده کند.
مثلاً: ثبت شد → در حال بررسی → ارجاع به واحد مربوطه → محاسبه → پرداخت → تکمیل
مرحله هفتم: گزارش مدیریتی
مدیر بتواند بدون بررسی دستی چندین سامانه، وضعیت کلی پرونده‌ها را مشاهده کند. برای مثال:
- تعداد پرونده‌های فعال
- متوسط زمان رسیدگی
- پرونده‌های متوقف
- پرونده‌های دارای نقص
- میزان درآمد مرتبط
- تعداد ارجاعات
در این مدل چه چیزی تغییر کرده است؟
در مدل سنتی: پرونده بین واحدها جابه‌جا می‌شود.
اما اطلاعات آن ممکن است بارها دوباره ثبت شود.
در مدل یکپارچه: پرونده و اطلاعات مرتبط با آن در یک جریان سازمانی حرکت می‌کنند.
واحدها بر اساس نقش خود به داده‌های مورد نیاز دسترسی دارند. این تفاوت بسیار مهم است.
پرونده دیجیتال فقط اسکن مدارک نیست
یکی از برداشت‌های اشتباه درباره دیجیتالی شدن پرونده‌ها این است که اگر اسناد کاغذی اسکن شوند، پرونده الکترونیکی ایجاد شده است. در حالی که اسکن فقط یکی از مراحل دیجیتالی‌سازی است. یک پرونده الکترونیکی واقعی باید بتواند:
- اطلاعات ساختاریافته داشته باشد.
- اسناد مرتبط را نگهداری کند.
- وضعیت پرونده را مشخص کند.
- گردش کار داشته باشد.
- سوابق اقدامات را ثبت کند.
- دسترسی کاربران را کنترل کند.
- با سامانه‌های دیگر ارتباط داشته باشد.
- قابل جست‌وجو و گزارش‌گیری باشد.
به همین دلیل، مدیریت الکترونیکی پرونده باید بخشی از معماری اطلاعات سازمان باشد.
نقش GIS در جریان اطلاعات پرونده
یکی از مزیت‌های مهم یکپارچه‌سازی این است که پرونده‌های شهری می‌توانند با اطلاعات مکانی ارتباط داشته باشند. برای مثال، با انتخاب یک ملک روی نقشه می‌توان به اطلاعات مرتبط با آن دسترسی پیدا کرد.
این ارتباط میان: نقشه + ملک + پرونده + مالک + کاربری + درآمد + سوابق
می‌تواند تصویر کامل‌تری از وضعیت یک موجودیت شهری ایجاد کند. در این مدل GIS فقط یک نقشه نیست؛ بلکه بخشی از جریان اطلاعات شهری است.
جریان اطلاعات و کاهش زمان انجام فرآیندها
وقتی اطلاعات میان واحدها به صورت خودکار و کنترل‌شده جریان داشته باشد، بخشی از زمان تلف‌شده در فرآیندهای سنتی کاهش پیدا می‌کند. در مدل سنتی ممکن است کارشناس برای دریافت اطلاعات:
تماس → درخواست → انتظار → دریافت فایل → بررسی → ورود مجدد
را طی کند.
در مدل یکپارچه: درخواست سیستم → دریافت اطلاعات معتبر → ادامه فرآیند
این تغییر می‌تواند زمان انجام فرآیند را کاهش دهد.
جریان اطلاعات و کاهش دوباره‌کاری
یکی از شاخص‌های مهم در پروژه‌های یکپارچه‌سازی، بررسی میزان ورود مجدد اطلاعات است. اگر اطلاعات یک پرونده چندین بار توسط واحدهای مختلف وارد شود، سازمان هزینه پنهانی ایجاد کرده است. این هزینه فقط هزینه نرم‌افزار نیست. شامل:
- زمان کارشناسان
- خطاهای انسانی
- اصلاح اطلاعات
- تماس‌های داخلی
- تأخیر پرونده
- مغایرت گزارش‌ها
نیز می‌شود.
بنابراین کاهش دوباره‌کاری یکی از نتایج مهم جریان صحیح اطلاعات است.
جریان اطلاعات و شفافیت فرآیند
در یک سیستم یکپارچه باید بتوان فهمید:
- پرونده کجاست؟
- چه کسی روی آن کار می‌کند؟
- آخرین اقدام چه بوده؟
- مرحله بعدی چیست؟
- پرونده چه مدت در هر مرحله مانده است؟
- آیا اطلاعات ناقص است؟
- آیا اقدامی معطل مانده است؟
این اطلاعات می‌توانند پایه ایجاد مدیریت عملکرد و داشبورد مدیریتی باشند.
امنیت در جریان اطلاعات شهری
هرچه اطلاعات بیشتری میان سامانه‌ها جریان داشته باشد، اهمیت امنیت بیشتر می‌شود. بنابراین جریان اطلاعات نباید به معنای انتقال بدون محدودیت داده باشد.
باید مواردی مانند:
- احراز هویت
- کنترل دسترسی
- سطح‌بندی کاربران
- رمزنگاری
- ثبت رویدادها
- کنترل APIها
- ثبت تاریخچه تغییرات
- پشتیبان‌گیری
- مانیتورینگ
در نظر گرفته شود.
برای مثال ممکن است واحد درآمد فقط به اطلاعات خاصی از پرونده نیاز داشته باشد و نیازی به مشاهده تمام اسناد محرمانه پرونده نداشته باشد. پس اصل مهم: هر کاربر و هر سامانه، فقط به اطلاعات مورد نیاز و مجاز خود دسترسی داشته باشد.
چه کسی می‌تواند اطلاعات را تغییر دهد؟
این سؤال نیز باید از ابتدا مشخص شود. فرض کنید اطلاعات پایه ملک در چند سامانه قابل ویرایش باشد. اگر یک کارشناس در شهرسازی، فردی در درآمد و شخص دیگری در نوسازی بتوانند همان اطلاعات را تغییر دهند، کنترل داده دشوار خواهد شد.
به همین دلیل باید مشخص شود:
چه داده‌ای → مالک آن کدام واحد است → چه کسی اجازه تغییر دارد → تغییر چگونه ثبت می‌شود؟
این موضوع ارتباط مستقیمی با حاکمیت داده دارد.
حاکمیت داده؛ بخش فراموش‌شده یکپارچه‌سازی
فناوری به تنهایی نمی‌تواند جریان اطلاعات را درست کند. شهرداری باید درباره داده‌های خود قواعد مشخصی داشته باشد. برای مثال:
- مالک هر داده چه واحدی است؟
- تعریف رسمی هر داده چیست؟
- چه کسی مسئول صحت آن است؟
- چه کسی اجازه تغییر دارد؟
- اطلاعات چه زمانی باید به‌روزرسانی شود؟
- چه مدت نگهداری شود؟
- چه کسانی به آن دسترسی داشته باشند؟
این مجموعه قواعد، بخشی از Data Governance یا حاکمیت داده است.
یکپارچه‌سازی موفق از کجا شروع می‌شود؟
برای ایجاد جریان اطلاعات میان واحدهای شهرداری، بهتر است ابتدا یک فرآیند مشخص انتخاب شود.
برای مثال:
پرونده ملک
سپس مسیر واقعی آن بررسی شود: شهروند → شهرسازی → درآمد → نوسازی → کمیسیون → نتیجه
در هر مرحله مشخص شود:
- چه اطلاعاتی تولید می‌شود؟
- چه اطلاعاتی دریافت می‌شود؟
- منبع اصلی هر داده کجاست؟
- چه اطلاعاتی باید منتقل شود؟
- چه کسی مسئول آن است؟
- چه کسی اجازه تغییر دارد؟
- چه API یا سرویس ارتباطی لازم است؟
این کار به جای شروع از نرم‌افزار، از فرآیند واقعی سازمان شروع می‌کند.
نقشه جریان اطلاعات شهرداری
برای طراحی یکپارچه‌سازی می‌توان برای هر فرآیند یک نقشه جریان اطلاعات تهیه کرد. مثلاً:
ملک ↓
شهرسازی ↓
محاسبه عوارض ↓
درآمد ↓
پرداخت ↓
به‌روزرسانی وضعیت پرونده ↓
خدمات شهروندی ↓
داشبورد مدیریتی
در کنار این جریان، GIS نیز می‌تواند اطلاعات مکانی پرونده را در اختیار سامانه‌های مرتبط قرار دهد. این نقشه کمک می‌کند نقاط قطع ارتباط، ورود مجدد اطلاعات و دوباره‌کاری شناسایی شوند.
چگونه بفهمیم شهرداری به جریان اطلاعات یکپارچه نیاز دارد؟
وجود این نشانه‌ها می‌تواند بیانگر نیاز به بازنگری در معماری اطلاعات باشد:
نشانه اول
کارشناسان مرتباً اطلاعات را از یکدیگر درخواست می‌کنند.
نشانه دوم
یک اطلاعات در چند سامانه مقدار متفاوت دارد.
نشانه سوم
کارشناسان مجبورند اطلاعات را از Excel به سامانه منتقل کنند.
نشانه چهارم
مدیران برای تهیه یک گزارش باید از چند واحد اطلاعات جمع‌آوری کنند.
نشانه پنجم
وضعیت یک پرونده در سامانه‌های مختلف یکسان نیست.
نشانه ششم
شهروند مجبور است اطلاعاتی را چندین بار ارائه کند.
نشانه هفتم
با تغییر یک اطلاعات، مشخص نیست کدام سامانه‌ها باید به‌روزرسانی شوند.
از سامانه‌های جزیره‌ای به اکوسیستم شهری
یکپارچه‌سازی به این معنا نیست که همه سامانه‌ها یک شکل یا حتی الزاماً متعلق به یک محصول باشند. آنچه اهمیت دارد این است که سامانه‌ها بتوانند در یک معماری مشخص با یکدیگر ارتباط داشته باشند.
در چنین معماری: سامانه‌ها تخصصی باقی می‌مانند، اما اطلاعات جزیره‌ای نمی‌ماند. این تفاوت یکی از مهم‌ترین مفاهیم در تحول دیجیتال شهرداری است.
نقش راهکارهای یکپارچه شهری
راهکارهای یکپارچه شهری می‌توانند به جای تمرکز صرف بر یک واحد، ارتباط میان فرآیندهای مختلف شهرداری را در نظر بگیرند. برای مثال در اکوسیستم راهکارهای شهری بهساز، حوزه‌هایی مانند:
- شهرسازی
- درآمد
- نوسازی
- املاک
- کمیسیون‌ها
- خدمات شهروندی
- GIS
- داشبورد مدیریتی
می‌توانند در یک چارچوب منسجم‌تر قرار بگیرند. هدف چنین رویکردی این نیست که تمام واحدها یک کار را انجام دهند؛ بلکه این است که هر واحد کار تخصصی خود را انجام دهد و اطلاعات مورد نیازش را از مسیر درست دریافت کند.
به این ترتیب: یک پرونده → چند واحد → یک جریان اطلاعاتی منسجم
می‌تواند جایگزین: یک پرونده → چند سامانه → چند نسخه اطلاعات
شود.
آینده مدیریت پرونده‌های شهری
در آینده، پرونده شهری صرفاً یک مجموعه اسناد نخواهد بود.
می‌تواند به یک موجودیت دیجیتال تبدیل شود که:
- اطلاعات ساختاریافته دارد.
- موقعیت مکانی دارد.
- تاریخچه اقدامات دارد.
- اسناد مرتبط دارد.
- فرآیند مشخص دارد.
- با سایر سامانه‌ها ارتباط دارد.
- وضعیت آن در لحظه قابل مشاهده است.
- قابلیت تحلیل دارد.
در چنین شرایطی، شهرداری می‌تواند از مدیریت «اسناد و پرونده‌ها» به سمت مدیریت اطلاعات و فرآیندهای شهری حرکت کند.
هوش مصنوعی و جریان اطلاعات پرونده‌ها
پس از ایجاد جریان منسجم اطلاعات، فناوری‌های هوش مصنوعی نیز می‌توانند کاربردهای بیشتری پیدا کنند. برای مثال:
استخراج اطلاعات از اسناد
هوش مصنوعی می‌تواند اطلاعات مهم را از اسناد و فرم‌ها استخراج کند.
طبقه‌بندی پرونده‌ها
پرونده‌ها می‌توانند بر اساس نوع، موضوع یا وضعیت دسته‌بندی شوند.
جست‌وجوی هوشمند
کاربر می‌تواند به جای جست‌وجوی صرفاً کلمه‌ای، مفهوم مورد نظر خود را پیدا کند.
شناسایی مغایرت
سیستم می‌تواند برخی اختلافات میان اطلاعات را شناسایی و برای بررسی انسانی علامت‌گذاری کند.
پیش‌بینی گلوگاه‌های فرآیند
با تحلیل سوابق می‌توان نقاطی را که معمولاً باعث تأخیر پرونده می‌شوند شناسایی کرد.
اما همان‌طور که در معماری داده مطرح شد، هوش مصنوعی نیز به داده معتبر، ساختاریافته و قابل اعتماد نیاز دارد.
شاخص‌های پیشنهادی برای سنجش جریان اطلاعات
برای اینکه یکپارچه‌سازی فقط یک پروژه فناوری نباشد، باید نتایج آن اندازه‌گیری شود. برخی شاخص‌های قابل بررسی عبارت‌اند از:
- درصد کاهش ورود مجدد اطلاعات
- تعداد مغایرت‌های اطلاعاتی
- متوسط زمان گردش پرونده
- زمان توقف پرونده در هر واحد
- تعداد تبادلات موفق میان سامانه‌ها
- درصد پرونده‌های قابل رهگیری
- تعداد فرآیندهای یکپارچه
- درصد داده‌های دارای مرجع مشخص
- میزان استفاده از خدمات الکترونیکی
- تعداد مراجعات غیرضروری شهروندان
این شاخص‌ها می‌توانند نشان دهند یکپارچه‌سازی واقعاً چه تغییری در عملکرد سازمان ایجاد کرده است.
جمع‌بندی؛ یک پرونده، چند واحد، یک جریان اطلاعات
در شهرداری، یک پرونده می‌تواند هم‌زمان به چندین واحد و سامانه مرتبط باشد. مشکل زمانی ایجاد می‌شود که هر واحد بخواهد نسخه مستقلی از اطلاعات پرونده را نگهداری کند. نتیجه چنین رویکردی می‌تواند:
- دوباره‌کاری
- مغایرت اطلاعات
- خطای انسانی
- تأخیر
- گزارش‌های متناقض
- کاهش شفافیت
باشد. راهکار، الزاماً حذف سامانه‌های موجود نیست. راهکار می‌تواند ایجاد یک معماری یکپارچه اطلاعات باشد که در آن:
داده در محل مناسب ثبت می‌شود → مرجع آن مشخص است → از طریق API و سرویس‌های مناسب در اختیار واحدهای مجاز قرار می‌گیرد → تغییرات ثبت می‌شوند → فرآیند قابل رهگیری است → اطلاعات برای تحلیل و تصمیم‌گیری استفاده می‌شود.
در چنین مدلی، شهرداری از مجموعه‌ای از سامانه‌های جزیره‌ای به سمت یک اکوسیستم اطلاعاتی شهری حرکت می‌کند. و در نهایت، هدف اصلی یکپارچه‌سازی نه «ارتباط دادن نرم‌افزارها» بلکه جریان پیدا کردن درست اطلاعات در سازمان است.
سوالات متداول
آیا اطلاعات یک پرونده باید در تمام سامانه‌های شهرداری ذخیره شود؟
خیر. بهتر است اطلاعات مرجع در محل مناسب نگهداری شود و سایر سامانه‌ها اطلاعات مورد نیاز خود را از طریق سازوکارهای کنترل‌شده دریافت کنند.
چگونه می‌توان از ثبت چندباره اطلاعات جلوگیری کرد؟
با مشخص کردن مرجع داده، ایجاد شناسه‌های مشترک، استفاده از API و اتصال فرآیندهای مرتبط می‌توان نیاز به ورود مجدد بسیاری از اطلاعات را کاهش داد.
آیا یکپارچه‌سازی یعنی همه سامانه‌های شهرداری باید تعویض شوند؟
خیر. بسته به معماری موجود، می‌توان بسیاری از سامانه‌های فعلی را از طریق API، سرویس‌های تبادل اطلاعات و لایه‌های یکپارچه‌سازی به یکدیگر متصل کرد.
نقش GIS در پرونده‌های شهری چیست؟
GIS می‌تواند اطلاعات مکانی پرونده‌ها را مدیریت کند و ارتباط میان موقعیت مکانی، ملک، پرونده و سایر اطلاعات شهری را فراهم کند.
آیا همه واحدها باید به تمام اطلاعات پرونده دسترسی داشته باشند؟
خیر. دسترسی باید بر اساس نقش، وظیفه و سطح مجاز تعریف شود.
جریان اطلاعات چه ارتباطی با مدیریت داده‌محور دارد؟
وقتی اطلاعات به شکل منسجم و قابل اعتماد میان فرآیندها جریان داشته باشد، امکان تولید شاخص، داشبورد، تحلیل و تصمیم‌گیری داده‌محور افزایش پیدا می‌کند.
آیا هوش مصنوعی بدون یکپارچه‌سازی اطلاعات قابل استفاده نیست؟
هوش مصنوعی می‌تواند در یک سامانه مستقل نیز استفاده شود، اما برای تحلیل‌های سازمانی و بین‌واحدی، کیفیت، دسترسی و انسجام داده‌ها اهمیت بسیار زیادی دارد.