سامانه بود، داده نبود! دربارهٔ مسئلهٔ کیفیت داده‌ها

اگرچه امروزه سامانه‌های پیشرفته با قابلیت ثبت انواع مختلف داده‌ها در سازمان‌ها توسعه داده می‌شود، اما این به معنای فراگیرشدن استفاده از این سامانه‌ها در سازمان و تولید داده‌های باکیفیت (صحیح، کامل، ارائه‌شده در زمان و فرمت مناسب، مرتبط) نیست.

در طراحی سیستم‌های اطلاعاتی باید تمهیدات لازم برای اطمینان از کیفیت داده‌ها لحاظ شود.

از عوامل مؤثر بر ارتقای کیفیت داده‌ها آن است که دادهْ کاربرد داشته باشد و محل رجوع باشد؛ داده، بدون ضرورت عملی و به‌صورت خودبه‌خود، باکیفیت نمی‌شود.

---

پروژۀ شفافیت را می‌توان پروژۀ طراحی یک سیستم اطلاعاتی دانست که قصد دارد با استفاده از فناوری اطلاعات و ارتباطات، جریان اطلاعات را، هم در درون مجموعۀ مدیریت شهری و هم بین مجموعۀ مدیریت شهری با بیرون از آن، به‌گونه‌ای تغییر دهد که امکان نظارت عموم شهروندان بر عملکرد مجموعه، و مشارکت ایشان در حل مسائل شهر، فراهم شود.

در هر سیستم اطلاعاتی، کیفیت داده و اطلاعات عاملی تعیین‌کننده در کارآمدی عملکرد آن سیستم متناسب با هدف (یا اهداف) سیستم است. منظور از دادۀ باکیفیت داده‌ای است که کامل و صحیح باشد، در زمان و فرمت مناسب در اختیار کاربر آن قرار گیرد، و محتوای آن متناسب با هدف و کاربرد داده باشد. متن حاضر، روایتی است از نمودِ مسئلۀ کیفیت داده در پروژۀ شفافیت و اقداماتی که به‌منظور ارتقای کیفیت داده‌ها صورت گرفت.

*

کمیتۀ شفافیت به دنبال آن بود که اطلاعات مربوط به عملکرد شورای شهر و شهرداری تهران را، به‌صورت الکترونیکی، و در بستر وب، در دسترس عموم قرار دهد. در این راستا، کمیتۀ شفافیت هنگام ورود به هر حوزه برای تحقق شفافیت با دو سؤال عمده مواجه بود: اول اینکه آیا سامانه‌ای برای ثبت داده و اطلاعات وجود دارد یا خیر؟ و دوم اینکه آیا داده‌های موجود در آن سامانه کیفیت مناسبی دارد یا خیر؟

خوشبختانه در اکثر حوزه‌هایی که کمیتۀ شفافیت به آن ورود کرد، از قبل، سامانه‌ای در شهرداری تهران وجود داشت و این امیدواری وجود داشت که با دستورِ واحدِ متولی داده‌ها به انتشار داده‌ها روی سایت شفاف، با انجام مختصر کار فنی برای فراخوانی داده‌ها از سامانه روی سایت شفاف، شفافیت در آن حوزه محقق شود.

اما آنچه کمیتۀ شفافیت درعمل با آن روبه‌رو شد این بود که داده‌های ثبت‌شده در پایگاه‌های داده‌ای سامانه‌ها لزوماً کیفیت مناسبی ندارند. درواقع، به‌رغم تعداد بالای سامانه‌ها در شهرداری (حدود ۱۷۰ سامانه به گفتۀ کارشناس کمیتۀ شفافیت، و حدود ۲۰۰ سامانه به گفتۀ مدیرعامل سازمان فاوا در دورۀ شورای پنجم)، وجود این سامانه‌ها به معنای آن نبود که سامانه‌ها به‌طور کامل مورد استفاده قرار می‌گیرند و اطلاعات ثبت‌شده در آن کیفیت قابل قبولی دارد.

سمیه فروغی[۱]: ما در شهرداری حدود ۱۷۰ سامانه داریم ولی واقعاً به این اندازه اشراف اطلاعاتی نداریم.

میثم درویشی[۲]: به‌طور کلی مشکل خیلی از سامانه‌های شهرداری این است که به‌خوبی مورد بهره‌برداری قرار نمی‌گیرند و دیتاها به‌درستی در آن‌ها وارد نمی‌شود. به همین دلیل گزارش‌هایی که از این سامانه‌ها گرفته می‌شود قابل استناد نیستند. برخوردهای سلیقه‌ای و نداشتن رویۀ مشخص در ورود اطلاعات نیز آسیب دیگری است که درخصوص شیوه تولید دیتاهای شهرداری وجود دارد که باید رابطه با آن تصمیم‌گیری شود.

علیرضا جالینوس[۳]: در هر حوزه‌ای که وارد شدیم که برای [سامانه] اشراف دیتا بگیریم، بعد از پروسۀ data cleansing (پاک‌سازی داده)، دیتا را در اختیار واحدی که صاحب داده بود هم قرار می‌دادیم و از او می‌خواستیم که این داده‌ها را جایگزین داده‌های خودش کند. یعنی اصلاً خودشان این را از ما درخواست می‌کردند که دیتایمان را به آن‌ها نیز بدهیم. چرا؟ چون هیچ‌وقت کار data cleansing به‌درستی در واحدهای مختلف انجام نمی‌شد.

محمد فرجود[۴]: در بسیاری از موارد، داده‌ای که درنهایت برای انتشار در اختیار ما قرار می‌گرفت دستی تهیه شده بود چون خیلی از سامانه‌ها هنوز integrate (یکپارچه) نبودند و داده‌های موردنیاز باید از منابع مختلف جمع‌آوری می‌شد و به‌صورت دستی در لیست‌ها قرار می‌گرفت. ما به‌تدریج سعی کردیم سامانه‌های اصلی را یکپارچه کنیم. برای مثال حوزۀ قراردادها حوزه‌ای بود که این کار تا حد خوبی در آن پیش رفت. در بیشتر مواقع content (محتوا) موردنیاز در سامانۀ ما به‌صورت تجمیع‌شده موجود بود، اما ممکن بود خطا و اشتباه داشته باشد‌ که دلیل آن هم عدم وجود فرایندی برای صحت‌سنجی و تأیید داده‌ها پیش از ثبت در سامانه بود و این موضوع احتمال اینکه در جمع‌آوری و ثبت داده اشتباه شود را خیلی بالا می‌برد.

اکبری[۵]: چند سال بود که شهرداری انرژی نیروی انسانی و هزینۀ مالی زیادی صرف می‌کرد، اما باز هم به نتیجه‌ای که باید نمی‌رسید، یعنی اطلاعات سامانۀ قراردادها با سامانۀ مالی سینک نبود. سینک‌کردن اطلاعات هم کار دقیقی بود چون همان اطلاعاتی که در سامانۀ قراردادها ثبت شده بود باید در سامانۀ مالی می‌آمد و نباید یک ریال هم بالا یا پایین می‌شد یا مشخصات اصلی و شناسنامه قرارداد مغایرتی می‌داشت.

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

اسحاق بهادری[۶]: از قدیم در شهرداری تهران، بر اساس نیاز روز و تعداد نیروی انسانی شهرداری، سامانه‌های مختلفی مورد استفاده قرار گرفته‌اند که به‌مرور تغییر پیدا کرده‌اند و جدیدتر و به‌روزتر شده‌اند. آخرین سامانه‌ای که ما با آن کار می‌کردیم، سامانۀ مدیریت جامع منابع انسانی شهرداری تهران بود. دی‌ماه ۱۳۹۸ که من اداره‌کل سرمایۀ انسانی را تحویل گرفتم، اطلاعات پرسنلی موجود در سامانۀ جامع حدود بیست و نه هزارتا بود؛ این در حالی بود که ما آن موقع در شهرداری تهران عملاً نزدیک به پنجاه و هشت هزار نفر پرسنل داشتیم.

بهاره آروین: [انتشار اطلاعات ایمنی ساختمان‌ها] مستلزم این بود که این اطلاعات درمورد تمام ساختمان‌ها جمع‌آوری و در سامانه‌ای وارد شود که بعد بتوان آن را فراخوانی کرد. سامانه ایجاد شد و آقای داوری از سازمان آتش‌نشانی هرازچندی می‌آمد و گزارش می‌داد که تاکنون اطلاعات چند ساختمان وارد سامانه شده است […] به انتشار که اصلاً نرسید چون خودِ تکمیل‌ این اطلاعات فازهای مختلفی داشت و خیلی طول کشید. هربار آتش‌نشانی‌ها می‌گفتند ما این‌قدرش را تکمیل کرده‌ایم و این‌قدر دیگرش مانده و ازاین‌جور حرف‌ها.

مسئلۀ کیفیت داده‌ها برای کمیتۀ شفافیت مسئله‌ای حیاتی بود چراکه اگر نمی‌شد از جامعیت، صحت و ثبت به‌موقع اطلاعات منتشرشده در حوزه‌های مختلف اطمینان حاصل کرد، بنای شفافیت سست و متزلزل می‌شد. در گام بعدی، فرمت ارائۀ اطلاعات، و اینکه اقلام اطلاعاتی منتشرشده گلوگاه‌های تخلف، فساد و اعتمادزدایی را هدف گرفته باشد، عامل مهمی در به‌ثمررسیدن پروژۀ شفافیت بود. به همین دلیل، بخش قابل‌ملاحظه‌ای از توان و زمان کمیتۀ شفافیت طی دورۀ چهارسالۀ شورای پنجم، صرف پیگیری ارتقای کیفیت داده‌های منتشرشده در حوزه‌های مختلف شد:

محمدحسین صدوقی[۷]: در بحث انتشار عمومی اطلاعات ما با دو دسته اطلاعات مواجهیم؛ یا اطلاعات از یک پروسۀ شفاف آمده است و مسیر انتشار عمومی آن راحت و سرراست طی می‌شود، و یا با مجموعه‌ای از اطلاعات نامفهوم و پراکنده مواجهیم که نیازمند تدقیق، صحت‌سنجی و یکپارچه‌سازی است. خیلی از اوقات، نقایص و عدم یکپارچگی اطلاعات بعد از انتشار نسخة اولیه خودش را نشان می‌داد و زمینه‌ای فراهم می‌کرد تا کمیتة شفافیت برای اصلاح و بهبود کیفیت اطلاعات مطالبه‌گری کند.

بعضاً، انتشار اطلاعات پیش از تضمین کیفیت آن چالش‌هایی را به وجود آورد:

محمد فرجود: درخصوص سفرهای خارجی […] بعداً برخی معترض شدند. مثلاً یکی از مدیران قبلی شهرداری به من زنگ زد که این داده‌ها اشتباه است؛ من این تعداد سفر نرفته‌ام‌. گفتم انتشار این اطلاعات مصوبه[۸] دارد و ما در سازمان فاوا فقط اطلاعاتی که به دستمان رسیده است را روی سایت منتشر کرده‌ایم. […] البته هرچه جلوتر می‌رفتیم، بارگذاری بخش بزرگ‌تری از اطلاعات سیستمی می‌شد و با فراخوانی داده از سامانه‌ها انجام می‌گرفت و خطاها و اشتباهاتی که در بارگذاری دستی پیش می‌آمد کمتر می‌شد.

بهاره آروین: قبل از اینکه به برنامه بروم داده‌ها [ی صورت‌های مالی سازمان‌ها و شرکت‌ها] را بررسی کردم و دیدم اعداد با منطق نمی‌خواند و متوجه شدیم که اشتباهی رخ داده. حالا تا آن اشتباه را بتوانیم تصحیح کنیم کلی بساط داشتیم چون به این سادگی و راحتی نیست که بگوییم فلان جای اکسل ایراد دارد و فوری درست شود. تصحیح داده‌ها برای خودش پروسه‌ای دارد. یادم می‌آید آن موقع با خودم گفتم چقدر خوب است که ما خودمان متوجه این اشتباه شدیم.

بهاره آروین: سر انتشار اطلاعات قراردادها، برای یکی از قراردادهای منطقۀ سه جنجالی به ‌‌‌پا شد. ماجرا این بود که شیوۀ انجام این معامله ترک تشریفات^[۹] خورده بود، ولی موضوعش طوری بود که ترک تشریفات کردنش بی‌معنی بود و به نظر می‌رسید تخلفی روی داده است. اما بعد مشخص شد که منطقۀ سه با یکی از زیرمجموعه‌‌های خود شهرداری «بدون تشریفات»^[۱۰] قرارداد بسته و اپراتور به‌اشتباه شیوۀ عقد قرارداد را ترک تشریفات ثبت کرده. درواقع، ماجرا خطایی بود که اپراتور واردکنندۀ اطلاعات در سیستم مرتکب شده بود. کار داشت تا تغییر شهردار منطقۀ سه پیش می‌رفت، چون ما مسئول صحت اطلاعات منتشرشده را بالاترین مقام هر واحد اجرایی اعلام کرده بودیم.

پروشات مهرورزی[۱۱]: انتشار تاریخ استخدام، به دلیل سنتی و دستی‌بودن ثبت اطلاعات، کار پیچیده‌ای بود. فکر می‌کنم چند گزارش هم در فارس و غیره و ذلک رفتند که سامانۀ شفافیتی که این‌همه پزش را می‌دهید همه‌اش دروغ است. فلانی مثلاً فلان سال اینجا استخدام شده، ولی تاریخ استخدامش در سایت یک موقع دیگری است. دلیل این ناهمخوانی این بود که احکام متغیر بود و دیتای آن درست نبود که شکر خدا، بعد از یکی-دو ماه، این بخش را از روی سایت برداشتند، ولی خب ضربه‌ای که به اعتماد به سامانۀ شفافیت خورده بود سخت جبران می‌شد.

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

بنابر گفته‌های مصاحبه‌شوندگان، کیفیت داده‌ها در حوزه‌های مختلف یکسان نبود.

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

در حوزه‌هایی که کیفیت داده‌ها قابل‌قبول بود، یعنی دست‌کم می‌شد از صحت و جامعیت اطلاعات مطمئن بود و از این نظر مانعی برای انتشار وجود نداشت، شفافیت بیش از هر چیز وابسته به اراده و دستور مدیریتی به انتشار اطلاعات بود. اطلاعات حوزۀ شهرسازی در این دسته قرار می‌گیرد. درمورد شفافیت پرونده‌های صدور پروانه‌های تخریب و نوسازی، کمیتۀ شفافیت دغدغۀ چندانی در رابطه با جامعیت و صحت اطلاعات ثبت‌شده در سامانۀ شهرسازی نداشت و تلاش‌های کمیته بیشتر صرف همراه‌کردن و جلب موافقت مدیران حوزۀ شهرسازی برای انتشار اطلاعات موجود در سامانه و سروکله‌زدن دربارۀ شکل انتشار داده‌ها می‌شد.

محمدمهدی ریوندی[۱۲]: حرف ایشان [معاون شهرسازی و معماری وقت] این بود که فارغ از بحثِ امکان، انتشار این اطلاعات مطلوب نیست. نه‌تنها مطلوب نیست که نامطلوب است؛ ایجاد مشکل می‌کند، دردسر و چالش‌های جدیدی برای شهرداری ایجاد می‌کند که برای مدیریت آن انرژی و بودجۀ کافی وجود ندارد و اصلاً چرا سری که درد نمی‌کند را دستمال ببندیم. [… خلاصه] قبل از تصویب طرح [الزام شهرداری تهران به انتشار عمومی اطلاعات شهرسازی] جلساتی با شهرداری برگزار کردیم و در آن خودمان از شهرداری خواستیم بحث شفافیت اطلاعات شهرسازی را پیش ببرد. فکر می‌کردیم این راه جواب می‌دهد. وقتی دیدیم که گوشی بدهکار نیست و همدلی اتفاق نیفتاده، فکر کردیم بهتر است با تهیۀ مصوبه آن‌ها را از طریق قانون ملزم به انجام کار کنیم. […] درنهایت طرح را بنا بر نتیجۀ بررسی‌ها تدوین کردیم و به شورا پیشنهاد دادیم. طرح به کمیسیون مشترک «شهرسازی و معماری»، «برنامه و بودجه» و «نظارت و حقوقی» ارجاع گردید. بعد از آن هم که دیگر دعواها و بحث‌ها شروع شد، اما درنهایت طرح به تصویب رسید […] یکی از چالش‌هایمان سر موارد مالی بود. ما در مصوبه گفته بودیم که برای هر پرونده، عوارض صدور پروانه باید منتشر شود. می‌گفتند نمی‌شود و معاونت مالی و اداره‌کل درآمد باید به ما اطلاعات بدهد. […] تصویب طرح درکل آسان انجام شد. در اجرای مصوبه هم با چالش زیادی مواجه نشدیم و درنهایت هم که اطلاعات منتشر شد. الان که نگاه می‌کنم کار سختی نبود. چالش اصلی شاید انتشار آرای شورای معماری یا کمیسیون ماده ۷^[۱۳] بود که آن را هم قبول کردند و منتشر کردند.

مصاحبه‌کننده: اگر یادتان باشد ما در بحث انتشار اطلاعات معاملات چالش زیادی بر سر کامل، دقیق و صحیح بودن اطلاعات داشتیم ولی برای شهرسازی چنین درگیری‌هایی وجود نداشت. تفاوت در چه بود؟

محمدمهدی ریوندی: ببینید اولاً پرونده‌های شهرسازی به نسبت پرونده‌های معاملات خیلی شسته‌رفته‌تر است. مثلاً برای گرفتن پروانه، اطلاعات زیادی باید به جاهای مختلف ارائه و در سامانه‌ها وارد شده باشد تا درنهایت منتهی به خروجی نهایی یعنی صدور پروانه شود. این اطلاعات باید به سازمان نظام مهندسی، سازمان ثبت اسناد و املاک کشور و سازمان‌های دیگری که مستقل از شهرداری هستند و همچنین بخش‌های مختلفی در خود شهرداری مثل شهرسازی، محیط‌زیست، فضای سبز، مالی و درآمد که هرکدام یک واحد در ستاد و یک واحد در هر منطقه دارند ارائه شود. به‌این‌ترتیب، صدور پروانه در گرو تأیید تک‌تک این واحدهاست و اطلاعات این واحدهای مختلف هم تقریباً همه با یکدیگر سینک است، به این معنا که اطلاعات بخش‌های مختلف یک پروندۀ صدور پروانه هم‌زمان در سامانه‌های فضای سبز، مالی، شهرسازی، کمیسیون ماده ۱۰۰ [۱۴]و امثالهم وجود دارد. علاوه‌براین، چون جنبۀ مهندسی در فرایند صدور پروانه برجسته است، فقط با طی و قطعی شدن هر مرحله می‌توان به مرحلۀ بعد رفت. به همین دلیل شاید نشود به‌سادگی موردی را مخفی کرد. مثلاً نمی‌شود همه‌چیز دربارۀ یک ملک مشخص باشد اما مبلغی که بابت صدور پروانه پرداخت شده نامشخص باشد، مگر اینکه کل پرونده را محو کنند و بگویند پرونده‌ای با فلان شماره اصلاً نیست و کسی به آن دسترسی ندارد. به همین دلیل اطلاعات در این حوزه شسته‌رفته‌تر است.

مصاحبه‌کننده: درمورد مثال آخری که زدید، در بحث معاملات هم مبلغ قرارداد جزء آیتم‌هایی بود که در سیستم ثبت می‌شد، اما در موارد بسیاری عدد ثبت‌شده پرت‌وپلا بوده.

محمدمهدی ریوندی: درمورد معاملات سامانه قفل نیست که اگر صحت و دقت اطلاعات تأیید نشد نرود مرحلۀ بعد. اما در سامانۀ شهرسازی همه‌چیز باید با جزئیات وارد شود و بعد هم ده نفر تأیید کنند. از کارشناس گرفته تا معاون، قائم‌مقام و مسئول همه باید امضا کنند. تفاوت در این است.

یکی از مسائلی که در رابطه با شفافیت اطلاعات شهرسازی وجود داشت، محدودیت تعداد پرونده‌های شهرسازی قابل مشاهده در هر روز بود. در این زمینه، بین کمیتۀ شفافیت و شهرداری اختلاف‌نظر وجود داشت.

محمدمهدی ریوندی: سازمان فاوا چنین محدودیتی را گذاشته بود که هر کاربر روزانه حداکثر اطلاعات پروندۀ پنج ملک ثبتی را می‌توانست مشاهده کند. استدلالشان این بود که دسترسی نامحدود به سرورهای ما فشار می‌آورد، اما به نظر من این مسخره‌بازی سازمان فاوا بود. […] به نظر من ایجاد محدودیت در مشاهدۀ پرونده کار بسیار احمقانه‌ای بود. حتی اگر فردی بخواهد صبح تا شب هزار تا پرونده ببیند، شمای سازمان فاوا موظفید به او دسترسی بدهید. هر زمان که سیستمت بابت این کلیک‌ها به مشکل خورد هم باید دنبال این باشی که بودجه بگیری و درستش کنی. وظیفۀ توست که به‌صورت روان و راحت دسترسی بدهی. به‌هرحال ما کوتاه آمدیم. می‌گفتیم آن‌ها رفیق و هم‌خط (برآمده از پایگاه اصلاح‌طلبی) و هم‌فکر خود ما هستند. حالا البته رفاقت خاصی هم نداشتیم ولی خب چاره‌ای هم جز اینکه راه بیاییم نداشتیم. خلاصه که دسترسی یک مدت محدود بود اما فکر می‌کنم بعداً اصلاح شد. […] بهانۀ آن‌ها برای ایجاد محدودیت این بود که ارائۀ این میزان دسترسی به سیستم ما فشار زیادی می‌آورد. از طرف دیگر بله، حرف‌هایی درمورد فروش داده‌ها و درآمدزایی برای شهرداری هم بود، اما خب به‌ نظر من اساساً ایدۀ بی‌معنایی بود. حرف ما این بود که مالکیت این داده‌ها متعلق به شهرداری نیست که بخواهد آن‌ها را بفروشد و درآمد ایجاد کند.

محمد فرجود: در ابتدا چنین محدودیتی وجود نداشت. این‌طور که یادم است، مشکلی که پیش آمد این بود که معاملات ‌ملکی‌ها دائماً روی ملک‌ها استعلام می‌گرفتند و دیتا را fetch (فراخوانی) می‌کردند. این کار باعث کندی سامانۀ شهرسازی ما شده بود و برای ما چالش ایجاد می‌کرد‌. روی همین حساب، با معاونت شهرسازی و شورا و بقیه متولیان مشورت کردیم و گفتیم یک فرد عادی قاعدتاً نمی‌آید هر روز استعلام ده ‌تا ملک را بگیرد، بنابراین کسانی که مدام در حال استعلام‌‌گرفتن هستند استفاده‌های دیگری جز بحث شفافیت و نظارت بر تخلفات ساخت‌وساز از این داده‌ها دارند، پس ما بیاییم یا از یک تعداد بیشتر استعلام در روز را پولی کنیم و یا روی تعداد استعلام روزانه لیمیتیشن بگذاریم. گفتند پولی نکنیم، و به این ترتیب قرار شد روی تعداد استعلام در روز لیمیتیشن بگذاریم. این تصمیم هم یک تصمیم جمعی بود و تصمیم انفرادی سازمان فاوا‌ نبود. بنابراین محدودیتی که ما اعمال کردیم مربوط به اصل دسترسی به اطلاعات نبود؛ همه می‌توانستند به دیتای منتشرشده دسترسی داشته باشند. اما ما به‌لحاظ فنی در ایجاد دسترسی به تعداد بالای استعلامات مشکل داشتیم، چون سامانۀ شهرسازی سامانۀ سنگینی بود و تعداد زیاد استعلامات هم لود زیادی روی سامانۀ ما ایجاد می‌کرد. اگر وضع به همان منوال پیش می‌رفت، دیگر هیچ‌کس نمی‌توانست از سامانه استفاده کند‌ و عملاً نقض غرض می‌شد.

محمد فرجود: سامانۀ شهرسازی سامانۀ خیلی سنگین و پیچیده‌ای بود. بیست‌و‌خرده‌ای زیرسامانه داشت‌. به این راحتی‌ها نبود که بگوییم برویم سیستم را ارتقا دهیم‌. اگر می‌شد این کار را انجام داد، می‌کردیم‌، که البته خیلی جاها هم این کار را کردیم‌. ضمن آنکه لیمیت‌گذاشتن روی سرویس آزاد و رایگان هم کار عجیبی نیست و متداول است‌. عمدۀ کاربران این‌ سرویس هم مردم نبودند‌. یعنی من هیچ‌وقت کسی از مردم را ندیدم که شکایت کند، بگوید من امروز می‌خواستم پنجاه‌ تا استعلام بگیرم و نتوانستم‌، چون نیاز مردم عادی در این حد نیست. مثلاً می‌خواهند یک خانه بخرند‌. حالا اگر در روز بنگاهی پنج‌ تا خانه هم به آن‌ها نشان بدهد و آن‌ها بخواهند اطلاعات این پنج خانه را ببینند، همان پنج استعلام کافی است. مشخص بود که تعداد زیاد استعلامات از یک آدرس مشخص (آی‌پی^[۱۵])، بنگاهی‌ها هستند و نه شهروند معمولی. پیشنهاد ما این بود که اگر بنگاهی‌ها سرویس می‌خواهند، ما یک سرویس برایشان درست کنیم و داده را به آن‌ها بفروشیم که در این حالت چون برای دریافت اطلاعات هزینۀ مالی می‌کردند، در استفاده از آن دقت می‌کردند و فشاری به سیستم وارد نمی‌آمد. اما آن‌ موقع تصمیم معاونت شهرسازی بر چنین رویه‌ای نبود و گفتند فعلاً موقعیت را با همین لیمیتیشن‌گذاشتن مدیریت کنید.

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

به‌عنوان نمونه می‌توان به شفافیت معاملات شهرداری تهران اشاره کرد. یکی از وعده‌های انتخاباتی بهاره آروین پیگیری شفافیت قراردادهای بالای یک‌میلیارد تومان شهرداری تهران بود. پس از آغاز به کار دورۀ پنجم شوراها نیز، شورای شهر تهران مصوبۀ «الزام شهرداری به انجام الکترونیکی و اعلان عمومی اطلاعات معاملات شهرداری تهران» را به تصویب رساند که طبق آن، شهرداری تهران موظف بود اطلاعات کلیۀ انواع معاملات متوسط به بالای شهرداری را به‌صورت عمومی منتشر نماید.

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

اول، لازم بود تا امکان ثبت اطلاعات تمامی انواع معامله در سامانه فراهم شود. سامانۀ ازپیش‌موجود شهرداری تنها برای ثبت مناقصات کاربرد داشت و برای تحقق کامل شفافیت معاملات متوسط‌به‌بالا لازم بود تا این سامانه برای پشتیبانی از ثبت اطلاعات انواع دیگرِ معامله (مزایده، سرمایه‌گذاری و مشارکتی، فاکتوری، …)، متناسب با فرایندهای معاملاتی کلیه واحدهای زیرمجموعۀ شهرداری اعم از شهرداری‌های مناطق، سازمان‌ها و شرکت‌های تابعه، ارتقا پیدا کند.

دوم، لازم بود تا تمهیداتی برای اطمینان از ورود صحیح اطلاعات در سامانه اندیشیده شود. بررسی اطلاعات ثبت‌شده از مناقصات در سامانه شهرداری نشانگر خطاهای بسیار در ورود اطلاعات بود که اغلب از سهل‌انگاری کاربر سامانه و نبود کنترل‌های سامانه‌ای برای جلوگیری از برخی خطاها در ورود اطلاعات نشأت می‌گرفت. با مطرح شدن بحث انتشار عمومی این اطلاعات، رفع خطاهای اطلاعاتی اهمیت پیدا کرد.

سمیه فروغی: شرح‌خدمات از آن اطلاعاتی بود که، تا قبل از آن، پرکردن فیلدش در سامانه قراردادها اختیاری بود، یعنی ممکن بود هنگام ثبت یک قرارداد در سامانه، این فیلد اصلاً پر نشود. برای حل این مشکل اول آمدند یک باکس گذاشتند که پرکردن آن اجباری بود و کاربر سامانه موقع ثبت اطلاعات قرارداد باید بخش‌های مهم شرح‌خدمات را در آن باکس می‌نوشت. خیلی ایدۀ مزخرفی بود. [… بعد از آن،] ثبت فایل شرح‌خدمات در سامانه هم اجباری شد که حتماً برای همۀ قراردادهایی که در سامانه ثبت می‌شد، فایل شرح‌خدمات هم قرار داده شود […] من خودم چند مورد را پیدا کردم که فایل عکس پنگوئن به‌جای شرح‌خدمات ثبت شده بود. مسئول قراردادهای یکی از مناطق این پنگوئن را همه‌جا آپلود کرده بود.

سمیه فروغی: آن اوایل اطلاعات خیلی مشکل داشت چون کنترلی روی ورودی وجود نداشت و ورود اطلاعات هوشمند نبود. مثلاً سال تولد ۱۵۰۰وخرده بود یا به‌جای کد ملی عددی وارد شده بود که معلوم بود کد ملی نیست یا کد اقتصادی که باید یونیک باشد این‌طور نبود. مثال ثبت عکس پنگوئن به‌جای شرح‌خدمات هم یکی از آن موارد بود. همان سال ۹۸، کارگروه nتا جلسه با معاونان مالی مناطق ۲۲گانه، ذی‌حسابانشان و رؤسا و کارشناسان امور قراردادهایشان گذاشت تا شیوه و ملاحظات ثبت اطلاعات به مناطق آموزش داده شود و سایت شفاف را برایشان مهم کند. اما حقیقتش این است که، روی ثبت شرح‌خدمات، نظارت سیستمی وجود نداشت. فقط این را به‌صورت سیستمی کنترل کردیم که ثبت فایل شرح‌خدمات، که قبلاً اختیاری بود، اجباری شود. بعضی‌ها از سر تنبلی و اینکه حال نداشتند بخش شرح‌خدمات را جدا کنند، کل قرارداد را آپلود می‌کردند. بعضی‌ها هم چرت‌وپرت می‌گذاشتند. به‌شان گفته شد که این کار پوینت منفی برایشان دارد و من که به‌صورت رندوم اطلاعات منتشرشده را چک می‌کردم، به نظرم به‌تدریج اشکالات کمتر شد.

سمیه فروغی: هر آدم عادی‌ای هم که داده‌های قراردادها را بررسی می‌کرد به همین نتایج می‌رسید، مثلاً اینکه فلان درصد از خانه‌های ستون x خالی است یا مقدارش غلط است یا مثلاً وقتی کد اقتصادی به‌صورت هشت تا «۱» وارد شده، معلوم است که یک چیز الکی است. یادم است به مقادیر ستون «غیرنقد» خیلی اشاره می‌شد. قضیه این بود که درمورد مبلغ قرارداد باید مشخص باشد که چقدرِ آن به‌صورت نقد پرداخت می‌شود و چقدرِ آن به‌صورت غیرنقد. صدی‌نودِ خانه‌های ستون غیرنقد روی سایت شفاف صفر بود و، هم‌زمان، مبلغ واردشده برای ستون نقد هم با مبلغ کل قرارداد هم‌خوان نبود.

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

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

و سوم، لازم بود تا تمهیداتی نیز برای اطمینان از ورود اطلاعات کلیۀ معاملات در سامانه در نظر گرفته شود. در زمان انتشار اطلاعات مناقصات بالای یک‌میلیارد شهرداری، سامانۀ شهرداری تنها در شهرداری‌های مناطق و برخی سازمان‌ها و شرکت‌ها تابعه راه‌اندازی شده بود و اغلب واحدهای تابعه از این سامانه استفاده نمی‌کردند. همچنین واحدهایی که از سامانه استفاده می‌کردند نیز، اگرچه به لحاظ آیین‌نامه‌ای ملزم به ورود اطلاعات تمامی معاملات خود در سامانه بودند، در صورت عدم ورود اطلاعات یک معامله، با مشکل جدی مواجه نمی‌شدند. این بدان معنا بود که از بسیاری از معاملات اساساً ردی در سامانه معاملات موجود نبود.

سمیه فروغی: آن موقع سامانۀ قراردادها به سایت شفاف وصل شده بود و مسئلۀ محوری‌ای که وجود داشت این بود که مطمئن شویم تمام قراردادهای واجد شرایط انتشار عمومی از سامانۀ قراردادها روی سایت شفاف می‌رود. من کارم را با این سؤال محوری شروع کردم. […] اوایل هم کار فقط در سطح مناطق ۲۲گانه بود. بعدها، پیگیری ثبت و انتشار قراردادهای سازمان‌ها و شرکت‌های تابعۀ شهرداری و همچنین بررسی سامان، مالی -که سامانۀ خیلی پیچیده‌ای است- و ارتباطش با سامانه قراردادها هم به مسئولیت‌های من اضافه شد.

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

محمد فرجود: به یاد دارم که آن اوایل، از حدود چهل سازمان و شرکت زیرمجموعۀ شهرداری، فقط سازمان ما و دو-سه سازمان دیگر از این سامانه استفاده می‌کردند. […] اما به‌خاطر فشارهایی که خانم آروین آورد و جلسات متعددی که برگزار شد و اینکه بعد از مدتی امکان ثبت قرارداد در سامانه‌های دیگر هم بسته شد، بخش‌های مختلف قبول کردند که از سامانۀ قراردادها، ولو از نسخۀ چابک آن، استفاده کنند. اما تا این پروسه طی شود زمان زیادی صرف شد. این‌طور نبود که همه از همان اول همراه باشند. دو سال قبل از اینکه من به سازمان فاوا بروم، سازمان فاوا سامانۀ قراردادها را دولوپ کرده بود و تقریباً همۀ بخش‌هایش کار می‌کرد‌. اما نه در شهرداری و نه در سازمان‌ها‌ و شرکت‌ها، هیچ‌کس از آن استفاده نمی‌کرد، غیر از سازمان فاوا و دو-سه تا سازمان دیگر، که آن‌ها هم به‌طور ناقص از آن استفاده می‌کردند. ما که آمدیم، برنامه‌ریزی برای customize و دولوپ‌کردن سامانۀ مذکور را انجام دادیم، ولی همچنان کسی از آن استفاده نمی‌کرد تا زمانی که بحث سایت شفاف و شفافیت قراردادها پیش آمد و استفاده از سامانۀ قراردادها فورس شد. وقتی اطلاعات قراردادهای واحدهای مختلف روی این سامانه آمد، خود معاونت مالی تازه فهمید چه خبر است‌ و اطلاعات قراردادها در خود شهرداری هم شفاف شد‌.

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

پروشات مهرورزی: دربارۀ اطلاعات مدیران و کارکنان، مشکلی که از ب بسم‌الله وجود داشت (و البته ما بعدها این را متوجه شدیم) اشتباهات فراوان در دیتای سامانۀ منابع انسانی شهرداری بود. مثلاً یادم است به ما گفته بودند که کل شهرداری و تمام سازمان‌ها و شرکت‌های وابسته به آن ۶۱ هزار نفر پرسنل دارد، اما وقتی به سامانه‌ای مراجعه می‌کردیم که اطلاعات از آن به‌صورت برخط روی سایت شفافیت منتشر شده بود، می‌دیدیم تعداد پرسنل ۶۵ هزار نفر است. علتش این بود که بعضی دیتاها دو-سه بار وارد شده بود و شهرداری هم به این مسئله توجهی نکرده بود. مثلاً سرچ می‌کردیم و می‌دیدیم آقای x هم شهردار منطقۀ فلان است و هم معاون بهمان جا. درحالی‌که در واقعیت، یکی از این دو سِمَتِ قبلی آقای x بود و باید از سامانه حذف می‌شد. به نظرم یکی از بزرگ‌ترین مشکلات در حوزۀ شفافیت اطلاعات مدیران و کارکنان شهرداری همین بود […] اما بعضی اطلاعات اصلاً وجود نداشت، مثلاً تاریخ برخی استخدام‌ها اصلاً مشخص نبود و معلوم نبود طرف در بیست سال گذشته کجاها بوده و چه کارهایی کرده […] یکی دیگر از مشکلات ما، که البته نسبتاً حل شد، این بود که امضای حکم مدیران و ثبت آن در سامانۀ منابع انسانی و متعاقباً انتشار آن روی سامانۀ شفافیت خیلی طول می‌کشید. مثلاً ما سه ماه بود می‌دانستیم فلان معاون شهردار به جای دیگری رفته، ولی در سامانۀ منابع انسانی و سامانۀ شفافیت هنوز در پوزیشن قبلی بود. حتی یادم است بعد از چهار ماه از انتخاب آقای حناچی، هنوز نام شهردار در سامانۀ شفافیت نیامده بود و همچنان نام شهردار قبلی بود. یعنی اطلاعات نفر اول مدیریت شهر اشتباه بود و همین باعث می‌شد دیتای کل سایت زیر سؤال برود. یادم است یک روز شخصاً به دفتر یکی از مدیران منابع انسانی رفتم که امضای حکم شهردار را بگیرم تا اطلاعات شهردار در سامانۀ منابع انسانی و سایت شفافیت اصلاح شود.

محمدحسین صدوقی: یک نمونۀ دیگر، شفافیت اطلاعات کارکنان و مدیران بود. قرار بود این اطلاعات از روی سامانة جامع منابع انسانی شهرداری فراخوانی شده و روی سایت شفاف منتشر شود. شروع این کار تازه به ما نشان داد که اطلاعات ثبت‌شده در سامانة منابع انسانی چقدر ناقص است. ما تقریباً هیچ اطلاعاتی از مجامع و هیئت‌مدیره‌ها در این سامانه نداشتیم و باید این اطلاعات را از امور مجامع^[۱۶] می‌گرفتیم. حتی مؤسسات تابعه‌ای بودند که اطلاعاتشان را خود مجامع هم نداشت و نمی‌دانست آخرین تغییرات هیئت‌مدیرة آن‌ها چه بوده است.

اسحاق بهادری: آن زمان، برای آنکه گزارش کاملی از اطلاعات مدیران در اختیار شورا قرار دهیم، باید ابتدا از اطلاعات ثبت‌شده در سامانۀ جامع منابع انسانی گزارش می‌گرفتیم و بعد آن گزارش را با مستندات دیگری که داشتیم تکمیل و تدقیق می‌کردیم. علت آن بود که اگرچه کلیۀ مدیران شهرداری، از لحاظ فرایندهای مربوط به انتصابات، زیر نظر اداره‌کل کارگزینیِ مدیران بودند اما بحث حقوق و مزایای مدیران عامل سازمان‌ها و شرکت‌ها، زیر نظر اداره‌کل مجامع بود.

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

وضعیت مشابهی در مورد اطلاعات ثبت‌شده از املاک شهرداری در سامانه املاک، وضعیت پیشرفت ریالی و فیزیکی پروژه‌ها در سامانه کنترل پروژه، اطلاعات سفرهای خارجی کارکنان در سامانه سفرهای خارجی و … وجود داشت.

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

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

محمد فرجود: در حوزۀ قراردادها، سازمان فاوا توانست فرایند ثبت و انتشار اطلاعات را تا حد زیادی سامانه‌ای و اتوماتیک کند. البته رسیدن به نقطه‌ای که سامانۀ قراردادها در تک‌تک واحدهای زیرمجموعۀ شهرداری راه‌اندازی شود یک‌سال‌‌ونیم زمان برد. در طول این مدت کمیتۀ شفافیت به‌طور مرتب با واحدهای مختلف جلسه می‌گذاشت و خانم آروین و ما نظارت داشتیم تا سامانۀ قراردادها در مثلاً بیست واحد از سی واحدی که از این سامانه استفاده نمی‌کردند ایجاد و راه‌اندازی شود. درخصوص آن واحدهای باقی‌مانده هم باز خانم آروین جلسه می‌گذاشت و ما هم در جلسات شرکت می‌کردیم. کار خیلی سختی بود‌. منتها از منظر شفافیت و انتشار اطلاعات، با راه‌اندازی این سامانه، اطلاعات قراردادها پس از ثبت در سامانه به‌صورت اتوماتیک روی سایت شفاف قرار می‌گرفت. […] در سازمان فاوا، همۀ مراحل، از تصمیم کارشناس یا مدیر به عقد قرارداد و اعلام نیاز و ارائۀ آراف‌پی تا بسته ‌شدن قرارداد و همۀ مراحل پس از آن، از طریق سامانه انجام می‌شد. اما خیلی از بخش‌ها نمی‌توانستند از سیستم طراحی‌شده در سازمان فاوا استفاده کنند و اطلاعات خود را در آن وارد کنند. پیاده‌سازی نیازمندی‌های آن‌ها در سامانه هم کار پیچیده‌ای بود. به همین دلیل ما یک ورژن لایت از سامانۀ قراردادها به نام سامانۀ قراردادهای چابک تهیه کردیم که چند بخش اصلی از سامانۀ قراردادها در آن پیاده‌سازی شده بود. هدف از ایجاد نسخه سبک‌تر این بود که می‌خواستیم سامانه در آن بخش راه‌اندازی شود و به‌مرور کامل شود. با این مدل چابک توانستیم سامانۀ قراردادها را در اکثر بخش‌های شهرداری راه‌اندازی کنیم. اواخر دوره واحدهایی که کمتر تحت مدیریت شهرداری و شورا بودند، مثل سازمان فرهنگی و هنری شهرداری، باقی ماندند که سامانۀ مذکور در آن‌ها راه‌اندازی نشد.

علاوه ‌بر چالش‌های فنی، مقاومت‌هایی نیز درخصوص مشخص‌شدن بعضی از پارامترهای قراردادها مانند رقم و طرف قرارداد نیز وجود داشت. اصلاً راه‌اندازی سامانۀ قراردادها باعث شد تا شهرداری و به‌ویژه شهرداری‌های مناطق در انعقاد قراردادها دقت بیشتری داشته باشند. پیش از راه‌اندازی سامانۀ قراردادها، با توجه با اینکه اطلاعات قراردادها شفاف نبود، امکان سوءاستفاده وجود داشت ولی پس از آن جلوی خیلی از سوء استفاده‌ها گرفته شد. اما خب، طراحی و راه‌اندازی سامانۀ قراردادها در کلیۀ بخش‌های زیرمجموعه واقعاً کار خیلی سختی بود و انرژی خیلی زیادی برد.

محمد فرجود: پیاده‌سازی سامانۀ منابع انسانی پیچیده بود چون مثلاً جایی مثل سازمان پارک‌‌ها^[۱۷] با دوهزار نفر نیرو کلاً سامانۀ منابع انسانی نداشت‌ و اطلاعات نیروهایش را در فایل اکسل نگه می‌داشت‌. دیگر خود شما حساب کنید که طراحی و پیاده‌سازی فرایندها و ورود اطلاعات کارکنان در آن بخش چقدر سخت بود. کاری که ما کردیم این بود که یک تیم بیست-سی‌نفره از نیروهای مؤسسۀ رایانه شهر^[۱۸] (افرادی که در سازمان ما کار می‌کردند اما قراردادشان با شرکت رایانه شهر بود) در اختیار تیم سامانۀ منابع انسانی سازمان فاوا قرار دادیم. آن‌ها با هدایت تیم معاونت منابع انسانی شهرداری در بخش‌های مختلف شهرداری مستقر ‌می‌شدند، اطلاعات کارکنان را از سیستم قبلی -هر سیستم یا روشی که برای نگه‌داشت اطلاعات پرسنلی استفاده می‌شد- به سیستم جدید منتقل می‌کردند، خروجی‌ها را تست و آزمایش می‌کردند تا می‌رسیدند به نقطه‌ای که می‌شد گفت داده‌‌ها از سیستم قبلی به سیستم جدید convert (تبدیل و منتقل) شده است. بعد از آن، اول زیرسامانۀ حقوق و دستمزد و بعد هم زیرسامانۀ حقوق‌پردازی را در سامانۀ منابع انسانی پیاده‌سازی می‌کردند. شما حساب کنید که ما این فرایند را باید حداقل در سی سازمان طی می‌کردیم. قشنگ یادم است که پروسۀ راه‌اندازی سامانۀ منابع انسانی در واحدهای مختلف شهرداری یک‌سال‌واندی طول کشید‌. راه‌اندازی سامانه در برخی بخش‌ها مثل شرکت اتوبوسرانی^[۱۹] و سازمان پارک‌ها سخت‌تر از بقیه بود چون این‌ بخش‌ها نیروی انسانی زیادی داشتند و خیلی سخت بود که شما همۀ داده‌های مرتبط -اطلاعات شناسایی، حکم، حقوق، تردد و غیره- را در سامانۀ منابع انسانی وارد کنید.

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

اسحاق بهادری: الزام مدیریتی وجود داشت که اطلاعات همۀ مدیران در سامانه ثبت شود و پرداخت حقوق و مزایای مدیران بر مبنای اطلاعات ثبت‌شده در این سامانه (اطلاعات پرسنلی، تردد و کارکرد، سوابق کاری و …) محاسبه و به آن‌ها پرداخت شود. البته ناممکن نبود که سازمان‌ها و شرکت‌ها، بدون آنکه اطلاعات مدیرانشان در سامانه ثبت شده باشد هم، پرداختیِ آن‌ها را محاسبه و واریز کنند (مثلاً از طریق چک). این موضوع، درعمل، شیوع زیادی نداشت اما احتمالاً علت مقاومت برخی واحدهای تابعه در برابر پیوستن به سامانۀ منابع انسانی همین بوده است که اختیار پرداختی‌هایشان به مدیران دست خودشان باشد.

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

محسن شکری‌پور[۲۰]: سازمان میادین میوه و تره‌بار اطلاعات مناقصاتش را در سامانۀ قراردادها وارد می‌کرد، اما اطلاعات مزایدات را، که اطلاعات مهمی هم محسوب می‌شود، در سامانۀ قراردادها وارد نمی‌کرد. درواقع سازمان میادین از جملۀ سازمان‌هایی بود که سامانه‌ای مجزا برای خودش داشت و مزایدات خود را از طریق آن سامانه انجام می‌داد. خواستۀ ما این نبود که سازمان سامانۀ خودش را حذف کند؛ به‌هرحال آن سامانه مورد تأیید سازمان بود و کاربران از آن راضی بودند. ما از آن‌ها خواستیم که سامانه‌شان را به سایت شفاف وصل کنند تا اطلاعات مزایدات سازمان میادین هم روی سایت شفاف بیاید، اما این کار انجام نشد.

پروشات مهرورزی: طبق آخرین آماری که به یاد دارم، تا پایان دورۀ پنجم، از آن ۶۱ هزار نفر کل پرسنل، دیتای ۴۸ هزار نفر شامل اینکه کجا کار می‌کنند و دقیقاً مسئولیتشان چیست و مواردی از این دست را کاملاً تمیز کردند. آن حدود ۱۳-۱۴ هزار نفری که دیتایشان تمیز نشد اگر اشتباه نکنم ۵ سازمان و شرکت بودند که اصلاً همکاری نمی‌کردند. […] دیتای اصلی‌ای که اصلاً به ما داده نمی‌شد متعلق به شرکت همشهری و شرکت مترو بود. این دو تا اصلاً همکاری نمی‌کردند و روی بیرون‌رفتن دیتای مالی‌شان حساسیت عجیب‌وغریبی داشتند. با وجود هزاران بخشنامه‌ای که در این زمینه صادر شده بود و همه موظف بودند دیتای صحیح کارمندان خود را وارد سامانه کنند، و همچنین با وجود هشدارهایی که دربارۀ عدم همکاری داده شده بود که اگر چنین نکنند اجازۀ پرداخت حقوق و دستمزد ندارند، اما این هیچ‌وقت عملی نشد. فکر می‌کنم شهرداری و مدیرانش در آن سه سال سه بخشنامه دادند. اصلاً یک سال، با کمک خانم فروغی، بندی به مصوبۀ بودجه اضافه شد که به‌موجب آن توانستیم بعضی سازمان‌ها را قانع کنیم که از سامانۀ منابع انسانی استفاده کنند و دیتایشان را آنجا بگذارند.^[۲۱] اما شرکت مترو اصلاً همکاری نمی‌کرد و نمی‌خواست دیتای مالی‌اش بیرون بیاید و این تهدید که اگر اطلاعات کارمندانش را ثبت نکند حقوق و دستمزد کارمندانش پرداخت نخواهد شد هم کارساز نبود، چون در شرایط بحرانی کشور در سال ۹۸ چنین تهدیدی عملی نبود.

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

نجمه طاهری[۲۲]: یکی از دغدغه‌های اصلی ما این بود که مطمئن شویم اطلاعات تمام معاملات شهرداری در سامانۀ معاملات ثبت می‌شود. راهکاری که به ذهنمان رسید این بود که شهرداری سامانۀ معاملات را به سامانۀ مالی وصل کند و هر وقت هر کس خواست امور مالی مربوط به یک قرارداد را در سامانۀ مالی پیش ببرد، سامانه چک کند که آیا اطلاعات این قرارداد قبلاً در سامانۀ معاملات ثبت شده یا نه و اگر نشده، کار پیش نرود. […] حالا دو تا سامانه به هم وصل شد، فهمیدیم در سامانۀ مالی آیتمی وجود دارد به نام «عامل هزینه» که از طریق آن می‌شود برای یک قرارداد هزینه‌ای درخواست تأمین وجه داد، بدون آنکه آن قرارداد در سامانۀ معاملات ثبت شده باشد. خب افتادیم دنبال بستن عامل هزینه. این کار چندین ماه طول کشید و این‌قدر کش‌وقوس داشت که اصلاً این عبارت «بستن عامل هزینه» دیگر بینمان تبدیل به اصطلاح شده بود. بعد که سراغ قراردادهای درآمدی رفتیم، دیدیم که آن طرف هم عامل درآمد وجود دارد، باید آن را هم برای اطمینان از ثبت تمام قراردادهای درآمدی شهرداری ببندیم.

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

بهاره آروین: اولش خیلی سخت بود و کارها گره می‌خورد. مثلاً ما گفتیم شما نمی‌‌توانید در سامانۀ مالی صورت‌وضعیت ثبت کنید مگر اینکه کد قرارداد داشته باشید، یعنی قبلاً قرارداد را در سامانۀ قراردادها ثبت کرده باشید. بعد طرفْ قرارداد را در سامانه ثبت نمی‌‌کرد و به مرحلۀ ثبت صورت‌وضعیت می‌رسید و سامانه ازش قبول نمی‌‌کرد. این‌طوری صورت‌وضعیت‌های ثبت‌نشده روی هم تلنبار می‌‌شد. منتها این مقطعی بود و بعد از یک مدتی کارها روی روال افتاد و قرارداد استارت که می‌‌خورد، در سامانه ثبت می‌شد. آن اوایل صدای همه از شروطی که برای ثبت اطلاعات در سامانه‌ها گذاشته شده بود درآمده بود. آقای آل‌‌طاها هم هر از چندی برای خودش سوئیچ‌ها را باز می‌‌کرد تا کارهایی که گیر کرده بود پیش برود. خود سامانۀ قراردادها هم از ابتدا سامانۀ کاملی نبود و کم‌کم قابلیت پشتیبانی از طیف وسیع‌تری از انواع مختلف قرارداد و فرایندهای مربوط به آن را پیدا می‌کرد. خلاصه جاافتادن روال‌های جدید در حوزۀ قراردادها فرایندی تدریجی بود و پروژۀ شفافیت قراردادها به این کار کمک کرد.

سمیه فروغی: کار به این راحتی نبود، چون دیدیم که مغایرت‌های اطلاعاتی زیادی بین قراردادهایی که تا آن زمان در دو سامانه ثبت شده بود وجود دارد و این خودش از عجایب بود. مثلاً راجع‌ به یک قرارداد واحد، در دو سامانه مغایرت مبلغی و مدتی وجود داشت یا حتی ممکن بود قراردادی در یکی از دو سامانه ثبت شده باشد و در دیگری نه. تازه این را هم در نظر بگیرید که قراردادهایی که ما دنبال انتشار عمومی اطلاعات آن بودیم مربوط به نیمۀ سال ۹۶ به بعد -یعنی آغاز به کار شورای پنجم- بود و به قبل از آن کاری نداشتیم، بااین‌حال باز هم با حجم زیادی از مغایرت‌های اطلاعاتی بین دو سامانه روبه‌رو شدیم. لازم بود که یک مغایرت‌گیری بین اطلاعات دو سامانه صورت بگیرد.

نجمه طاهری: مشکلی که وجود داشت این بود که بین اطلاعاتی که از قبل در رابطه با قراردادهای شهرداری در این دو سامانه ثبت شده بود تعداد زیادی مغایرت وجود داشت و این مغایرت‌ها باید رفع می‌شد تا بتوان دو سامانه را به هم وصل کرد. ما یک ماه پیگیری کردیم تا این ایراد رفع شود و شهرداری هم به‌صورت هفتگی از مغایرت‌های رفع‌شده گزارش می‌داد، مثلاً این هفته می‌گفتند سه‌هزار مغایرت داریم، هفتۀ بعد می‌شد دوهزار و پانصد تا، هفتۀ بعدش هزار تا و بعد هشتصد تا … تا تمام شد. ما یکی-دو ماهی درگیر این موضوع بودیم.

محسن شکری‌پور: پیش از آنکه درگاه ورود اطلاعات قراردادها واحد شود، لازم بود تا مغایرت‌های اطلاعاتی‌ای که از قبل وجود داشت رفع شود. سازمان فناوری موارد مغایرت را درآورد که حدود ده هزار مغایرت می‌شد. قرار شد موارد مغایرت مربوط به هر یک از مناطق را برایشان ارسال کنیم تا خودشان این موارد را بررسی کنند و مقادیر صحیح را در سامانۀ قراردادها وارد کنند. با این فرایند بخشی از مغایرت‌ها رفع شد، اما حدود ۷۰ درصد از مغایرت‌ها باقی ماند. برای اینکه کار در وقت مقرر انجام شود از اکبری در سازمان فناوری خواستم دسترسی‌ای ایجاد کند تا من خودم مغایرت‌های باقی‌مانده را بررسی و رفع نمایم. دقیقاً ساعت نه-ده شبِ ۳۰ مهر به خانم فروغی زنگ زدم و گفتم که مغایرت‌ها صفر شد. […] بعد از آن، ورود دیتای قراردادها فقط از طریق سامانۀ قراردادها انجام می‌شد و درگاه‌های ورودی در سامانه‌های دیگر بسته شد.

این راهکار در حوزه املاک نیز مدنظر قرار گرفت و تلاش شد تا با اتصال سامانۀ املاک به سامانۀ مالی و سامانۀ معاملات، هم به‌تدریج بانک اطلاعاتی املاک شهرداری در سامانۀ املاک کامل شود و هم انواع مختلف معاملات ملکی در سامانۀ معاملات ثبت شود.

سمیه فروغی: آخرین طراحی‌ای که بر سر آن توافق کردیم این بود که اطلاعات ملک در سامانۀ املاک ثبت شود؛ برای این ملک یک کد اموال در سامانۀ مالی تعریف شود؛ و هنگام انجام معامله روی این ملک، سامانۀ معاملات، از طریق آن کد اموال، بفهمد که معامله دارد روی کدام ملک انجام می‌شود. همچنین هنگام انجام معامله، اطلاعاتی همچون متراژ و لوکیشن ملک از طریق سامانۀ املاک در اختیار سامانۀ معاملات قرار گیرد.

در حوزۀ منابع انسانی نیز تلاش شد تا با اتصال سامانۀ منابع انسانی به زیرسیستم حقوق و دستمزد در سامانۀ مالی و منوط‌کردن پرداخت حقوق کارکنان به ثبت اطلاعات ایشان در سامانۀ منابع انسانی، اطلاعات این سامانه کامل و به‌روز شود.

اسحاق بهادری: خب یکی از موضوعاتی که برای تحقق شفافیت اهمیت داشت همین تکمیل اطلاعات پرسنل در سامانه بود […] برای این منظور، ارتباط مستقیمی بین ثبت اطلاعات پرسنل (در سامانۀ جامع منابع انسانی) و پرداخت حقوق به او (از طریق سامانۀ حقوق و دستمزد) ایجاد شد. البته در همین مورد هم باگ‌هایی وجود داشت و در برخی شرایط، ناهم‌خوانی‌هایی بین اطلاعات سامانۀ منابع انسانی و اطلاعات سامانۀ حقوق و دستمزد به وجود می‌آمد […] از طرف دیگر خود محتوای اطلاعات هم نیاز به ویرایش، بازنگری و اصلاح داشت و این هم خودش یک پروسه شد. اگر اشتباه نکنم، ما دو بار امکان اصلاح اطلاعات را روی سامانه برای پرسنل باز کردیم که بیایند و اطلاعات خودشان (اطلاعات شناسنامه‌ای، آدرس محل سکونت، اطلاعات مدارک و رشتۀ تحصیلی و …) را در سامانه اصلاح و مستندات آن را هم بارگذاری کنند؛ یعنی اگر کسی می‌گوید من لیسانس دارم، تصویر مدرک تحصیلی لیسانس و تأییدیۀ لیسانسش را هم بارگذاری کند که بعد بشود راستی‌آزمایی انجام داد. این‌ها اقداماتی بود که به‌عنوان پیش‌نیاز شفافیت حوزۀ منابع انسانی باید انجام می‌گرفت.

پروشات مهرورزی: آن زمان، هر کدام از سازمان‌های شهرداری سامانۀ داخلی خودشان را داشتند و سیستم هنوز یکپارچه نشده بود و تا زمانی هم که به بحث پول و حقوق ربط پیدا نمی‌کرد که اگر اطلاعات در سامانه نباشد خبری از حقوق و دستمزد نیست این یکپارچگی اتفاق نمی‌افتاد.

پیاده‌سازی این ایده نیز بی‌چالش نبود و تا پایان دورۀ پنجم، بودند واحدهایی که به سامانۀ منابع انسانی متصل نشده بودند.

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

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

اتصال سامانۀ سفرهای خارجی به سامانۀ مالی نیز ایده‌ای بود که با هدف بسط استفاده از سامانۀ سفرها، به‌نحوی که امکان فراخوانی برخط اطلاعات از آن روی سایت شفاف وجود داشته باشد، دنبال شد. کیفیت اطلاعات ثبت‌شده در سامانۀ سفرها به حدی پایین بود که انتشار اطلاعات سفرها به‌صورت دستی روی سایت شفاف بارگذاری می‌شد.

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

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

محمد فرجود: در دورۀ قبل یکی از مهم‌ترین توفیقات ما همین بود که ضریب نفوذ سامانه‌های مرکزی را از خیلی کم به نزدیک به کامل‌ رساندیم. […] شهرداری می‌خواست خیالش دربارۀ حوزه‌های مهم مثل منابع انسانی و مالی راحت شود و مطمئن باشد که کسی داده‌ای را جابه‌جا یا دستکاری نمی‌کند. می‌خواست همه‌جا سامانۀ مرکزی خودش را راه بیندازد تا برای مثال بعداً بتواند مسیر همۀ جریانات مالی را در سامانۀ مالی ببیند. بالاخره وقتی واحدهای زیرمجموعه از سامانه‌‌های دیگری استفاده کنند که شما روی آن کنترل ندارید، ممکن است استانداردهایتان در پیاده‌سازی آن سامانه رعایت نشود یا به هر دلیلی دیتا به‌درستی وارد آن نشود یا به‌درستی نمایش داده نشود. ما آن اوایل می‌گفتیم بالاخره شاید آن سامانه‌های مستقل هم امکانات و ویژگی‌های خوبی داشته باشند که سامانه‌های ما ندارند و بنابراین بهتر است واحدها را مجبور نکنیم‌ که به سامانۀ مرکزی متصل شوند. ولی بعد به این نتیجه رسیدیم که اتفاقاً باید این تمرکز و یکپارچگی صورت بگیرد، به‌خاطر اینکه سازمان‌ها یا شرکت‌ها و شهرداری به‌شدت به هم متصل بودند‌ و آن‌قدرها مستقل نبودند‌؛ بودجه‌شان را از شهرداری می‌گرفتند، منابع انسانی‌شان اکثراً در خود شهرداری جابه‌جا می‌شدند و همه‌چیزشان شبیه هم بود‌ و فقط اسماً سازمان یا شرکت مستقل بودند‌ […] دست‌آخر به این نتیجه رسیدیم که بهتر است سامانه را یکی‌یکی در همۀ واحدها پیاده‌سازی کنیم. راه‌اندازی سامانه‌های پایه‌ در همۀ واحدها موجب می‌شد آن‌ها دربارۀ گزارش‌دهی و آماردهی و این قبیل موارد هم دیگر به شهرداری بدهکار نباشند‌.

درواقع ارتقای کیفیت داده‌ها تنها دغدغۀ کمیته شفافیت نبود و در برخی حوزه‌ها، معاونت متولی داده‌ها نیز، با هدف گسترش دامنۀ نظارت خود بر واحدهای زیرمجموعه و بهبود عملکرد (و نه لزوماً با هدف شفافیت و انتشار عمومی اطلاعات)، در این مسیر با کمیتۀ شفافیت همراه بود.

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

محسن شکری‌پور: چند ماه اول که کمیته هنوز شناختی از فرایندهای شهرداری و روال کار نداشت، ما درگیری زیادی نداشتیم. اما بعد از پنج-شش ماه، با تصویب مصوبۀ انجام الکترونیکی و اعلان عمومی اطلاعات معاملات، خواسته‌های کمیته از شهرداری تهران در راستای اجرای آن مصوبه به‌صورت شفاف مطرح شد. معاون مالی و مدیرکل مالی نیز دستور دادند موارد درخواستی خانم آروین انجام شود. البته بسیاری از مواردِ درخواستی از قبل در دستورکار حوزۀ مالی بود، اما پیگیری‌های کمیتۀ شفافیت به انجام آن‌ها سرعت داد. درواقع در بحث شفافیت قراردادها، زمانی رسید که شهردار، روی بخشنامه‌هایی که خانم آروین از طریق نامه‌های رسمی به شهرداری اعلام می‌کرد، با عبارت «جهت اطلاع و اقدام لازم» دستور می‌داد. این به معنای تأکید بر انجام خواسته‌های نامۀ ارسالی بود. در این مرحله، ما هم در سَمت شهرداری همدل شدیم تا کار انجام شود. وگرنه تا پیش از آن، من شخصاً فقط به این دلیل به موضوع شفافیت قراردادها ورود کردم که تمرکز خانم آروین هم بر هدف خود ما، یعنی راه‌اندازی سامانۀ قراردادها، بود.

اسحاق بهادری: کمیته پیگیر بود که اطلاعات پرسنلی کامل شود و اداره‌کل سرمایۀ انسانی، اداره‌کل تشکیلات و اداره‌کل امور مالی (بحث حقوق و دستمزد)، اداره کل برنامه‌ریزی (ارزیابی عملکرد کارکنان) و سازمان بازرسی (به جهت بازخوردهایی که کارمندان ما روی پیام‌های ۱۳۷ و ۱۸۸۸ می‌گرفتند)، همه، بهره‌برداران این اطلاعات بودند و تکمیل اطلاعات پرسنلی به کارشان می‌آمد.

پروشات مهرورزی: طی دو-سه سالی که ما در شورای شهر شفافیت این حوزه را پیگیری می‌کردیم خود قسمت آی‌تی معاونت منابع انسانی خیلی همکاری کرد و اصلاً دغدغۀ آن‌ها هم بود که حتماً دیتای سامانه‌شان اصلاح شود.

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

راهکار دیگری که کمیتۀ شفافیت، برای ارتقای کیفیت داده‌ها در برخی حوزه‌ها، در پیش گرفت، استفاده از نظارت همگانی و فشار افکار عمومی بود. ایده آن بود که به جای آنکه شهرداری، خود، مسئولیت صحت‌سنجی اطلاعات و کامل‌بودن داده‌ها را به عهده گیرد، بازخورد شهروندان روی اطلاعات منتشرشده مکانیسمی را برای تصحیح اطلاعات شکل دهد.

در این راستا، برای هر کدام از اطلاعات منتشرشده روی سایت شفاف، فرد یا واحدی به‌عنوان مسئول صحت اطلاعات تعیین، و این موضوع در سایت شفاف نیز اطلاع‌رسانی شد با این هدف که مسئول مربوطه، به دلیل قرار گرفتن در جایگاه پاسخگویی به افکار عمومی، نسبت به صحت اطلاعات حساس شود. همچنین بهره‌گیری از بازخورد شهروندان برای ارتقای کیفیت اطلاعات، به‌طور خاص، برای انتشار رزومۀ مدیران پیگیری شد، گرچه به دلیل نقص در ورود اطلاعات، انتشار رزومۀ مدیران، آن‌طور که مدنظر کمیتۀ شفافیت بود، هیچگاه انجام نگرفت.

پروشات مهرورزی: شورا در مصوبۀ مدیریت تعارض منافع شهرداری را مکلف کرده بود تا رزومۀ این هشتصدوخرده‌ای مدیر را منتشر کند. قرار بود رزومۀ خوداظهاری این عزیزان منتشر شود. موقعی که دربارۀ این موضوع با معاونت منابع انسانی شهرداری صحبت می‌کردیم، مسئلۀ آن‌ها این بود که معلوم نبود آن مدرکی که مدیر به شهرداری ارائه کرده مثل مدرک دکترای آقای کردان خدا بیامرز تقلبی است یا نه و استعلام‎گرفتن از یک‌سری دانشگاه‌ها هم خیلی سخت و زمان‌بر بود. درواقع معاونت می‌گفت اگر من رزومه‌ها را منتشر کنم نمی‌توانم صحت اطلاعات را تضمین کنم. راه‌حلشان این بود که مدیرانْ اطلاعات رزومه‌شان را خوداظهاری کنند و مسئولیت صحت اطلاعات بر دوش خود فرد اظهارکننده قرار بگیرد. قرار شد یک صفحۀ خوداظهاری ایجاد کنیم و مدیران رزومه‌شان‌شان را آنجا ثبت کنند و آن اطلاعات مستقیماً بیاید روی سامانۀ شفافیت. یادم است که اردیبهشت بخشنامه آمد که هر مدیر عزیزی که تا آخر خرداد این کار را انجام ندهد، نمی‌تواند حقوق بگیرد. دوباره از خرداد تمدید کردند تا شهریور. بااین‌همه، دست‌آخر، از آن هشتصدوخرده‌ای عزیز، تنها ۱۲۹ نفر رزومه‌شان را آپلود کردند. تا سال بعدش فکر کنم تعداد به دویست‌و‌خرده‌ای یا سیصد نفر رسید. ولی بقیۀ عزیزان خیلی وقعی ننهادند.

 

مصاحبه‌کننده: دربارۀ رزومۀ مدیران که گفتید قرار بود مدیران خوداظهاری کنند […] این سیستم خوداظهاری باگ نداشت؟ یعنی اینکه خب طرف می‌توانست هرچه می‌خواهد بگوید.

پروشات مهرورزی: استدلال این بود که طرف می‌آید می‌گوید من اینم و اینم، ولی قطعاً یکی هست که برود نگاه کند و ببیند این آقایی که دارد این اظهارات را بیان می‌کند راست می‌گوید یا نه و آیا مثلاً واقعاً در فلان دانشگاه درس خوانده یا نه. البته فکر می‌کنم موقع ارتقادادن مدیران، صحت مدرکشان از دانشگاه‌ها استعلام می‌شد، ولی چون پروسۀ زمان‌بری بود در کنارش سامانۀ خوداظهاری را هم راه انداختند.

به‌طور کلی، مواردی از گزارش‌های شهروندی و بازخورد افکار عمومی نسبت به اطلاعات منتشرشده اتفاق افتاد که به بهبود کیفیت اطلاعات منتشرشده انجامید:

سمیه فروغی: از طرف شهروندان چند باری گزارش‌هایی به دست ما رسید که راجع به یک قرارداد خاص بود. یعنی مثلاً گفته بودند ما می‌دانیم مبلغ قرارداد فلان که روی سایت گذاشته‌اید اینی که منتشر شده نیست.

بهاره آروین: سر انتشار اطلاعات قراردادها، برای یکی از قراردادهای منطقۀ سه جنجالی به ‌‌‌پا شد. ماجرا این بود که شیوۀ انجام این معامله ترک تشریفات خورده بود، ولی موضوعش طوری بود که ترک تشریفات کردنش بی‌معنی بود و به نظر می‌رسید تخلفی روی داده است. اما بعد مشخص شد که منطقۀ سه با یکی از زیرمجموعه‌‌های خود شهرداری «بدون تشریفات» قرارداد بسته و اپراتور به‌اشتباه شیوۀ عقد قرارداد را ترک تشریفات ثبت کرده. درواقع، ماجرا خطایی بود که اپراتور واردکنندۀ اطلاعات در سیستم مرتکب شده بود. کار داشت تا تغییر شهردار منطقۀ سه پیش می‌رفت، چون ما مسئول صحت اطلاعات منتشرشده را بالاترین مقام هر واحد اجرایی اعلام کرده بودیم.

بهاره آروین: اولین باری که قراردادهای منتشرشده در وب‌سایت شفاف مورد توجه قرار گرفت سر قراردادی مربوط به نظافت دست‌شویی‌‌های حرم امام خمینی بود. فکر می‌کنم مبلغش حدود چهارده ‌میلیارد ریال بود.^[۲۳] در رسانه‌‌ها پخش کردند که برای نظافت دست‌شویی چهارده ‌میلیارد پول شهرداری تهران را هدر داده‌اند! اما وقتی شرح‌خدمات قرارداد را می‌‌دیدی که چند تا دست‌شویی وجود دارد و شامل چه خدماتی است و اینکه این مبلغ سالانه است و ماهش چقدر می‌شود خیلی چیز عجیب‌وغریبی نبود و با کمی حساب‌وکتاب به نظر معقول می‌آمد. ما از این جنجال به‌وجودآمده استفاده کردیم و به شهرداری گفتیم راه‌افتادن این ماجراها نشان می‌دهد که «شرح‌خدمات» قراردادها هم باید منتشر شود. البته عملی‌کردنش به این راحتی‌ها هم نبود و می‌‌شد تصور کرد که اگر مداومت و پیگیری شورا نبود همان یک قرارداد و حواشی‌اش می‌‌توانست باعث شود سیستم کلاً از انتشار اطلاعات قراردادها پشیمان شود، چون دیده بود که از بین چند هزار قرارداد منتشرشده، دقیقاً آنی که پتانسیل این را داشته که با استفاده از فضای عمومی علیه مجموعه استفاده شود برجسته شده.

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

اما علی‌رغم گزارش‌های محدودی که ارائه شده بود، بنا بر تجربۀ پروژۀ شفافیت، به نظر می‌رسد برای آنکه مکانیسم تصحیح اطلاعات بر اثر گزارش‌های مردمی شکل گیرد و فعال شود، به چیزی بیش از انتشار عمومی اطلاعات نیاز است:

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

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

اسحاق بهادری: یکی از موضوعاتی که ما پیگیری می‌کردیم همین بود که ما اطلاعات مدیران را از طریق اکسل به سازمان فاوا ندهیم و طوری باشد که اطلاعات به‌صورت اتوماتیک منتشر شود. این اتفاق هم افتاد اما بعد از یک دورۀ زمانی خیلی طولانی […] تا جایی که من حضورذهن دارم، می‌دانم که انتشار اطلاعات مدیران کاملاً برخط شد و با فراخوانی اطلاعات از سامانه انجام می‌شد. مگر اینکه در این مدت اتفاق دیگری افتاده باشد.

پروشات مهرورزی: تمام تلاش من این بود که کل این فرایند [انجام سفر خارجی] سامانه‌ای شود، امضاها الکترونیک شود و همه‌چیز در سامانه ثبت شود. ولی هم مسئلۀ سفرهای ناگهانی که «حالا حکمش را بزن بره» وجود داشت و هم مسائل مربوط به ویزاگرفتن که سامانه‌ای‌کردن فرایند و اینکه مراحل به‌ترتیب انجام شود را سخت می‌کرد. آخرهای دوره، کارها کمی مرتب شده بود و بعضی‌ها واقعاً گزارش سفر را ثبت می‌کردند و این گزارش‌ها واقعاً قابل‌استناد بودند، ولی درنهایت انتشار اطلاعات روی سایت شفافیت به‌صورت دستی باقی ماند [… اگر به نقطۀ شروع برمی‌گشتم] احتمالاً روی قضیۀ گلوگاه مالی و اینکه مثلاً تا وقتی اطلاعات سفر در سامانۀ سفرها ثبت نشده، ارز تعلق نگیرد بیشتر کار می‌کردم. فکر می‌کنم از آن طریق به‌هرحال می‌شد یک کاری کرد. به نظرم اگر برای این کار مصوباتی داشتیم یا مثلاً به کمک معاونت منابع انسانی بخشنامه‌هایی ابلاغ می‌کردیم می‌شد سامانۀ مالی را به سامانۀ سفرهای خارجی متصل کرد، اما خب دیر شروع کردیم.

محسن شکری‌پور: خانم آروین درمورد سازمان املاک هیچ‌وقت به نتیجه‌ای که مدنظرش بود نرسید. بعد از یک سال که از همکاری من با خانم آروین می‌گذشت، در جلسه‌ای که با سازمان املاک داشتیم، به آن‌ها گفتم که سامانه‌شان را باید عوض کنند و سامانۀ جدیدی هم بالا نیاورند. به‌جایش ما فرایندهایشان را در سامانۀ قراردادها پیاده‌سازی می‌کنیم.[…] آن زمان، معاون برنامه‌ریزی سازمان املاک موافق انجام این کار بود اما سازمان فناوری، با این استدلال که من متولی این امرم و برای سامانۀ املاک هزینه کرده‌ام و قرار است سامانۀ املاک توسعه پیدا کند و تمامی موارد موردنظر شما در بحث معاملات هم در آن دیده شده است، درنهایت قبول نکرد. این در حالی است که از دو سال پیش، تازه رسیدند به این حرف که سامانۀ املاک فعلی قابلیت‌های لازم را ندارد.

اکبری: سازمان املاک از جمله واحدهایی بود که علناً می‌گفت نمی‌خواهیم روی سامانۀ مرکزی بیایم.

سمیه فروغی: املاک حوزۀ شکست ما بود و شاید ناخودآگاه خیلی دلمان نمی‌‌خواهد از شکست‌‌ها صحبت کنیم. [می‌خندد] اتفاقاً چند وقت پیش داشتم فکر می‌‌کردم که اگر یک عضو شورا بخواهد چهار سال روی یک حوزه به‌صورت متمرکز کار کند […] خوب است چه حوزه‌ای را انتخاب کند. ذهنم سمت چیزهای مختلفی از جمله املاک هم رفت، مثلاً یک عضو شورا باشد که هفته‌ای دو بار در جلسات صحن بحث املاک را مطرح کند و از اقدامات و تغییرات گزارش دهد و پیگیری مداوم داشته باشد. ولی بعد به نظرم آمد که این حوزه واقعاً حوزه‌ای نیست که به این راحتی بتوانی در آن تغییری صورت بدهی؛ این‌قدر گیروگور دارد که من خیلی خوش‌بین نیستم که اگر یک نفر کل چهار سال را هم روی این حوزه تمرکز کند، بتواند کار خاصی انجام دهد.

در پایان شاید بد نباشد به این سؤال فکر کنیم چه چیز داده باکیفیت می‌سازد؛ چه عاملی باعث شد اطلاعات سامانۀ شهرسازی کیفیت بالایی داشته باشد اما چنین وضعیتی درمورد اطلاعات معاملات صدق نکند؟

در مورد سامانۀ شهرسازی می‌توان گفت که این سامانه از قدیمی‌ترین سامانه‌های شهرداری بود که طی سال‌ها بسیار فربه شده بود و تمامی امور مربوط به حوزۀ شهرسازی از طریق آن انجام می‌گرفت؛ در واقع اطلاعات ثبت‌شده در این سامانه، محل رجوع و مورداستفادۀ شهرداری بود و کیفیت بالاتری داشت.

میثم درویشی: درخصوص حوزۀ شهرسازی، نکتۀ مثبت این بود که سامانۀ آن از قبل استقرار یافته بود و از آنجا که بخش عمده‌ای از درآمد شهرداری از این حوزه تأمین می‌شود، سازمان فاوا و شهرداری برای آن برنامه‌ریزی ویژه داشتند. خوشبختانه نظم خاصی در این حوزه حاکم بود و واحدهای مختلف، طبق رویه‌های مشخص، دیتاهای خود را وارد سامانه شهرسازی می‌کردند.

این در حالی است که ثبت‌نشدن یا ثبت اشتباه اطلاعات معاملات در سامانۀ معاملات اخلالی در فرایند انجام معامله ایجاد نمی‌کرد چون روال‌های کاغذی هنوز کارایی داشت و در انجام معاملات، سامانۀ معاملات مورداستناد نبود. به دلیل آنکه کیفیت پایین اطلاعات در این سامانه تبعاتی نداشت، کسی هم پیگیر رفع خطاهای اطلاعاتی در سامانه نبود. در مقابل، اسناد کاغذی معاملات، به دلیل آنکه محل رجوع بودند، واجد جامعیت و اعتبار بودند (البته جامعیت در اینجا با جامعیتی که در سامانه دنبال می‌شد متفاوت است. در سامانه، همه اطلاعات به‌صورت متمرکز در یک پایگاه داده‌ای واحد جمع است. در حالت کاغذی، اسناد بین واحدهای زیرمجموعه پراکنده است).

به‌طور کلی، مجموعه‌های داده‌ای به‌طور خودبه‌خود باکیفیت نمی‌شوند و کیفیت بنا بر ضرورت و کارکرد ایجاد می‌شود:

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

 

مصاحبه‌کننده: این اشتباهاتی که در ثبت داده در سامانۀ منابع انسانی وجود داشت، برای شهرداری ایجاد مشکل نمی‌کرد؟

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

پروشات مهرورزی: [برای آنکه مدیران رزومه‌های خود را ثبت کنند] باید یک فشار بالادستی به مدیران وارد می‌شد. درواقع مدیران با خودشان فکر می‌کردند منی که این‌قدر سرم شلوغ است این دیگر چه کار چرت‌وپرتی است که باید انجام دهم. یعنی به نظرم این‌طور نبود که با خودشان فکر کنند شایستۀ جایگاهی که دارند نیستند و نگران باشند انتشار رزومه برایشان دردسر شود. اتفاقاً فکر می‌کنم خودشان را شایسته می‌دانستند و بیشتر سؤالشان این بود که این دیتا به چه دردِ چه کسی می‌خورد. راستش ما هم نرفتیم به سمت اینکه دربارۀ ضرورت انجام این کار توجیهشان کنیم.

نجمه طاهری: تا قبل از این، چیزی که برای شورا اهمیت داشت نتیجۀ رأی‌گیری بود، لذا فقط تعداد مخالفان و موافقان در برگۀ رصد نوشته می‌شد. اما ما دنبال این بودیم که اسامی کسانی که رأی مخالف یا موافق داده بودند هم در برگۀ رصد مشخص باشد و موارد دیگری مثل ساعت شروع و پایان جلسه را هم می‌خواستیم که ثبت شود. ولی این چیزها برای کارمندان شورا اصلاً مهم نبود و آن اوایل منظور ما را از خواسته‌هایی که داشتیم نمی‌‌فهمیدند.

مهدیه آقاملایی[۲۴]: رأی‌گیری خیلی تأثیری برای ادارۀ مصوبات ندارد؛ فرمانداری فقط ترکیب آرا را از ما می‌خواهد چون قانون می‌گوید اگر دوسوم اعضای حاضر به پیشنهادی رأی موافق بدهند، مصوب می‌شود. هیچ‌وقت نمی‌پرسد چه کسی رأی داده یا کاری ندارد که چه کسی رأی مثبت و چه کسی رأی منفی داده است. شاید فقط در مواقعی که رأی‌ها لب مرز بود نیاز می‌شد تا از طریق رأی‌گیری الکترونیکی چک کنند که تعداد رأی‌های مثبت و منفی درست محاسبه شده است یا نه. وگرنه رأی‌گیری الکترونیکی، در حوزۀ کاری من، نقشی در ابلاغ مصوباتمان ایفا نمی‌کرد.

مورد استفاده قرار گرفتن اطلاعات و محل رجوع بودن آن عاملی است که موجب ارتقای کیفیت داده‌ها می‌شود و مثال مهم آن، داده‌های مالی است. به قول یکی از مصاحبه‌شوندگان، داده‌های سامانۀ مالی «واقعی» است:

اکبری: از بین این دو سامانه [سامانۀ مالی و سامانۀ قراردادها]، تیم شفافیت به این نتیجه رسید که اطلاعات سامانۀ مالی معتبر است و اطلاعات سامانۀ قراردادهاست که مشکل دارد، چراکه دیتای سامانۀ مالی دیتای واقعی در دنیای واقعی است؛ سامانۀ مالی دیتای پولی که دارد خرج می‌شود را نگه می‌دارد و این دیتا نمی‌تواند غیرواقعی باشد.

محمدنادر محمدزاده[۲۵]: من همیشه این را می‌گویم که شما وقتی می‌خواهید حوزه‌ای را منظم کنید، نبضش در حوزۀ مالی است؛ یعنی اگر شما بتوانید سیستم مالی را به هر سیستم دیگری گره بزنید، آن حوزه منظم می‌شود. چون مثلاً شما وقتی ملکی را معامله می‌کنید،حتی اگر پول ندهید و پول نگیرید و به جایش ملک بدهید یا ملک بگیرید، باز هم باید اضافه یا کم‌شدن این دارایی را ثبت کنید. اگر سیستم مالی را به حوزۀ املاک گره بزنیم، هرچه در حوزۀ املاک انجام می‌شود دیگر قابل پنهان‌کردن نیست، چون یکی از حوزه‌هایی که به‌قول معروف باید «صفر» بگیرد تا کارش درست باشد حوزۀ مالی است. حوزۀ مالی باید اختلاف ترازش صفر باشد. در این حوزه نباید چیزی روی هوا باشد.

به همین دلیل هم بود که کمیتۀ شفافیت، در موارد متعددی، تضمین کیفیت داده‌ها را از طریق گره‌زدن روال انجام کار به امور مالی (اتصال سامانه‌های مرتبط به سامانۀ مالی) دنبال کرد. البته «واقعی‌بودن» داده‌های سامانۀ مالی نیز همیشه برقرار نبود، به‌خصوص درمورد سازمان‌ها و شرکت‌های تابعه شهرداری که لزوماً از سامانۀ مالی مرکزی شهرداری استفاده نمی‌کردند:

مصاحبه‌کننده: پس عملاً تا پایان دورۀ پنجم دیگر کمبود اطلاعاتی در سامانۀ منابع انسانی وجود نداشت.

اسحاق بهادری: کمبود اطلاعات وجود داشت؛ چون در فرایند پرداخت حقوق و دستمزد، بعضاً این امکان وجود داشت که برخی پرداخت‌ها با فرایند دیگری صورت بگیرد. گرفتید چی شد؟ […] راه‌های مختلفی وجود دارد که اطلاعات برخی پرداخت‌ها مستقیماً در امور مالی ننشیند، مثل دادن بن یا پاداش نقدی […] ناممکن نبود که سازمان‌ها و شرکت‌ها، بدون آنکه اطلاعات مدیرانشان در سامانه ثبت شده باشد هم، پرداختیِ آن‌ها را محاسبه و واریز کنند (مثلاً از طریق چک). این موضوع، درعمل، شیوع زیادی نداشت اما احتمالاً علت مقاومت برخی واحدهای تابعه در برابر پیوستن به سامانۀ منابع انسانی همین بوده است که اختیار پرداختی‌هایشان به مدیران دست خودشان باشد.

پروشات مهرورزی: یک زمانی خانم آروین گفتند که پس برویم ببینیم گلوگاه‌های مالی این سفرهای خارجی کجاست. در انتها به این رسیدیم که قطعاً هزینه‌های سفر باید ردپایی در سامانۀ مالی شهرداری داشته باشد و از طریق این دیتا شاید بتوانیم اطلاعات سامانۀ سفرهای خارجی را کامل کنیم. اما یادم است که باز هم یک مشکلی در سامانۀ مالی وجود داشت که نشد این کار را بکنیم. یعنی طوری نبود که بنا بر اطلاعات ثبت‌شده در سامانۀ مالی بتوان با قطعیت گفت فلان سفر انجام شده است.

سمیه فروغی: هر کدام از سازمان‌ها و شرکت‌های زیرمجموعۀ شهرداری را که به سامانۀ قراردادها پیوند می‌دادیم و اطلاعاتشان روی شفاف می‌رفت، خیلی خوشحال می‌شدم […] ولی خب یک جاهایی هم ماجرا برعکس و دقیقاً نقطۀ مقابل این چیزی که تعریف کردم می‌شد، مثلاً اینکه بعد از چند سال، سازمان املاک برای امور مالی و املاکی خود همچنان از سامانۀ مستقل خودش استفاده می‌کرد.

اکبری: سازمان املاک از جمله واحدهایی بود که علناً می‌گفت نمی‌خواهیم روی سامانۀ مرکزی بیایم.

به‌عنوان جمع‌بندی، جا دارد مجدداً به این نکته اشاره کنیم که راه‌اندازی سامانه در سازمان لزوماً به معنای تولید مجموعه‌داده‌های قابل‌اتکا و قابل استفاده نیست؛ در بررسی گزارش‌هایی که مبتنی بر داده‌های ثبت‌شده در سامانه‌ها ارائه می‌شود، پیش از توجه به محتوای گزارش، می‌بایست کیفیت داده‌هایی را که گزارش بر مبنای آن تهیه شده است مورد بررسی قرار داد.

اگر خواندن متن حاضر، تمایز بین داشتنِ داده و داشتنِ دادۀ باکیفیت را در ذهن شما نشانده باشد، پروژهٔ مستندنگاری به هدف خود رسیده است.

---

سؤالاتی جهت بحث و بررسی بیشتر:

1. راهکارهای فنی برای تضمین کیفیت داده‌ها، نظیر اتصال سامانه‌ها، در چه شرایطی کارآمدند و در چه شرایطی نتیجۀ موردنظر را به دنبال ندارند؟ (برای مشاهدۀ بحثی درخصوص تمایز راهکار فنی و راهکار غیرفنی نگاه کنید به متن «دربارۀ رابطۀ فناوری و تحول سازمانی»)
2. به جز راه‌اندازی سامانه‌های مرکزی، چه مدل‌های دیگری برای ایجاد یکپارچگی اطلاعاتی در سازمان‌های گسترده وجود دارد و شرط کارآمدی آن‌ها چیست؟
3. عوامل مؤثر بر کیفیت داده‌ها چیست؟ چه چیز دادۀ باکیفیت می‌سازد؟

 

[۱] کارشناس کمیتۀ شفافیت و شهر هوشمند

[۲] رئیس ادارۀ درگاه‌های اینترنتی شهرداری تهران

[۳] معاون برنامه‌ریزی و فناوری حراست کل شهرداری تهران

[۴] مدیرعامل سازمان «فناوری اطلاعات و ارتباطات» شهرداری تهران

[۵] (نام مستعار) کارشناس سازمان فناوری اطلاعات و ارتباطات در حوزه امور مالی

[۶] مدیرکل «سرمایۀ انسانی» ذیل معاونت «برنامه‌ریزی، توسعۀ سرمایۀ انسانی و اموری شورا»ی شهرداری تهران

[۷] کارشناس دفتر بهاره آروین و رئیس دبیرخانۀ ستاد ارتقای سلامت اداری و مبارزه با فساد شهرداری تهران در دورة بعد از آن

[۸] منظور مصوبۀ «مدیریت تعارض منافع در شهرداری تهران»، مصوب ۱۰/۰۷/۱۳۹۷ با اصلاحات بعدی » است.

^[۹] ترک تشریفات روشی است غیر رقابتی (عدم برگزاری مزایده یا مناقصه) جهت تأمین نیازهای سازمان در شرایط خاص، که برگزاری فرایند تشریفات به صلاح نباشد و منجر به ازبین‌رفتن منافع سازمان شود.

^[۱۰] طبق آیین‌نامۀ مالی و معاملاتی شهرداری، عقد قرارداد با واحدهای زیرمجموعه بدون تشریفات مجاز است.

[۱۱] کارشناس کمیته شفافیت و شهر هوشمند

[۱۲] کارشناس کمیتۀ شفافیت  و شهر هوشمند

[۱۳] منظور کمیسیونی است که بنا بر مادۀ ۷ آیین‌نامۀ اجرایی مادۀ ۱ قانون «اصلاح لایحۀ قانونی حفظ و گسترش فضای سبز در شهرها» تشکیل می‌شود. ترکیب اعضای این کمیسیون در کلان‌شهرها عبارت است از: دو نفر از اعضای شورای اسلامی شهر، یکی از معاونان شهردار، رئیس یا مدیرعامل سازمان بوستان‌ها و فضای سبز شهر، یک قاضی رسمی دادگستری. اخذ نظر این کمیسیون درخصوص نوعیت ملک (باغ بودن یا نبودن) یکی از مراحل صدور پروانه‌های ساختمانی است.

[۱۴] کمیسیونی است متشکل از نمایندۀ وزارت کشور، یک نفر از قضات دادگستری و یکی از اعضای شورای شهر که بنا بر مادۀ ۱۰۰ قانون شهرداری‌ها وظیفۀ رسیدگی به تخلفات ساختمانی اعم از ساخت‌وساز بدون پروانه و ساخت‌وساز مخالفت با مفاد پروانه را دارد.

[۱۵] آی‌پی (Internet Protocol) سرواژۀ انگلیسی مخفف پروتکل اینترنت است. پروتکل اینترنت نشانی عددی است که به هریک از دستگاه‌ها و رایانه‌های متصل به شبکۀ رایانه‌ای که بر مبنای مجموعه پروتکل اینترنت کار می‌کند اختصاص داده می‌شود.

[۱۶] اداره‌کل «امور مجامع و حسابرسی» ذیل معاونت «مالی و اقتصاد شهری» شهرداری تهران

[۱۷] سازمان «بوستان‌ها و فضای سبز شهر تهران» ذیل معاونت «خدمات شهری و محیط‌زیست» شهرداری تهران. نام قبلی این سازمان «پارک‌ها و فضای سبز شهر تهران» بوده است.

[۱۸] یکی از شرکت‌های ذیل معاونت «حمل‌ونقل و ترافیک» شهرداری تهران

[۱۹] شرکت واحد اتوبوسرانی تهران و حومه، ذیل سازمان «حمل‌ونقل و ترافیک» شهرداری تهران

[۲۰] نمایندۀ اداره‌کل‌های «امور مالی و اموال» و «حقوقی» شهرداری در اجرای مصوبۀ «الزام شهرداری تهران به انجام الکترونیکی و اعلان عمومی اطلاعات معاملات شهرداری»

^[۲۱] تبصرۀ ۲۱ بودجۀ ۹۹ شهرداری تهران:

به منظور ایجاد هماهنگی و پرداخت به‌موقع حقوق و مزایای مستمر کارمندان و کارگران رسمی و قراردادی، مأمورین انتظامی و پرسنل تأمین نیروی انسانی:

الف) …

ب) کلیۀ واحدهای اجرایی اعم از ستاد، مناطق، سازمان‌ها، شرکت‌ها و مؤسسات موظف به ثبت یا به‌روزرسانی اطلاعات کارکنان رسمی، قرارداد کار معین و مشخص و قرارداد کارگری در پایگاه اطلاعات کارکنان شهرداری تهران و استقرار سامانۀ جامع منابع انسانی تا پایان اردیبهشت ۱۳۹۹ می‌باشند.

پ) از ابتدای تیر ماه ۹۹، تخصیص اعتبار و پرداخت حقوق کارکنان رسمی و قراردادی، کارگری و غیره صرفاً بر اساس اطلاعات «پایگاه اطلاعات کارکنان شهرداری تهران» و «سامانۀ جامع منابع انسانی» صورت می‌گیرد.

[۲۲] مشاور بهاره آروین و عضو گروه راهبری کمیتۀ شفافیت و شهر هوشمند

^[۲۳] بنا بر اطلاعات منتشرشده روی سایت شفاف، رقم دقیق این قرارداد ۰۰۰/۴۰۰/۹۶۰/۱۴ ریال بوده است.

[۲۴] رئیس ادارۀ مصوبات و تنقیح مقررات شورای شهر

[۲۵] رئیس سازمان املاک شهرداری تهران