مصاحبه‌کننده: لطفاً خودتان را معرفی کنید و بفرمایید چه شد که مدیرعامل سازمان فاوای شهرداری شدید.
محمد فرجود: من محمد فرجود هستم. سال ۱۳۷۹ وارد دانشگاه صنعتی‌شریف شدم و بعد از تحصیل در رشتهٔ مهندسی مکانیک، بلافاصله در همان دانشگاه در رشتهٔ MBA (ارشد مدیریت کسب‌وکار) وارد مقطع فوق‌لیسانس شدم. از همان موقع هم در حوزهٔ مدیریت تکنولوژی و مدیریت نوآوری در مرکز مطالعات تکنولوژی دانشگاه شریف درگیر کار شدم. آنجا روی پروژههای مختلفی، عمدتاً در حوزه‌های فناوری و نوآوری، کار می‌کردیم که بعضی از آنها از جنس سیاست‌گذاری و بعضی از جنس ارائهٔ مشاوره به مجموعه‌های مختلف بود. برمبنای همین تجربه از من دعوت شد تا در ایجاد مجموعه‌ای جدید ذیل شرکت سرمایه‌گذاری تأمین اجتماعی (شستا) همکاری کنم. به این ترتیب من معاون شرکت تازه‌تأسیسی به نام شرکت مدیریت صنایع نوین تأمین (شمص تأمین) شدم که به‌عنوان هلدینگ تخصصی زیرمجموعهٔ شستا در حوزه فناوری‌های نوین فعالیت می‌کرد. چند سالی آنجا بودم و روی پروژههای مختلفی کار کردیم. چند شرکت در حوزهٔ بیوتکنولوژی و فناوری اطلاعات و مخابرات ایجاد کردیم. یکی از آنها پروژهٔ اپراتور سوم موبایل بود که بعد نامش رایتل شد. چند سالی هم در رایتل و بعد در ایرانسل مشغول به کار بودم. بعد هم به‌عنوان مدیرعامل سازمان فناوری اطلاعات در شهرداری تهران مشغول به کار شدم.
داستان آمدنم به شهرداری هم این بود که من در ایرانسل، در حوزهٔ کسب‌وکار سازمانی، کارهای مختلفی از قبیل توسعهٔ سرویس و مشتریان سازمانی و تکنولوژی‌های جدید میکردم. یکی از حوزههایی که ما روی آن کار می‌کردیم هم اسمارت سیتی بود. زمانی که آقای نجفی شهردار شد، تعدادی از فارغ‌التحصیلان دانشگاه صنعتی شریف که خیلی‌هایشان از شاگردهای قدیمی‌شان بودند با ایشان وارد شهرداری شدند و مسئولیت واحدها و سازمانهای مختلفی را برعهده گرفتند. روال این بود که برای انتخاب مدیران عامل سازمانها و شرکت‌ها، از جاهای مختلفی افرادی پیشنهاد می‌شدند و رزومه‌های آنها ارسال می‌شد و نهایتاً شهردار یک نفر را از میان آنها انتخاب می‌کرد. اما درمورد سازمان فاوا، آقای نجفی گفته بود انتخاب مدیرعامل توسط یک تیم تخصصی انجام شود. یکی از دوستانم که با آن تیم در تماس بود به من گفت که رزومهٔ من را به آن تیم داده تا با من صحبت کنند.
من تا آن زمان نه خیلی کار دولتی کرده بودم و نه به آن علاقه‌مند بودم، بنابراین در وهلهٔ اول تمایل چندانی به قبول مدیرعاملی سازمان فاوا نداشتم. اما در صحبت‌هایی که با آن تیم داشتیم احساس کردم می‌توان از این طریق اثرگذار بود. آقای نجفی هم جلسه‌ای با من گذاشتند و گفتند من می‌خواهم شما روی اسمارت سیتی تمرکز کنی و آن را اینجا پیاده کنی و اینجا را تغییر دهی.
به این ترتیب من اواخر سال ۹۶ به شهرداری آمدم. این مسیر ورود من به شهرداری بود. تا پیش از ورودم به سازمان فاوا، شهرداری را چندان نمی‌شناختم. و پیش از آن تجربۀ همکاری با شهردار وقت آقای دکتر نجفی را هم نداشتم. ایده این بود که مدیرعاملی سازمان فاوا یک پست تخصصی است و من هم با این فرض وارد شدم که می‌خواهم کار تخصصی انجام دهم.
مصاحبه‌کننده: تیمی که قرار بود با شما در سازمان فاوا کار کنند را خودتان آوردید یا از نیروهای خود سازمان فاوا استفاده کردید؟
محمد فرجود: من تیم خاصی با خودم نیاوردم؛ معمولاً این کار را نمی‌کنم. وقتی از رایتل به ایرانسل رفتم، تیمی که در رایتل داشتم همه در رایتل ماندند. از ایرانسل هم که آمدم تقریباً هیچ‌کس را با خودم نیاوردم.
وقتی وارد شهرداری شدم، آقای قائمی که قبل از من دوازده سال -یعنی تمام دورهٔ آقای قالیباف- مدیرعامل سازمان فاوا بودند در سازمان بیمهٔ سلامت مسئولیت پذیرفته بودند. با رفتن ایشان، ظرف چند ماه، سه نفر از معاونان کلیدی سازمان فاوا جهت انتقال به آن مجموعه از سازمان فاوا جدا شدند. از طرف دیگر، در همین دوره جذب نیرو در شهرداری متوقف شد مگر با اخذ اجازهٔ شهردار، که آن هم کار خیلی سختی بود. در این شرایط و با توجه به مدت چندماهه‌ای که با تیم قبلی سازمان کار کرده بودم، تصمیم گرفتم از ظرفیت نیروهای خود سازمان استفاده کنم. درنتیجه اکثر معاونانی که گذاشتم از مدیران خود سازمان بودند. سعی کردیم یک مکانیسم جدید هم بگذاریم؛ برای بعضی از پوزیشن‌ها با افراد مصاحبه می‌کردیم و از بیرون چند مشاور گرفتیم که آنها را ارزیابی کنند. اما بههرحال هم آن موقع و هم بعد از آن، عمدتاً افراد را از داخل شهرداری به کار گرفتیم. یعنی تعداد نیروهایی که ما از بیرون آوردیم، جز برای موضوع شهر هوشمند که موضوعی جدید و تخصصی بود و تجربهٔ چندانی درمورد آن در سازمان وجود نداشت، نسبت به نیروهایی که از داخل خود شهرداری برای اکثر معاونت‌ها و انجام کارهای حوزه‌های اصلی به کار گرفتیم خیلی کمتر بود.
مصاحبه‌کننده: اولین مواجههٔ شما با پروژهٔ شفافیت شورا و شهرداری چطور صورت گرفت؟
محمد فرجود: ما در سازمان فاوا، همان اوایل دورهٔ پنجم، یعنی سال ۹۶ و ابتدای سال ۹۷، بررسی و تحقیق زیادی درمورد اسمارت سیتی انجام دادیم تا ببینیم شهر هوشمند چیست، تجربهٔ بقیهٔ کشورها و شهرها چیست و باید چه کار کنیم؛ اسناد بالادستی را خواندیم، انواع گزارش‌های موجود را بررسی کردیم و دانشگاه شریف هم یک کار مطالعاتی درمورد تجربهٔ بقیهٔ شهرهای دنیا برای ما انجام داد، و در همین حین، مواردی را که احتمالاً باید روی آنها کار می‌کردیم شناسایی کردیم. از جملهٔ آنها، بحث اوپن دیتا و شفافیت بود. می‌خواهم بگویم از همان ابتدا، مطالعه روی دیتا و دسترسی مردم به داده و عدالت داده‌ای -که کشورهای مختلف دنیا تجارب زیادی در این زمینه‌ها داشتند- در دستورکار ما قرار داشت. ایدهٔ اولیهٔ سایت شفاف را هم خود ما در همان اواخر سال ۹۶ دادیم. به‌طور موازی، در شورا و شهرداری نیز موضوع شفافیت شروع شده بود. لذا مقرر شد درگاهی با موضوع شفافیت ایجاد شود و برخی داده‌هایی که مردم تا به حال به آنها دسترسی نداشته‌اند روی آن قرار داده شود. آخر سال ۹۶، اولین باری بود که ما اسم شفاف را برای آن درگاه مطرح کردیم و بعدش هم سایت shafaf.tehran.ir را ایجاد کردیم.
مصاحبه‌کننده: اگر بخواهیم دقیق بگوییم، از سایت شفاف اواخر فروردین ۹۷ با اطلاعات مناقصات بالای یک میلیارد شهرداری رونمایی شد.
محمد فرجود: بله، همین‌طور است. یادم است اسم شفاف را در یکی از جلسات درونی خودمان در سازمان فاوا انتخاب کردیم. اتفاقاً بعداً هم دولت به همهٔ دستگاه‌های اجرایی ابلاغ کرد که آدرس درگاه شفافیت خودشان را دامنه‌ای با پیشوند شفاف قرار دهند.
پس سایت شفاف آخر سال ۹۶ بالا آمد و سال ۹۷ هم دیتای مناقصات عمده روی آن بارگذاری شد. احتمالاً این اتفاق بر اساس صحبت‌هایی که با شورا داشتیم افتاد، اما می‌خواهم بگویم خود ما هم از قبل درمورد شفافیت و دادهٔ باز[۱] مطالعه داشتیم.
مصاحبه‌کننده: پس این‌طور که می‌گویید، در رابطه با موضوعات مدنظر کمیتهٔ شفافیت، خودتان هم برنامه‌ها و ایده‌هایی داشتید.
محمد فرجود: بله، البته قاعدتاً بخشی از برنامه‌ها و ایده‌های ما از دل همان تعاملات با شورا و کمیته شکل گرفت، اما درعین‌حال خود ما هم به‌طور مستقل درگیر موضوعاتی مثل دادۀ باز و ای‌پی‌آی[۲] باز و شفافیت بودیم.
مصاحبه‌کننده: وقتی ما با دوستان کمیتهٔ شفافیت صحبت می‌کنیم یا حتی دستورجلسات یا صورت‌جلسات کمیتهٔ شفافیت با شهرداری را می‌خوانیم حضور پررنگ سازمان فاوا در جلسات و اینکه سازمان فاوا پای ثابت جلسات کمیتهٔ شفافیت بود خیلی بارز است. کمیتهٔ شفافیت از سازمان فاوا چه می‌خواست؟
محمد فرجود: ببینید، کمیتهٔ شفافیت و شهر هوشمند جزء کمیته‌هایی بود که خیلی با هم کار داشتیم، هم نگاه‌ها نزدیک بود و هم دغدغه‌ها. دغدغهٔ خانم آروین و تیم ایشان شفافیت بود و من هم که از ابتدا با اولویت پیاده‌سازی شهر هوشمند به شهرداری آمده بودم و این موضوع برای من خیلی جدی بود. به این ترتیب رویکرد ما خیلی به هم نزدیک بود و در اصلِ موضوع اختلاف نظر نداشتیم. ما هم علاقه‌مند بودیم و هم می‌دانستیم که یکی از موضوعات جدی در اکثر شهرهای هوشمند فراهم‌کردن هرچه بیشترِ دسترسی ذی‌نفعان به دیتاست. از آن طرف کمیته هم همین را می‌خواست. درنتیجه روی این هم‌نظر بودیم که شفافیت و انتشار داده کار مهمی است.
درخصوص نحوهٔ اجرا، سازمان فاوا باید ابزار مناسب را ارائه می‌داد. در این رابطه، مسئله‌ای که با آن روبه‌رو بودیم این بود که چه کسی تصمیم بگیرد که چه داده‌ای روی سایت شفاف برود. راجع به این موضوع، به‌خصوص بعد از راند اول انتشار اطلاعات و گسترش تدریجی حوزه‌های انتشار اطلاعات، بحث‌های زیادی شروع شد. به یادم دارم که سر انتشار حقوق مدیران شهرداری، بخش‌های مختلف نظرات مختلفی داشتند. مثلاً معاونت منابع انسانی میگفت حقوق مدیران را منتشر کنیم اما نه با جزئیات. یا مرکز ارتباطات و روابط بین‌الملل شهرداری هم درخصوص انتشار اطلاعات سفرهای خارجی ملاحظاتی داشت و از زاویهٔ ملاحظات خودش خواسته‌هایی را مطرح می‌کرد.
بنابراین ما با چالش فرایند تصمیم‌گیری بر سر اینکه کدام داده منتشر شود یا نشود مواجه بودیم. من چندین بار، خیلی واضح به خانم آروین و دیگر واحدهای شهرداری گفتم که مسئولیت تصمیم‌گیری درخصوص محتوایی که روی سایت شفاف منتشر می‌شود بر عهدهٔ واحدهای تخصصی متولی آن داده است و سازمان فاوا نمی‌تواند مسئول تمام محتوای منتشرشده باشد. معتقد بودم حتماً باید کمیته‌ای وجود داشته باشد که علاوه بر تأیید صحت داده، راجع به اینکه چه داده‌ای منتشر شود هم تصمیم بگیرد. بالاخره قرار بود اطلاعات گوناگونی روی سایت شفاف برود، یک روز بحث انتشار اطلاعات قراردادها بود، یک روز اطلاعات شهرسازی، یک روز اطلاعات حقوق مدیران، یک روز اطلاعات سفرهای خارجی. می‌گفتم اگر سازوکار مشخصی برای تصمیم‌گیری دربارهٔ انتشار یا عدم انتشار دادهها وجود نداشته باشد، هر دفعه که اطلاعاتی می‌خواهد منتشر شود یکی مدعی می‌شود و کار پیش نمی‌رود.
همان موقع سر انتشار اطلاعات مدیران به یاد دارم که لیست اولیهٔ اطلاعات را تیم ما از دیتابیس سامانه‌ها استخراج کرد. اطلاعات را به معاونت منابع انسانی دادیم، چون نظر من این بود که معاونت منابع انسانی حتماً باید صحت این اطلاعات را تأیید کند. بعد از مدتی، معاونت منابع انسانی یک سی‌دی به ما داد و گفت اطلاعات روی این سی‌دی را روی سایت بگذارید. طبق تجربه می‌دانستیم که با توجه به جمع‌آوری دستی دادهها ممکن است اشکالاتی در دادهها وجود داشته باشد. حتی به معاونت پیشنهاد کردیم که ما اول اطلاعات را روی یک صفحهٔ تستی بالا می‌آوریم، شما ببینید و اگر مورد تأیید بود، روی سایت اصلی منتشر می‌کنیم. اما نهایتاً بعد از انتشار هم اشکالاتی وجود داشت که مجدداً اصلاح گردید.
چنین مسائلی وجود داشت، اما بههرحال رویکرد ما این بود که کمک کنیم تا کار انجام شود. واقعیت این است که در آغازِ کار هم صرفاً یک‌سری اطلاعات استاتیک (از طریق یک‌سری فرم‌ساز) در سایت می‌گذاشتیم که از نظر فنی پیچیدگی خاصی نداشت. ولی خب این موضوع چالشی همیشه وجود داشت که چه کسی بگوید چه اطلاعاتی منتشر شود یا نشود. نظر کمیتهٔ شفافیت بر انتشار حداکثری اطلاعات بود؛ مثلاً در موضوع انتشار اطلاعات مدیران، کمیته میگفت جزئیات دریافتی را منتشر کنید. اما از سمت شهرداری می‌گفتند فقط حقوق مندرج در حکم را بگذارید. درخصوص سفرهای خارجی هم همین اتفاق افتاد و بعداً برخی معترض شدند. مثلاً یکی از مدیران قبلی شهرداری به من زنگ زد که این دادهها اشتباه است؛ من این تعداد سفر نرفته‌ام. گفتم انتشار این اطلاعات مصوبه دارد و ما در سازمان فاوا فقط اطلاعاتی که به دستمان رسیده است را روی سایت منتشر کرده‌ایم. گفتم اگر اشتباهی در این اطلاعات هست باید با واحد متولی داده صحبت شود -البته هرچه جلوتر می‌رفتیم، بارگذاری بخش بزرگ‌تری از اطلاعات سیستمی می‌شد و با فراخوانی داده از سامانه‌ها انجام می‌گرفت و خطاها و اشتباهاتی که در بارگذاری دستی پیش می‌آمد کمتر می‌شد.
مصاحبه‌کننده: این اشتباهات و خطاهایی که در دادهها وجود داشت چطور به وجود آمده بود؟
محمد فرجود: در بسیاری از موارد، داده‌ای که درنهایت برای انتشار در اختیار ما قرار می‌گرفت دستی تهیه شده بود چون خیلی از سامانه‌ها هنوز integrate (یکپارچه) نبودند و داده‌های موردنیاز باید از منابع مختلف جمع‌آوری می‌شد و بهصورت دستی در لیست‌ها قرار می‌گرفت. ما به‌تدریج سعی کردیم سامانههای اصلی را یکپارچه کنیم. برای مثال حوزهٔ قراردادها حوزه‌ای بود که این کار تا حد خوبی در آن پیش رفت.
در بیشتر مواقع content (محتوا) موردنیاز در سامانهٔ ما بهصورت تجمیع‌شده موجود بود، اما ممکن بود خطا و اشتباه داشته باشد که دلیل آن هم عدم وجود فرایندی برای صحت‌سنجی و تأیید دادهها پیش از ثبت در سامانه بود و این موضوع احتمال اینکه در جمع‌آوری و ثبت داده اشتباه شود را خیلی بالا می‌برد.
خلاصه آنکه سازمان فاوا همیشه درخصوص انتشار داده چالش داشت. مثلاً شورا میگفت اطلاعاتی را روی سایت شفاف بگذارید، درحالیکه شهرداری هنوز تأیید انتشار دادهها را نداده بود. به یادم دارم که چند بار خانم آروین به ما گفت فلان اطلاعات را روی سایت بگذارید و من گفتم تا از سمت شهرداری انتشار اطلاعات را approve (تأیید) نکند، دادهها را روی سایت قرار نمی‌گیرد چون بعداً می‌تواند مشکل‌ساز شود. به ایشان می‌گفتم بپذیرید که سازمان فاوا صرفاً ابزار کار است و اصلاً مسئول تأیید صحت محتوا نیست؛ هر محتوایی که از سمت شهرداری می‌آید یک متولی دارد که باید انتشار محتوا را تأیید کند. درخصوص اطلاعات سفرهای خارجی، اطلاعات را از سامانههای سازمان فاوا استخراج می‌کردیم و در اختیار روابط عمومی[۳] قرار می‌دادیم تا تأیید کند. فرایند تأیید اطلاعات زمان‌بر بود، زیرا باید اطلاعات استخراج‌شده با اسناد و مدارک موجود چک و بررسی می‌شد.
مصاحبه‌کننده: شورا نهاد بالادست محسوب می‌شود. وقتی او به شما می‌گوید اطلاعات را روی سایت بگذارید نباید تحت هر شرایطی این کار را انجام دهید؟
محمد فرجود: در رابطه با هر داده‌ای، بحث‌هایی مثل سطح امنیتی و محرمانگی، صحت‌سنجی، حفظ حریم شخصی و نظایر آن مطرح است و انتشار هر داده‌ای ملاحظات خاص خودش را دارد و مسئولیت آن با متولی داده است. ما در سازمان فاوا از این ملاحظات مطلع نبودیم و من این را در شهرداری نهادینه کرده بودم که متولی داده سازمان فاوا نیست. بنابراین این‌طور نبود که چون شورا به سازمان فاوا گفته است که فلان اطلاعات منتشر شود، سازمان فاوا هم بدون تأیید متولی داده این کار را انجام دهد.
مصاحبه‌کننده: تدوین سند حکمروایی داده، که تکلیف برنامۀ سوم توسعه هم بود، نمی‌توانست به نظم و سروسامان دادن به این وضعیت کمک کند؟
محمد فرجود: بله، می‌توانست. ما سند حکمروانی داده را، تا جایی که وظیفۀ ما بود، آماده کرده و ارائه دادیم. در سند گفته شده بود که انواع داده‌های موجود در شهرداری و قواعد استفادهٔ هر کدام چطور باید مشخص شود. قدم بعدی این بود که الزامات سند روی تک‌تک دیتاسِت‌های موجود اعمال شود، و در کمیته‌ای با حضور واحدهای متولی هر دیتاست مشخص شود که برای مثال، کدام‌یک از دادهها محرمانه است و کدام نیست. اگر اشتباه نکنم، این موضوع در سند دیده شده بود که دو کمیتۀ تصمیم‌گیری وجود داشته باشد، یکی high level (سطح بالا) که وظیفهٔ راهبری را بر عهده داشته باشد و جلساتش متناسب با نیاز و موضوعات قابل طرح تشکیل شود، و یکی در سطح کارشناسی و اجرایی که با استمرار بیشتری تشکیل جلسه دهد و در این جلسات راجع به مصادیق محرمانگی و مسائل مرتبط با انتشار دادهها صحبت کنند و اگر شخص یا سازمانی از شهرداری داده‌ای می‌خواهد که تکلیفش معلوم نیست، آنجا تعیین تکلیف شود که دادهٔ درخواست‌شده در کدام کتگوری قرار می‌گیرد، محرمانه است یا نیست و می‌توانیم به آن دسترسی بدهیم یا خیر. در این سند، سازوکار این کمیته‌ها با جزئیات دیده شده بود و وظیفۀ هر کمیته و فکر کنم اعضایشان هم مشخص شده بود.
خلاصه اینکه ما سند را تهیه کردیم. ولی تا جایی که می‌دانم، سند روی تمام داده‌های شهرداری اعمال نشد، هرچند در زمان ما قرار بود این اتفاق بیفتد. البته یک‌سری دادهها که حساسیت و اهمیت بالایی داشتند تعیین تکلیف شد و در حوزههایی هم که توانستیم فرایند ثبت و انتشار داده را سامانه‌ای و اتوماتیک کنیم عملاً نیاز به تأیید متولی داده منتفی شد. مثلاً در حوزهٔ قراردادها، سازمان فاوا توانست فرایند ثبت و انتشار اطلاعات را تا حد زیادی سامانه‌ای و اتوماتیک کند. البته رسیدن به نقطه‌ای که سامانهٔ قراردادها در تک‌تک واحدهای زیرمجموعهٔ شهرداری راهاندازی شود یکسالونیم زمان برد. در طول این مدت کمیتهٔ شفافیت به‌طور مرتب با واحدهای مختلف جلسه می‌گذاشت و خانم آروین و ما نظارت داشتیم تا سامانهٔ قراردادها در مثلاً بیست واحد از سی واحدی که از این سامانه استفاده نمی‌کردند ایجاد و راهاندازی شود. درخصوص آن واحدهای باقی‌مانده هم باز خانم آروین جلسه می‌گذاشت و ما هم در جلسات شرکت می‌کردیم. کار خیلی سختی بود. منتها از منظر شفافیت و انتشار اطلاعات، با راهاندازی این سامانه، اطلاعات قراردادها پس از ثبت در سامانه بهصورت اتوماتیک روی سایت شفاف قرار می‌گرفت.
درمقابل، وقتی فرایند ثبت یا انتشار اطلاعات سامانه‌ای نباشد، واحد فناوری نمی‌تواند مسئولیت حساسیت داده و محرمانگی داده را به عهده بگیرد. اتفاقاً انتشار بسیاری از دادهها روی سایت شفاف به این شکل دوم انجام می‌شد و این موضوع فشار زیادی را به سازمان فاوا تحمیل می‌کرد.
مصاحبه‌کننده: لطفاً کمی بیشتر توضیح دهید که چرا می‌گویید راهاندازی سامانهٔ قراردادها در واحدهای مختلف کار خیلی سختی بود.
محمد فرجود: اولاً سطح بلوغ سازمانها و شرکت‌های شهرداری از نظر طراحی فرایند و فراهم‌‌بودن زیرساخت آی‌تی یکسان نبود. یا مثلاً خیلی پیش می‌آمد که سازمان فاوا سامانه‌ای را آماده و در چند بخش هم راهاندازی کرده باشد، اما بخش‌های دیگر به دلایل مختلف از آن استفاده نکنند. راهاندازی یک سامانهٔ جدید در همهٔ بخش‌های شهرداری اصلاً کار آسانی نبود. ممکن بود که یکی از زیربخش‌های شهرداری درخصوص استفاده از سامانه‌ها همکاری لازم را نداشته باشد مگر آنکه شهرداری آن را موظف کرده باشد -مثلاً دریافت حقوق را منوط به اتصال واحد اجرایی به سامانهٔ منابع انسانی کرده باشد- که در این حالت برای راهاندازی سامانه در بخش خودشان همکاری می‌کردند.
اجرای دستور ثبت سامانه‌ای و انتشار اتوماتیک اطلاعات قراردادها هم با همین مسائل مواجه بود. ما باید کل فرایند مربوط به درخواست و انعقاد قرارداد را الکترونیکی می‌کردیم. برای این کار، سراغ سامانهٔ قراردادهای شهرداری رفتیم که قبلاً ایجاد شده بود اما هنوز در همهٔ بخش‌ها راهاندازی نشده بود. به یاد دارم که آن اوایل، از حدود چهل سازمان و شرکت زیرمجموعهٔ شهرداری، فقط سازمان ما و دو-سه سازمان دیگر از این سامانه استفاده می‌کردند. در راند اول گفتیم کل اطلاعات قرارداد را خودتان بهصورت دستی در سامانهٔ قراردادها وارد کنید. این وسط ممکن بود بعضی فیلدها خالی بماند یا مقادیر اشتباه وارد شود. هرچه مراحل بیشتری از فرایند الکترونیکی شد، میزان بروز این خطاها هم کمتر شد.
به‌طور موازی، شروع کردیم به راهاندازی سامانهٔ قراردادها در دیگر سازمانها و شرکت‌های زیرمجموعه. این کار از دو-سه سازمان شروع شد و بعد سایر شرکت‌ها و سازمانها به این طرح اضافه شدند. جلسات زیادی در این خصوص برگزار شد. الکترونیکی‌کردن کل فرایندهای مربوط به قراردادها کار خیلی سختی بود. در سازمان فاوا، همهٔ مراحل، از تصمیم کارشناس یا مدیر به عقد قرارداد و اعلام نیاز و ارائهٔ آراف‌پی تا بسته شدن قرارداد و همهٔ مراحل پس از آن، از طریق سامانه انجام می‌شد. اما خیلی از بخش‌ها نمی‌توانستند از سیستم طراحی‌شده در سازمان فاوا استفاده کنند و اطلاعات خود را در آن وارد کنند. پیاده‌سازی نیازمندی‌های آنها در سامانه هم کار پیچیده‌ای بود. به همین دلیل ما یک ورژن لایت از سامانهٔ قراردادها به نام سامانهٔ قراردادهای چابک تهیه کردیم که چند بخش اصلی از سامانهٔ قراردادها در آن پیاده‌سازی شده بود. هدف از ایجاد نسخه سبک‌تر این بود که می‌خواستیم سامانه در آن بخش راهاندازی شود و به‌مرور کامل شود. با این مدل چابک توانستیم سامانهٔ قراردادها را در اکثر بخش‌های شهرداری راهاندازی کنیم. اواخر دوره واحدهایی که کمتر تحت مدیریت شهرداری و شورا بودند، مثل سازمان فرهنگی و هنری شهرداری، باقی ماندند که سامانهٔ مذکور در آنها راهاندازی نشد.
علاوه بر چالش‌های فنی، مقاومت‌هایی نیز درخصوص مشخص‌شدن بعضی از پارامترهای قراردادها مانند رقم و طرف قرارداد نیز وجود داشت. اصلاً راهاندازی سامانهٔ قراردادها باعث شد تا شهرداری و به‌ویژه شهرداری‌های مناطق در انعقاد قراردادها دقت بیشتری داشته باشند. پیش از راهاندازی سامانهٔ قراردادها، با توجه با اینکه اطلاعات قراردادها شفاف نبود، امکان سوءاستفاده وجود داشت ولی پس از آن جلوی خیلی از سوء استفاده‌ها گرفته شد.
اما خب، طراحی و راهاندازی سامانهٔ قراردادها در کلیهٔ بخش‌های زیرمجموعه واقعاً کار خیلی سختی بود و انرژی خیلی زیادی برد.
مصاحبه‌کننده: سازمان فاوا رأساً اقدام به توسعهٔ سامانه‌ها -سامانهٔ قراردادها یا هر سامانهٔ دیگری- می‌کرد؟
محمد فرجود: نه، ما سفارش را از واحد بهره‌بردار سامانه می‌گرفتیم. مثلاً درمورد سامانهٔ مالی، معاونت مالی گفته بود تمام واحدهای شهرداری اعم از ستاد شهرداری، شهرداری‌های مناطق و حتی سازمانها و شرکت‌ها باید از این سامانه استفاده کنند. در خود ستاد شهرداری و شهرداری‌های مناطق، سامانههای مورد استفاده در هر حوزه یکپارچه بودند، یعنی یک سامانهٔ مالی، یک سامانهٔ منابع انسانی و یک سامانهٔ قراردادها وجود داشت. اما درمورد سازمانها و شرکت‌ها موضوع کمی فرق می‌کرد و مواردی وجود داشت که، بنا به برخی دلایل، از سامانهٔ مالی مخصوص خودشان استفاده می‌کردند. در دورهٔ ما -البته قبل از آن هم همین‌طور بود- ستاد شهرداری اعلام کرد که سامانه‌ای به‌جز سامانهٔ مالی مرکزی را قبول نمی‌کند و سامانهٔ مالی در کلِ شهرداری باید یکپارچه شود، تا همهٔ اطلاعات یک جا جمع شود و بتوان گزارش‌های لازم را از روی آن تهیه کرد. تا جایی که به یادم دارم، تا پایان دوره، اطلاعات حوزهٔ مالی با ضریب خوبی به سامانهٔ مالی مرکزی منتقل شد.
این نکته را در نظر داشته باشید که وقتی من به شهرداری وارد شدم، هم درمورد سامانهٔ قراردادها، هم درمورد سامانهٔ مالی و هم درمورد سامانهٔ منابع انسانی و هم برخی سامانههای دیگر ما در نقطهٔ صفر نبودیم و کار پیاده‌سازی و راهاندازی سامانه‌ها در بخش‌های مختلف تا یک جایی جلو رفته بود. مثلاً درمورد سامانهٔ منابع انسانی، گفته شده بود که شهردار وقت اطلاعاتی درخصوص تعداد نیروی انسانی فعال در شهرداری خواسته بود که نتوانسته بودند اطلاعات دقیقی در این خصوص ارائه بدهند. درواقع آمار دقیقی از نیروهای انسانی شهرداری وجود نداشت و از طرفی تعاریف متفاوتی هم از نیروی انسانی در هر بخش وجود داشت که باید یکسان‌سازی صورت می‌گرفت.
بعد که ما آمدیم و این موضوع را برای من گفتند، دیدم که سامانهٔ منابع انسانی تا به حال چهار بار پیاده‌سازی شده است اما هر بار، تیم جدیدی که بر سر کار آمده گفته سامانهٔ موجود خوب نیست و باید عوض شود. زمانی که من به شهرداری آمدم دوباره با سفارش تیم جدید داشتند نسخهٔ آخر را می‌نوشتند. معاونت منابع انسانی متولی پروژه شد و تقریباً یک‌سال طول کشید تا ما توانستیم سامانهٔ منابع انسانی را در تمام مجموعهٔ شهرداری راهاندازی کنیم. کار خیلی سختی بود. در دورهٔ قبل یکی از مهمترین توفیقات ما همین بود که ضریب نفوذ سامانههای مرکزی را از خیلی کم به نزدیک به کامل رساندیم.
پیاده‌سازی سامانهٔ منابع انسانی پیچیده بود چون مثلاً جایی مثل سازمان پارکها[۴] با دوهزار نفر نیرو کلاً سامانهٔ منابع انسانی نداشت و اطلاعات نیروهایش را در فایل اکسل نگه می‌داشت. دیگر خود شما حساب کنید که طراحی و پیاده‌سازی فرایندها و ورود اطلاعات کارکنان در آن بخش چقدر سخت بود. کاری که ما کردیم این بود که یک تیم بیست-سی‌نفره از نیروهای مؤسسهٔ رایانه شهر[۵] (افرادی که در سازمان ما کار می‌کردند اما قراردادشان با شرکت رایانه شهر بود) در اختیار تیم سامانهٔ منابع انسانی سازمان فاوا قرار دادیم. آنها با هدایت تیم معاونت منابع انسانی شهرداری در بخش‌های مختلف شهرداری مستقر می‌شدند، اطلاعات کارکنان را از سیستم قبلی -هر سیستم یا روشی که برای نگهداشت اطلاعات پرسنلی استفاده می‌شد- به سیستم جدید منتقل می‌کردند، خروجی‌ها را تست و آزمایش می‌کردند تا می‌رسیدند به نقطه‌ای که می‌شد گفت دادهها از سیستم قبلی به سیستم جدید convert (تبدیل و منتقل) شده است. بعد از آن، اول زیرسامانهٔ حقوق و دستمزد و بعد هم زیرسامانهٔ حقوق‌پردازی را در سامانهٔ منابع انسانی پیاده‌سازی می‌کردند. شما حساب کنید که ما این فرایند را باید حداقل در سی سازمان طی می‌کردیم. قشنگ یادم است که پروسهٔ راهاندازی سامانهٔ منابع انسانی در واحدهای مختلف شهرداری یک‌سال‌واندی طول کشید. راهاندازی سامانه در برخی بخش‌ها مثل شرکت اتوبوسرانی[۶] و سازمان پارکها سخت‌تر از بقیه بود چون این بخش‌ها نیروی انسانی زیادی داشتند و خیلی سخت بود که شما همهٔ داده‌های مرتبط -اطلاعات شناسایی، حکم، حقوق، تردد و غیره- را در سامانهٔ منابع انسانی وارد کنید.
در حوزهٔ مالی و حوزهٔ قراردادها هم مسیر مشابهی طی شد، یعنی ما شروع کردیم به ارتقای سامانه‌هایی که از قبل در شهرداری وجود داشتند و، به‌طور موازی، پیگیری‌های لازم درخصوص راهاندازی این سامانه‌ها را در تعداد هرچه بیشتری از بخش‌های شهرداری انجام می‌دادیم.
نکته‌ای که می‌خواهم روی آن تأکید کنم این است که اگر سامانههای پایه از قبل در شهرداری وجود نداشتند، نمی‌توانستیم به این راحتی‌ها به نقطه‌ای برسیم که، در حوزه‌های مختلف، دیتای معتبر و به‌روز منتشر کنیم. ببینید، ما در سامانهٔ شفافیت دو نوع داده داشتیم، داده‌های ثبتی و داده‌های غیرثبتی. داده‌های غیرثبتی بر مبنای پرسشنامه و جدول جمع‌آوری می‌شد؛ فرمی را برای بخش مربوطه می‌فرستادیم و می‌گفتیم اطلاعات را در این فرم وارد کنید و بعد آن را روی سایت بارگذاری می‌کردیم. طبیعی بود که در این شیوه، خطای ورود اطلاعات بالا باشد.
نوع دیگر داده داده‌های ثبتی بود که مستقیماً از سامانه‌ها روی سایت شفاف منتشر می‌شد و خطای کمتری داشت. یکی از مهمترین اتفاقاتی که تلاش کردیم در شهرداری رقم بزنیم این بود که ما سامانه‌ها را یکی‌یکی در بخش‌های مختلف مستقر کنیم و سهم داده‌های ثبتی را نسبت به داده‌های غیرثبتی بالا ببریم. بعد از این کار تازه آشکار شد که شیوهٔ غیرثبتی چقدر نقص و خطا دارد. مثلاً درخصوص راهاندازی سامانهٔ منابع انسانی تازه مشخص شد که چقدر نقص دیتا در بخش‌هایی مثل مدرک تحصیلی، حکم و سابقهٔ کاری کارمندان وجود دارد. خوشبختانه با اقداماتی که انجام شد، بعد از یک سال، ما تا حد خوبی دیتای دقیق داشتیم که همین الان در شهرداری چند نفر کار می‌کنند؛ چه تعداد از آنها آقا و چه تعداد خانم هستند؛ مدرک تحصیلی آنها چیست؛ در همین ماه چند نفر از شهرداری رفته‌اند؛ چند نفر بازنشسته شده‌اند و چند نفر جذب شهرداری شده‌اند و اطلاعاتی از این قبیل؛ و همهٔ این‌ها در حد خوبی داشبورد شد (البته تعداد اندکی از بخش‌ها باقی ماندند که سامانهٔ منابع انسانی در آنها راهاندازی نشد).
بعد از ایجاد سایت شفاف در شهرداری و اطلاع‌رسانی درخصوص نتایج و دستاوردهای آن، سازمانهای دیگری هم از این دستاورد استفاد کردند و سامانهٔ شفافیت را در سازمان خود راهاندازی کردند. اما واقعیت این است که اکثر آنها، چون زیرساخت سامانه‌ای برای ثبت اطلاعات نداشتند، اطلاعاتی که روی سامانهٔ شفافیتشان منتشر می‌کردند مبتنی بر گزارش‌گیری دستی و غیرالکترونیکی بود، درنتیجه ممکن بود در داده‌های منتشرشده خطا وجود داشته باشد و دادهها با فاصلهٔ زیادی به‌روز شود. در بهترین حالت می‌توانستند مثلاً هر سه ماه یک بار دادهها را بهصورت غیرثبتی و دستی از بخش‌های مختلف جمع‌آوری کنند و در سامانه بارگذاری کنند؛ در غیر این صورت داده‌هایشان همان‌‌جور قدیمی و به‌روزنشده می‌ماند. اما در شهرداری تهران، به‌جز انتشار اطلاعات سفرهای خارجی که تا آخر دوره هم بهصورت دستی و از طریق بارگذاری فایل اکسل انجام می‌شد، انتشار اکثر دادهها روی سایت شفاف بهصورت اتوماتیک انجام می‌گرفت. این اتوماتیکشدن، صحت دادهها را بالا برد و مکانیسم انتشار داده را تسریع کرد.
استقرار سامانههای پایه در شهرداری، به‌خصوص در دو سال اول، انرژی زیادی از ما برد. اما خب ما با تلاش بسیار و حمایت‌هایی که از سوی شهرداری و شورای شهر انجام شد، جلو می‌رفتیم و کار را انجام می‌دادیم. بخش خوبی از پیشرفت کار، به‌ویژه در حوزهٔ مالی و قراردادها، مدیون پیگیری‌های خود خانم آروین بود. در حوزهٔ منابع انسانی هم همین‌طور بود، اما آنجا خود شهرداری -معاونت منابع انسانی در ستاد شهرداری- هم به‌جد پیگیر بود.
همکاری بخش‌های مختلف با ما خیلی تابعِ این پیگیری‌ها بود. شرکت‌ها، سازمانها و بخش‌های شهرداری همیشه به این نگاه می‌کنند که چه کسی پیگیر موضوع است و چقدر قدرت دارد، چون بالاخره همیشه دلایل زیادی برای عدم همکاری وجود دارد و همه تا حدی در برابر تغییر مقاومت دارند. همیشه چیزهای غیرشفافی هم وجود دارد که واحدها دوست ندارند شفاف شود. خلاصه مقاومت‌ها کم نبود. مثلاً ممکن بود یکی از بخش‌ها اعلام کند که ما نیروی انسانی لازم برای پیاده‌سازی این سامانه و ورود اطلاعات در آن، و امکانات و سرمایهٔ لازم برای تأمین نیروی انسانی موردنیاز را نداریم. یکی از کارهای خوبی که معاونت منابع انسانی کرد این بود که به ما -سازمان فاوا- گفت هزینه‌های راهاندازی سامانه اعم از توسعه، نصب، تبدیل داده، آموزش را می‌دهند، سازمان فاوا فقط برود و سامانه را راهاندازی کند. به این ترتیب ما در راند اولِ راهاندازی سامانه، تقریباً هیچ هزینه‌ای از سازمانها و شرکت‌ها نگرفتیم و مانند این بود که با خود شهرداری قرارداد داشته باشیم. ضمن آنکه نیروی انسانی موردنیاز را خودمان تأمین می‌کردیم. موضوع یکپارچه‌سازی و ساماندهی دادهها آنقدر برای شهرداری مهم بود که حاضر بود به‌خاطر آن هزینه کند تا سامانه‌ها راهاندازی شود. بعدها که سامانه راهاندازی شد دیگر هزینهٔ پشتیبانی از خود سازمانها و شرکت‌ها دریافت می‌شد.
نمی‌دانم سامانهٔ قراردادها هنوز هم استفاده می‌شود یا نه، اما تا آن زمانی که ما در شهرداری بودیم فرایندهای مربوط به قراردادها هم تا حد خوبی سامانه‌ای و الکترونیکی شد.
مصاحبه‌کننده: گفتید بعد از یک سال که راهاندازی سامانهٔ منابع انسانی در بخش‌های مختلف شهرداری را پیگیری کردید، دیتای نسبتاً دقیقی از کارمندان شهرداری و اینکه چه کسانی هستند و کجا کار می‌کنند و از کِی مشغول شده‌اند در اختیار داشتید. اما همچنین گفتید تعداد کمی از بخش‌ها نیز از سامانهٔ منابع انسانی استفاده نکردند. لطفاً این موضوع را کمی باز کنید؛ چرا از این سامانه استفاده نکردند؟ یا چه شد که سامانه در آن بخش‌ها راه نیفتاد؟
محمد فرجود: اولاً، سامانۀ منابع انسانی ماژول‌های مختلفی داشت. ماژول اصلی یا core سامانه اطلاعات ثبت‌نامی افراد را نگه می‌داشت. به‌مرور ماژول‌های دیگری مثل ماژول حضوروغیاب، ماژول رفاهیات و ماژول حقوق‌پردازی، که یکی از ماژول‌های مهم بود، به آن اضافه شد و سامانه کامل‌تر شد. ممکن بود شما از سامانۀ منابع انسانی استفاده کنید ولی، به دلایل مختلف، هنوز حقوق‌پردازی شما در آن تعریف نشده باشد. درواقع راهاندازی کامل این سامانه در هر یک از واحدهای شهرداری چندمرحله‌ای بود: اول باید داده‌های قبلی، که ممکن بود در قالب یک فایل اکسل یا دیتابیس یک سامانۀ دیگر باشد، به سامانۀ منابع انسانی convert شود. بعد باید می‌دیدند کدام فیلدهای اطلاعاتی خالی است و چه داده‌هایی موجود نیست؛ در این زمان نقص اطلاعات مشخص می‌شد. همۀ این نقص‌ها و اشکالات طی مراحل مختلف راهاندازی سامانه یکی‌یکی مشخص و برطرف می‌شد. پس لزوماً همۀ ماژول‌های سامانهٔ منابع انسانی در همان فاز اول راهاندازی نمی‌شد و وقتی از راهاندازی سامانهٔ منابع انسانی در واحدهای مختلف حرف می‌زنیم، همین راهاندازی هم ممکن است در بعضی واحدها فقط در لایه‌های بیسیک سامانه اتفاق افتاده باشد و در بعضی واحدها در لایه‌های پیشرفته‌تر، به‌عنوان مثال راهاندازی کامل سامانه در واحدهای ستادی تقریباً همان اول انجام شد.
اما درمورد سؤال شما که چه واحدهایی روی سامانهٔ منابع انسانی نمی‌آمدند یا چرا نمی‌آمدند، ببینید، شهرداری تعداد زیادی سازمان و شرکت زیرمجموعه دارد و شرکت‌ها و سازمانها، با اینکه هرکدام ذیل یکی از معاونت‌های شهرداری هستند و مجموعه‌های کاملاً مستقل به حساب نمی‌آیند، ممکن بود آمادگی استفاده از سامانهٔ جدید را نداشته باشند یا اصولاً ثبت اطلاعاتشان در سامانه مقدور نباشد. مثلاً سازمان فرهنگی و هنری شهرداری چندان زیرمجموعۀ شهرداری به حساب نمی‌آید؛ خودش هیئت‌امنا دارد و هیئت‌امنا تصمیم می‌گیرد و ممکن است بگوید من -به هر دلیلی- نمی‌خواهم از این سامانه استفاده کنم.
در شرایط ایده‌آل می‌توانستیم با واحدهایی که مایل به استفاده از سامانهٔ منابع انسانی نبودند این‌طور توافق کنیم که آنها سامانۀ خودشان را داشته باشند اما با وب‌سرویس به سامانهٔ منابع انسانی مرکزی دیتا بدهند و از آن دیتا بگیرند. این سیاستی بود که من در بخش خصوصی تجربه‌اش را داشتم. آنجا هر کدام از شرکت‌های زیرمجموعهٔ شرکتِ مادر، سامانه، دیتابیس و داشبوردهای خودش را داشت و یکپارچگی از طریق تبادل داده بین این سامانههای مختلف حاصل می‌شد. ولی ما در شهرداری به این نتیجه رسیدیم که درمورد سامانههای پایه نمیشود انعطاف و دمکراسی زیادی به خرج داد و باید سامانههای مستقل را یکی‌یکی با سامانههای پایه replace (جایگزین) کنیم تا integrity (یکپارچگی) اتفاق بیفتد.
در این میان ممکن بود برخی بخش‌ها آمادگی استفاده از سامانهٔ مرکزی را نداشته باشند یا از نظر اندازهٔ سازمانی کوچک باشند، شهرداری هم سیاستش این بود که از معاونت‌ها، شرکت‌ها و سازمانهای اصلی و بزرگ شروع کند، یا مثلاً به هر دلیلی بگویند که سامانۀ ما فرایندهایشان را پشتیبانی نمی‌کند. بالاخره چنین چالشهایی برای پیاده‌سازی سامانه وجود داشت. البته چنین واحدهایی کم بودند. نمی‌دانم درنهایت چند واحد باقی ماندند که سامانهٔ منابع انسانی در آنها راهاندازی نشد، ولی کار در بیشتر واحدها انجام شد و بیش از ۹۰ درصد دیتاهای منابع انسانی بهصورت سیستمی از سامانهٔ منابع انسانی فراخوانی می‌شد و روی سایت شفاف قرار می‌گرفت. تازه درمورد آن واحدهایی هم که من می‌گویم سامانه در آنها راهاندازی نشد منظورم این نیست که دادهها دریافت نشد؛ بالاخره همۀ دادهها به روش‌های مختلف دریافت می‌شد ولی لزوماً همهٔ دادهها بهصورت اتوماتیک روی سایت شفاف بارگذاری نمی‌شد.
مصاحبه‌کننده: در مواردی که دلیل استفاده‌نکردن از سامانهٔ منابع انسانی پشتیبانی‌‌نکردن آن از فرایندهای واحد مربوطه عنوان می‌شد، این امکان وجود نداشت که سامانه برای استفادهٔ آن واحد مناسب‌سازی شود؟ آیا فرایندی طی می‌شد که سامانۀ شما از نیاز آنها پشتیبانی کند؟
محمد فرجود: این کار شدنی بود و نمونه‌اش را هم داشتیم. مثلاً وقتی به سازمانهای بزرگ مثل سازمان بوستان‌ها یا سازمان اتوبوسرانی ورود می‌کردیم، تیم ما، متناسب با نیازمندی‌های این سازمانها، customization (مناسب‌سازی) روی سامانه انجام می‌داد. اما ممکن بود واحد مربوطه بخش کوچکی باشد که راهاندازی سامانه در آن نه برای ما مهم باشد و نه برای معاون ارشد آن واحد، و معاونت بگوید همین که گزارشی از دیتای کارکنان این بخش به ما بدهید که ما اطلاعات کلی از تعداد نفرات آنها داشته باشیم کافی است.
خلاصه این‌طور نبود که کل شهرداری از یک سامانه استفاده کنند و فکر می‌کنم درنهایت تعدادی از بخش‌ها باقی ماندند که از سامانۀ دیگری استفاده می‌کردند. بااینحال، تا جایی که می‌دانم، داده‌های سامانهٔ منابع انسانی تا حد بسیار زیادی دقیق شد.
مصاحبه‌کننده: گفتید ما در شهرداری به این نتیجه رسیدیم که بهتر است درمورد سامانههای پایه همهٔ واحدها از یک سامانهٔ مرکزی استفاده کنند، به‌جای آنکه بین سامانههای متعدد با سامانهٔ مرکزی تبادل اطلاعات داشته باشیم. کمی در این خصوص توضیح می‌دهید؟
محمد فرجود: تصمیم سختی بود. البته در نظر داشته باشید که وقتی می‌گویم تصمیم گرفتیم همه از «یک» سامانه استفاده کنند، منظورم این نیست که تصمیم گرفتیم همه از یک نرم‌افزار واحد و یک‌شکل استفاده کنند، چون همانطور که گفتم، برای هر واحد، سامانه را بهصورت مجزا customize می‌کردیم (مناسب‌سازی می‌کردیم). ولی بالاخره core همهٔ این سامانههای customizeشده برای آن مجموعه یکی بود و وقتی جمع‌آوری داده انجام می‌شد و شما یک شبکۀ یکپارچه هم داشتید، همۀ دیتاها سریع می‌آمد و یک جا قرار می‌گرفت.
درمجموع این کار مزایای زیادی داشت. یکی از مزایای آن این بود که سطح بلوغ اکثر سازمانها و شرکت‌های زیرمجموعهٔ شهرداری در حدی نبود که بتوانند واحد آی‌تی مفصلی داشته باشند و اصلاً نرم‌افزارنویس و معمار نرم‌افزار نداشتند. این واحدها تا پیش از استفاده از سامانهٔ مرکزی، توسعه و نگهداری و پشتیبانی و این چیزها را همیشه به پیمانکار می‌سپردند و آن پیمانکارها هم معمولاً محصول شرکت خودشان را که لزوماً برای شهرداری customize نشده بود به این واحدها ارائه می‌دادند. ما آمدیم یک سامانهٔ آماده که متناسب با کار شهرداری و واحد مربوطه customize شده بود به آنها دادیم که فقط باید دیتایی را که از قبل داشتند در آن وارد می‌کردند. پس برای این واحدها، راهاندازی سامانۀ مرکزی به نفعشان شد. هزینۀ این customizationها را معمولاً خود سازمانها می‌دادند، ولی هزینۀ راهاندازی سیستم مرکزی را یک بار شهرداری داده بود.
یک جنبهٔ دیگر از ایجاد سامانهٔ مرکزی الزام و دستوری بود که از سوی شهرداری ایجاد شده بود. شهرداری می‌خواست خیالش دربارۀ حوزه‌های مهم مثل منابع انسانی و مالی راحت شود و مطمئن باشد که کسی داده‌ای را جابه‌جا یا دستکاری نمی‌کند. می‌خواست همه‌جا سامانۀ مرکزی خودش را راه بیندازد تا برای مثال بعداً بتواند مسیر همهٔ جریانات مالی را در سامانهٔ مالی ببیند. بالاخره وقتی واحدهای زیرمجموعه از سامانههای دیگری استفاده کنند که شما روی آن کنترل ندارید، ممکن است استانداردهایتان در پیاده‌سازی آن سامانه رعایت نشود یا به هر دلیلی دیتا به‌درستی وارد آن نشود یا به‌درستی نمایش داده نشود.
ما آن اوایل می‌گفتیم بالاخره شاید آن سامانههای مستقل هم امکانات و ویژگی‌های خوبی داشته باشند که سامانههای ما ندارند و بنابراین بهتر است واحدها را مجبور نکنیم که به سامانۀ مرکزی متصل شوند. ولی بعد به این نتیجه رسیدیم که اتفاقاً باید این تمرکز و یکپارچگی صورت بگیرد، به‌خاطر اینکه سازمانها یا شرکت‌ها و شهرداری به‌شدت به هم متصل بودند و آن‌قدرها مستقل نبودند؛ بودجه‌شان را از شهرداری می‌گرفتند، منابع انسانی‌شان اکثراً در خود شهرداری جابه‌جا می‌شدند و همه‌چیزشان شبیه هم بود و فقط اسماً سازمان یا شرکت مستقل بودند. سازمان فاوا هم همین‌طور بود؛ درست است که سازمان بودیم و براساس قانون تجارت فعالیت می‌کردیم، هیئت‌مدیرهٔ خودمان را داشتیم و …، ولی بالاخره همۀ بودجه‌مان را از شهرداری می‌گرفتیم و ۹۰ درصد تبادلات مالی و منابع انسانی‌مان با شهرداری بود و شهرداری هم میگفت باید قوانین شهرداری را تا حد زیادی در حوزه‌های مالی و منابع انسانی رعایت کنید. دست‌آخر به این نتیجه رسیدیم که بهتر است سامانه را یکی‌یکی در همهٔ واحدها پیاده‌سازی کنیم. راهاندازی سامانههای پایه در همهٔ واحدها موجب می‌شد آنها دربارۀ گزارش‌دهی و آماردهی و این قبیل موارد هم دیگر به شهرداری بدهکار نباشند.
خلاصه در اکثر موارد، خود واحدهای زیرمجموعه از راهاندازی سامانههای پایه استقبال می‌کردند. این کار معمولاً یک پیک کاری سخت برای سازمان فاوا و برای واحدی که قرار بود سامانه آنجا راهاندازی شود به همراه داشت. ما یک تیم حدوداً بیست الی سی نفره را ایجاد و تجهیز می‌کردیم و آنها به مدت یک ماه یا دو ماه در واحد مربوطه مستقر می‌شدند و کار data conversion (انتقال داده)، رفع عیب‌ها و launchکردن (راه‌اندازی‌کردن) سامانه را انجام می‌دادند.
مصاحبه‌کننده: با این توضیحاتی که دادید، آیا می‌توانیم این‌طور نتیجه بگیریم که اگر در بعضی از سازمانها و شرکت‌های مهم شهرداری، مثل سازمان املاک، برخی سامانههای پایه راهاندازی نشدند یا آن‌طور که باید راهاندازی نشدند، مسئله بر سر مقاومت ایشان در برابر شفاف‌شدن بوده است؟
محمد فرجود: در سازمان املاک هم سامانهٔ منابع انسانی و هم سامانهٔ مالی راهاندازی شد.
مصاحبه‌کننده: تا جایی که من می‌دانم، اگر هم این سامانه‌ها راهاندازی شدند، اما چندان مورد استفاده قرار نگرفتند.
محمد فرجود: درمورد سامانهٔ منابع انسانی، بعید می‌دانم این‌طور باشد که شما می‌گویید، اما سامانهٔ مالی را نمی‌دانم. به‌طور کلی در برابر استفاده از سامانههای مرکزی مقاومت وجود داشت و سازمان املاک هم که خودش نمونۀ خیلی خاصی بود و حتی سامانههای خودشان را که ایجاد می‌کردیم بعضاً بارها تغییرش می‌دادند، می‌گفتند این را نمی‌خواهیم و فرایندهای ما این‌جوری نیست که در سامانه پیاده شده، یا مدیریت عوض می‌شد و مدیر جدید نظرات جدید می‌داد و مواردی از این قبیل. خود من شاید چندین جلسه با سازمان املاک داشتم که بتوانیم خواسته‌هایشان در حوزهٔ فناوری اطلاعات را به سرانجام برسانیم. ولی درنهایت، بله، مشخص بود که انگیزه‌های دیگری هم پشت بعضی از این ماجراها هست و آن هم اینکه در نظر داشتند آنچه در سازمان املاک می‌گذرد خیلی شفاف نشود، چون مثلاً توسعهٔ سامانه تمام شده بود و همه‌چیزش آماده بود، اما باز هم بهانه می‌آوردند که از سامانه استفاده نکنند. وقتی بررسی می‌کردیم مشخص می‌شد که سال‌های پیش هم برای راهاندازی این سامانه کارهایی انجام شده است، اما باز هم سازمان املاک شروع به استفاده از سامانه نکرده است و سازمان فاوا مجدداً راهاندازی سامانه را در این سازمان شروع می‌کرد. ببینید، بالاخره اگر مدیر یک بخش تمایل به همکاری نداشته باشد و اگر سیستم داخلی یک بخش از سامانه‌ای‌شدن و شفافیت گریزان باشد، می‌توانند جلوی آن را بگیرند.
با تمام این تفاصیل، درمورد سامانههای پایه، چون یک فورس قوی از سوی شهرداری وجود داشت، در اکثر واحدها راهاندازی شد. مثلاً ما در سامانۀ قراردادها خیلی چالش داشتیم، اما به‌خاطر فشارهایی که خانم آروین آورد و جلسات متعددی که برگزار شد و اینکه بعد از مدتی امکان ثبت قرارداد در سامانههای دیگر هم بسته شد، بخش‌های مختلف قبول کردند که از سامانهٔ قراردادها، ولو از نسخهٔ چابک آن، استفاده کنند. اما تا این پروسه طی شود زمان زیادی صرف شد. این‌طور نبود که همه از همان اول همراه باشند. دو سال قبل از اینکه من به سازمان فاوا بروم، سازمان فاوا سامانۀ قراردادها را دولوپ کرده بود و تقریباً همۀ بخش‌هایش کار می‌کرد. اما نه در شهرداری و نه در سازمانها و شرکت‌ها، هیچ‌کس از آن استفاده نمی‌کرد، غیر از سازمان فاوا و دو-سه تا سازمان دیگر، که آنها هم به‌طور ناقص از آن استفاده می‌کردند.
ما که آمدیم، برنامه‌ریزی برای customize و دولوپ‌کردن سامانهٔ مذکور را انجام دادیم، ولی همچنان کسی از آن استفاده نمی‌کرد تا زمانی که بحث سایت شفاف و شفافیت قراردادها پیش آمد و استفاده از سامانهٔ قراردادها فورس شد. وقتی اطلاعات قراردادهای واحدهای مختلف روی این سامانه آمد، خود معاونت مالی تازه فهمید چه خبر است و اطلاعات قراردادها در خود شهرداری هم شفاف شد.
مصاحبه‌کننده: در مصاحبه‌هایی که تا اینجا داشته‌ایم، به نقل از بعضی از واحدها گفته شده که دلیل اینکه تمایل چندانی نداشتند به سامانههای پایۀ مرکزی بپیوندند و ترجیح می‌دادند از سامانههای خودشان استفاده کنند این بوده که کیفیت سامانههای سازمان فاوا خیلی خوب نبوده، یا پیاده‌سازیِ نیازمندی‌های خاص هر واحد در سامانه و فرایند ریپورت مشکلات و اصلاح‌شدن آنها به‌کندی انجام می‌گرفته و زمان‌بر بوده است. شما چقدر این استدلال را موجه می‌دانید؟
محمد فرجود: خب این حرف خیلی کلی است. بله، با اینهمه سامانه‌ای که شهرداری داشت و با آن تیمی که از قدیم در سازمان فاوا بودند -که هرچند توانمندی‌هایی داشتند ولی بالاخره مثل بخش خصوصی که نبودند- قطعاً نمیشود به‌طور قطع گفت که سامانه‌ها عیب و ایرادی نداشتند. ما وقتی به سازمان فاوا رفتیم این ایرادات خیلی زیاد بود. ولی از آن طرف این هم ممکن نبود که همۀ این سامانه‌ها را همزمان عوض و تحول شدید ایجاد کرد. به‌علاوه، کند‌بودن سامانه ممکن بود دلایل مختلفی داشته باشد: ممکن بود مشکل از کد برنامه باشد، ممکن بود مشکل از شبکه باشد، ممکن بود مشکل از نحوهٔ نگهداری دیتا باشد. دیتای بعضی سامانه‌ها خیلی سنگین بود و دلیلش این بود که دیتاها را بر اساس استاندارد مشخصی جمع‌آوری و ذخیره نمی‌کردند. یعنی خود سامانه مشکل نداشت. مثلاً درمورد سامانهٔ شهرسازی مشکل این بود که دیتابیس آن آنقدر پر و سنگین می‌شد که سامانه را کند می‌کرد و باید فکری به حال data compression (فشرده‌سازی داده) و بعد data warehouse (انبار داده) و ذخیره‌سازی داده می‌کردند. بعضاً هم مشکلات و لیمیتیشن سخت‌افزاری وجود داشت.
می‌خواهم بگویم وقتی واحدی راجع به کیفیت سامانه‌ای اظهارنظر می‌کند، صرفاً دارد بر مبنای تجربهٔ [۷]UX خودش نظر میدهد و نمی‌توان از روی آن راجع به کیفیت سامانه قضاوت قطعی کرد. بنابراین، با اینکه نفی نمی‌کنم که ایراداتی وجود داشت، ولی این مشکلات حداقل درمورد سامانههای زیرساختی و پایه مثل ای‌آر‌پی‌ها[۸] یا سامانههای منابع انسانی و مالی معضل چندانی درست نمی‌کرد. دلیلش هم این بود که این سامانه‌ها با توجه به شرایط شهرداری و متناسب با نیاز آنها ایجاد شده بودند. مثلاً سامانۀ مالی‌ای که وجود داشت از لحاظ فناوری خیلی به‌روز نبود و قدیمی بود؛ روی دسکتاپ بود و web-based (مبتنی بر وب) نبود. چندین راند هم ما خودمان فشار آوردیم و سعی کردیم آن را web-based و یک مقدار ماژول‌هایش را عوض کنیم. ولی آنقدر بزرگ بود که تغییرش هم برای ما و هم برای کاربران سامانه در شهرداری سخت شده بود. بااین‌وجود، این سامانه یک ویژگی داشت که آن را به سولوشن‌های بیرونی برتری می‌داد، و آن هم اینکه متناسب با فرایندهای شهرداری ایجاد شده بود؛ روی فرایندهای شهرداری هیچ سولوشن بیرونی‌ای به این اندازه دقیق و مَچ نبود و، به هر ترتیب، این سامانه کار را انجام می‌داد.
ببینید، اگر شما ده-دوازده سال وقت داشته باشید، خب دست‌به‌کار می‌شوید و یکی‌یکی مشکلات سامانه‌ها را بهصورت زیربنایی برطرف می‌کنید. ولی عمدهٔ کاری که از دست ما برمی‌آمد از این جنس بود که به سامانه‌ها ماژول add (اضافه) کنیم، انبار داده اضافه کنیم، و ترتیبی دهیم که همه از آن استفاده کنند. این‌ها برایمان اولویت داشت تا اینکه معماری سامانه را عوض و web-basedاش کنیم و کارهایی از این قبیل، البته تبدیل سامانهٔ مالی به حالت web-based در دستورکار سازمان فاوا بود و فکر می‌کنم نسخهٔ web-based آن اواخر دورهٔ مسئولیت ما تقریباً آماده شد.
ولی بههرحال این مشکلات، حداقل درمورد سامانههای پایه، مانع بزرگی در استفاده از این سامانه‌ها نبود. البته این را هم بگویم که ما همیشه خودمان منتقد بودیم و می‌گفتیم بسیاری از سامانه‌ها قدیمی است و به واحدهای متولی این سامانه‌ها پیشنهاد می‌دادیم که درخواست تعویض آن را بدهند. ولی تعداد سامانه‌ها آنقدر زیاد بود که باید اهم فی الاهم می‌کردیم. در این میان چالش‌های نیروی انسانی مور نیاز و نیز منابع مالی لازم برای انجام تغییرات نیز وجود داشت. معجزه هم که نمی‌شد کرد. مضاف بر اینکه همۀ این‌ها سامانههای عملیاتی بودند، یعنی نمی‌شد آنها را آف کرد و گفت یکی دیگر می‌نویسیم.
برای مثال سامانهٔ شهرسازی، که همیشه سر عوض‌کردنش بحث بود، در حدود بیست ماژول مختلف داشت که هر کدامشان خدمت خاصی را ارائه می‌کرد. یعنی تعداد زیادی زیرسامانه، تعداد زیادی فرایند و هزاران نقش و قاعده در این سامانه تعریف شده بود. اگر منابع مالی مناسب داشته باشید، می‌توانید پیمانکارهای بزرگ‌تری بگیرید تا تغییرات لازم را در چنین سامانه‌ای انجام دهند. اما در شهرداری، در آن شرایط کرونا و محدودیت‌های مالی و اینکه می‌گفتند همه کار را سازمان فاوا انجام دهد، نمی‌شد کار عجیبوغریبی کرد و طبیعتاً باید مدام بین کارهای توسعه‌ای و کارهای واجب تعادل برقرار می‌کردیم. مثلاً به شما میگویند من الان مثلاً ماژول کمیسیون ماده ۱۰۰[۹] یا ماژول کمیتهٔ نما[۱۰] می‌خواهم؛ خب شما می‌روید این‌ها را درست می‌کنید. اما اینکه تمام آن بیست ماژول را منتقل کنید به یک پلتفرم دیگر خودش یک مگاپروژه است که ممکن است از نظر زمانی و مالی بتوانید به آن برسید یا نرسید. به همین دلیل می‌گویم کندی سامانه و نظایر آن که ذکر شد واقعاً نمی‌تواند دلیل جدی‌ای برای استفاده‌نکردن از سامانههای پایه باشد.
البته ممکن بود، و کم هم نبود، که واحدهای مختلف در شهرداری از شرکت‌های بیرونی سامانه بگیرند. اما در این موارد هم بحث ما این بود که دیتابیس این سامانه کجا نگهداری می‌شود؟ امنیتش چطور تأمین می‌شود؟ یا integration دادهها در مجموعهٔ شهرداری چه می‌شود؟ پس اینکه بگویند مثلاً سامانهٔ منابع انسانی شهرداری خیلی کند و نامناسب بود و به همین دلیل ما از سامانههای دیگر استفاده می‌کردیم، نه؛ به نظر من دلیل قانع‌کننده‌ای نیست چون همه داشتند از این سامانه استفاده می‌کردند. حداقل درمورد سامانههای مالی و منابع انسانی این‌گونه بود.
مصاحبه‌کننده: راجع به سامانۀ منابع انسانی گفتید که خود معاونت منابع انسانی تأمین بودجهٔ مناسب‌سازی سامانه و راهاندازی آن در واحدهای مختلف را به عهده گرفت و این موضوع به پیشبرد کار خیلی کمک کرد. درمورد سامانههای مالی و قراردادها تأمین مالی چطور انجام شد؟
محمد فرجود: درمورد آنها هم به همین ترتیب بود که ما اکثراً هزینهٔ آن را از شهرداری دریافت می‌کردیم. یعنی طی تفاهمی که با شهرداری برقرار کردیم، شهردار موافقت کرد برای تسریع در راهاندازی سامانه‌ها، هزینه اولیهٔ آن را بپردازد ولی هزینهٔ نگهداری بر عهدهٔ شرکت‌ها و سازمانها بود. البته نحوۀ بودجه‌دهی هم این‌طور بود که مثلاً ما سال آخر اعلام کردیم که بودجهٔ مورد نیاز سازمان فاوا در حدود نهصد میلیارد تومان است. از این مبلغ نهصد میلیارد تومان، بعد از جلسات بسیاری که برای بررسی بودجه برگزار شد، درنهایت مبلغ پانصد میلیارد تومان آن تصویب شد. از آن پانصد میلیارد تومان هم فقط ۷۰درصدش را بهصورت نقدی تخصیص دادند. بعد دوباره گفتند فلان مقدارش غیرنقدی است. به همین منوال بودجهٔ ما کوچک و کوچک‌تر می‌شد. از آن طرف مثلاً قیمت تجهیزات دیتاسنتر با افزایش قیمت دلار بالا می‌رفت و چاره‌ای هم نبود و باید می‌خریدیم. هزینه‌های مربوط به شبکه و امنیت هم همین‌طور. درنهایت چیزی که برای بخش نرم‌افزار می‌ماند درصد کمی از بودجهٔ سازمان بود. آن مقدار هم عمدتاً مربوط به حقوق افراد و پرداختی‌های مربوط به تعدادی از پیمانکارها بود. به همین خاطر باید دائم بین این هزینه‌ها تعادل برقرار می‌کردیم. در مالی هم به همین ترتیب بود، چون هزینه ایجاد و راهاندازی سامانهٔ مالی را هم عملاً شهرداری پرداخت می‌کرد. اتفاقاً سامانهٔ مالی از بقیهٔ سامانه‌ها برای واحدهای شهرداری حیاتی‌تر بود، چون خیلی از واحدها داشتند از سامانۀ مالی استفاده می‌کردند و فرایند فعالیتشان در آن تعریف شده بود. اما در دورۀ ما ضریب نفوذ اکثر این‌ها، یعنی آن سامانه‌هایی که تصمیم گرفته بودیم در همهٔ واحدها یکی باشند، خیلی بالا رفت و اکثر واحدها روی این سامانه‌ها آمدند.
مصاحبه‌کننده: گفتید که در دورهٔ قبل، فرایند انتشار اطلاعات قراردادها تا حد زیادی خودکار شد؛ یعنی وقتی قراردادی در سامانه ثبت می‌شد، اطلاعات آن مستقیماً روی سایت شفاف می‌رفت و این باعث شد میزان خطا در اطلاعاتی که منتشر می‌شود کاهش یابد و اطلاعات به‌روز باشد. خب این یک وجه ماجراست که اطمینان از انتشار کامل و صحیح اطلاعات قراردادها را بالا می‌برد. اما حتی در همین حالت هم، چه تضمینی وجود داشت که مثلاً سازمان فاوا خودش داده‌ای را کم‌وزیاد نکند؟
محمد فرجود: چه دلیلی دارد که سازمان فاوا بخواهد داده‌های سامانه‌ای که خودش متولی دارد را کم و زیاد کند؟ اصلاً کم و زیادکردنِ دادهها به این راحتی‌ها نیست.
مصاحبه‌کننده: منظورم این نیست که لزوماً سازمان فاوا خودش رأساً اقدام به چنین کاری کند ….
محمد فرجود: ببینید، شما وقتی ادمین سامانههای کل شهرداری هستید، در لایه‌های مختلف، از دولوپر گرفته تا ادمینِ دیتابیس و …، بالاخره افراد دسترسی‌هایی دارند و در هر کجای این لایه‌ها ممکن است کسی تخلف کند. ولی طبیعتاً در سیستم‌های آی‌تی یک‌سری مکانیسم‌های کنترلی برای جلوگیری از وقوع چنین اتفاقاتی در نظر می‌گیرند. مثلاً لاگ اتفاقاتی که در سیستم می‌افتد، از جمله اینکه چه کسی چه زمانی وارد دیتابیس شده و چه چیزی را تغییر داده، ثبت می‌شود و درمورد دیتابیس‌های حساس، چند نفر بر آن نظارت دارند. ما هم طبیعتاً چنین مکانیسم‌هایی را فعال کرده بودیم. به شکل سازمانی و رسمی که اصلاً ممکن نبود تغییری در دادهها ایجاد شود، و اصلاً یکی از وظایف همیشگی سازمان فاوا این بوده که از داده‌های شهرداری حفاظت کند. در زمان ما هم به‌هیچ‌وجه نه قبول می‌کردیم و نه کسی اجازه داشت به دادهها دست بزند. بله، فرایندی وجود داشت که مثلاً معاونت شهرسازی میگفت فلان پروژه مصوب شده و آن را در سامانه وارد کنید. یعنی به‌شکل مکتوب نامه می‌زدند و درخواست می‌دادند و ما هم انجام می‌دادیم -البته باز هم این مثالی که زدم از جنس دخل‌وتصرف در اطلاعات قراردادها نبود.
خلاصه در این مکانیسم همهچیز معلوم است و مشخص است که چه کسی به چه کسی چه درخواستی داده و چه کسی در چه ساعتی تغییرات را در سیستم ایجاد کرده است. پس بر فرض که یک کارشناس می‌خواست خلاف فرایند عمل کند و برخلاف ضوابط داده‌ای را دستکاری کند، مشخص می‌شد و به‌طور معمول کنترل‌هایی روی سامانه‌ها قرار داده شده بود که این خلاف دستورالعمل‌ها عمل کردن را رصد کند. با همهٔ این‌ها نمی‌دانم که آیا احتمال دستکاری صفر بوده یا نه، چون بالاخره همیشه ممکن است خطا رخ دهد.
مصاحبه‌کننده: علاوه بر ثبت الکترونیکی اطلاعات قرارداد، انجام الکترونیکی مراحل پیش از عقد قرارداد مثل اعلام فراخوان و برگزاری مناقصه و مزایده هم الکترونیکی شد؟ تا جایی که می‌دانم، انجام الکترونیکی این مراحل در دورهٔ قبل آن‌قدرها عملیاتی نشد.
محمد فرجود: ما که در سازمان فاوا کل مراحل را بهصورت الکترونیکی انجام می‌دادیم، اما انجام الکترونیکی معاملات در شهرداری فراگیر نشد. با وجود تلاش و پیگیری‌های بسیار، اداره‌کل حقوقی شهرداری قبول نکرد که کاغذ از فرایند معاملات حذف شود و چون روال کاغذی بهصورت موازی با روال الکترونیکی بر جا ماند همیشه این ریسک وجود داشت که سیستم انجام الکترونیکی معامله مستقر نشود -اداره‌کل حقوقی تا به آخر بر این نظر بود که منظور از پاکت مهروموم شده در آیین‌نامۀ معاملاتی شهرداری پاکت فیزیکی است.
این‌طور جمع‌بندی می‌کنم که ما، به‌لحاظ فنی، انجام تمام‌الکترونیکی معاملات را پیاده‌سازی کرده بودیم؛ مثلاً یک تالار الکترونیکی آگهی‌های مناقصات و مزایدات راه انداخته بودیم که اگر کسی کامل از سامانهٔ قراردادها استفاده می‌کرد، اطلاعات فراخوان مناقصات و مزایداتش خودبه‌خود در این تالار منتشر می‌شد.[۱۱] اما خب بله، اینکه زیرساخت را پیاده‌سازی کنی یک چیز است، اینکه از این زیرساخت استفاده شود و اطلاعات در سامانه وارد شود چیز دیگری. استفاده از بستر انجام الکترونیکی معاملات در شهرداری فراگیر نشد.
مصاحبه‌کننده: بروز همه‌گیری کرونا به فراگیرشدن استفاده از بستر انجام الکترونیکی معاملات کمک نکرد؟
محمد فرجود: نه، این‌طور نشد. عاملی که راهاندازی سیستم انجام الکترونیکی معامله را جلو برد فشار و اصرار خیلی زیاد از طرف کمیتهٔ شفافیت بود. کار در شهرداری‌های مناطق تا حد خوبی جلو رفت، به نحوی که دیگر همه توکن[۱۲] و امضای دیجیتال داشتند و می‌توانستند مناقصاتشان را آنلاین برگزار کنند. حتی در یک بازۀ زمانی کمیتهٔ شفافیت نظارت می‌کرد که چه کسانی مناقصاتشان را الکترونیکی برگزار کردند و چه کسانی نکردند. پس می‌شود گفت که حداقل در سطح شهرداری‌های مناطق، انجام معاملات الکترونیکی شده بود، هرچند که همزمان بهصورت کاغذی هم انجام می‌شد.
وضعیت در رابطه با سازمانها و شرکت‌ها فرق می‌کرد. اگر صورت‌جلسات کمیتهٔ شفافیت را هم نگاه کنید می‌بینید که بارها و بارها مصوب می‌شد که فلان سازمان یا شرکت اقداماتی را درخصوص راهاندازی و استفاده از سیستم انجام الکترونیکی معاملات انجام دهد، اما کار آن‌طور که باید پیش نمی‌رفت. بعد از آن هم که مصادف شد با تغییر دوره و فکر کنم کار دیگر متوقف شد. بنابراین اینکه سیستم انجام الکترونیکی معاملات در شهرداری فراگیر نشد واقعاً به دلیل موانع و مشکلات فنی نبود؛ همه چیزِ سامانه کار می‌کرد و همانطور که گفتم، ما در سازمان فاوا همهٔ فرایند را کاملاً الکترونیکی انجام می‌دادیم.
ببینید، وقتی شما می‌خواهید کاری را در این اندازه انجام دهید و یک رویهٔ جدید را بخش به بخش در اینهمه معاونت و شهرداری منطقه و سازمان و شرکت پیاده کنید، از یک طرف نیاز به یک تیم مدیریت پروژه دارید که برود و با فرایندهای تک‌تک این واحدها آشنا شود، و از طرف دیگر هم خودتان و هم بخش‌های مختلف شهرداری با هزار چالش و مسئلهٔ روزمره روبه‌رو هستید که باید به آنها رسیدگی کنید. در این شرایط، وجود اهرم فشاری که مجموعه را به تکاپو بیاندازد تا کاری را در اولویت قرار دهد ضروری است. وگرنه اینکه فکر کنید یک سامانه ایجاد می‌کنید و به بخش‌های مختلف می‌گویید از این استفاده کنید و آنها هم می‌کنند، بعید است نتیجهٔ موفقیت‌آمیزی داشته باشد.
مصاحبه‌کننده: ابتدای دورهٔ پنجم، سازمان فاوا ذیل معاونت برنامه‌ریزی شهرداری قرار داشت و بعد برای مدتی ذیل دفتر شهردار رفت.
محمد فرجود: بله، تقریباً دو سال ذیل دفتر شهرداری بودیم.
مصاحبه‌کننده: آیا در آن دوران حرف‌شنوی بخش‌های مختلف از سازمان فاوا بیشتر شد؟ به‌عبارتی، آیا تغییر جایگاه سازمان فاوا در ساختار سازمانی موجب شد که سازمان فاوا توانایی بیشتری در اعمال فشار برای پیشبرد کارها به دست بیاورد؟
محمد فرجود: بله، قدرت ما در آن دو سال بیشتر بود و از نظر من، برگرداندن مجدد سازمان فاوا ذیل معاونت برنامه‌ریزی تصمیم اشتباهی بود که شورا گرفت. البته ما به دلیل دیدِ بازِ آقای مظاهریان[۱۳]، ذیل معاونت برنامه‌ریزی هم خیلی راحت بودیم و انتقال مجدد ما ذیل این معاونت چالش جدی‌ای برای ما ایجاد نکرد و کارهای ما در یک سال آخر دوره هم پیش رفت، اما همچنان معتقد بودم که وقتی سازمان فاوا مستقیماً ذیل دفتر شهردار باشد، قدرتی دارد که به‌واسطهٔ آن می‌تواند جدی‌تر عمل کند.
البته قدرت و مشروعیت بخش‌های مختلف در شهرداری تنها به جایگاهشان در ساختار سازمانی برنمی‌گردد، بلکه به عملکرد مدیریت سازمان هم بستگی دارد چون همیشه هم اعمال فشار جواب نمی‌دهد. اگر شما بخش‌های مختلف در شهرداری را با اعمال فشار مجاب به استفاده از سامانه‌ای کنید که درست کار نمی‌کند، درعمل از استقرار سامانه حمایت نمی‌کنند و با شما همراهی نخواهند کرد. رویکرد ما هم در سازمان فاوا این نبود که کار فقط با فشار پیش برود، بلکه همزمان تلاش می‌کردیم حرف بخش‌های مختلف را بشنویم و نیازهای آنها و مشکلاتی که با سامانه‌ها داشتند را متوجه شویم. به گفته بخش‌های مختلف شهرداری، ارتباط سازمان فاوا با سایر بخش‌ها در مدتی که ما در این سازمان مسئولیت داشتیم تغییر کرد و یک ارتباط تعاملی با آنها داشتیم. به‌عنوان مثال ما ساعت‌ها با افراد حوزهٔ خدمات شهری جلسه می‌گذاشتیم تا نیازهایشان را پیدا کنیم. زبان مشترک خوبی هم پیدا کرده بودیم. بنابراین، در خیلی از موضوعات، شیوهٔ ما این نبود بخواهیم سامانه‌ها را با فشاری که به‌واسطهٔ جایگاه سازمانی‌مان داشتیم در بخش‌های مختلف راهاندازی کنیم.
ولی بههرحال همانطور که ما در پرزنتیشن‌های مختلفمان هم زیاد تکرار می‌کردیم، در ساختار کلان اجرای پروژههای آی‌تی، هم‌راستاکردن بخش‌های مختلف و راهاندازی سامانه در آنها خیلی مهم‌تر از ابعاد فنی پروژه است. نه اینکه بگویم اگر سامانه از نظر فنی ضعیف باشد اشکالی ندارد، اما خب تعارف که نداریم، کوالیتی سامانه‌هایی که توسعه داده می‌شد متوسط و در بعضی موارد متوسط رو به بالا بود ولی لزوماً چیز خیلی عالی نبود؛ نه هزینۀ مناسب آن را داشتیم که تاپ‌ترین دولوپرهای نرم‌افزار ایران را به کار بگیریم و نه وقت آن را داشتیم که همهٔ دویست سامانهٔ شهرداری را کنار بگذاریم و از اول بنویسیمشان. درنتیجه ما در وهلهٔ اول باید به ایجاد سامانه‌ای که حد معقولی از کیفیت داشته باشد و کار کند، بسنده می‌کردیم تا بعد در طول زمان آن را improve کنیم (بهبود دهیم) و به آن امکانات جدید اضافه کنیم. به همین دلیل وقتی سامانه به حد مقبولی می‌رسید، برای راهاندازی آن اقدام می‌کردیم. ولی موضوع راهاندازی واقعاً مسئلهٔ پیچیده‌ای است. یعنی اینکه بنشینی آن بالا و فقط بگویی «بشود»، نمیشود. باید همیشه پیگیری کنی، هرازچندی به بالاسری‌ها گزارش دهی، جلوی بقیه بگویی این بخش‌ها همکاری کردهاند و آن بخش‌ها همکاری نکرده‌اند و از این‌جور کارها. هم ما و هم شورا دائم از این کارها می‌کردیم که پروژه پیش برود.
بنابراین اگر بخواهم جواب سؤال شما را بدهم باید بگویم بله، قرارگرفتن سازمان فاوا ذیل دفتر شهردار حتماً خیلی کمک می‌کرد. به نظر من آن مقطعی که سازمان فاوا ذیل دفتر شهردار بود قدرتمان بیشتر بود و هنوز هم توصیه می‌کنم که جایگاه این سازمان در حد یک معاونت باشد. در اکثر کشورهای دنیا هم می‌بینید که شهرداری‌ها chief information officer (مدیر ارشد فناوری اطلاعات) دارند که در حد یک معاون است. اگر نظر من را بخواهید، حتماً در ساختار شهرداری یک معاونت شهر هوشمند و تحول دیجیتال لازم است. قطعاً اگر اثرش از برخی از معاونت‌های فعلی بیشتر نباشد، کمتر نیست. ولی خب آن موقع چنین معاونتی وجود نداشت و ما هم مجبور بودیم در محدودهٔ سازمانی خودمان عمل کنیم و بعضی مواقع هم نمی‌توانستیم در بازی رده‌های بالاتر وارد شویم. اما آن برهه‌ای که زیر نظر شهردار بودیم به نظرم شرایطمان خیلی خوب بود. نه اینکه بگویم بعدش برایمان بد شد، چون ما تا آن موقع خیلی از موضوعات مدنظر خودمان را نهادینه کرده بودیم و نوع ارتباط و وابستگی دیگربخش‌ها به سازمان ما به نحوی بود که دیگر کسی نمی‌توانست به‌راحتی در برابر راهاندازی و استفاده از سامانه‌ها مقاومت کند. در این شرایط دیگر خیلی فرق نمی‌کرد که جایگاهمان در ساختار سازمانی کجا باشد. آقای مظاهریان هم انصافاً معاون بسیار همراهی بود که باعث شد ما به چالش خاصی برنخوریم، اما بالاخره فضای شهرداری طوری است که نگاه می‌کنند ببینند هرکسی چه جایگاهی دارد و بر این اساس روابطشان را با آن تنظیم می‌کنند.
مصاحبه‌کننده: مثال مشخصی در ذهنتان هست که کاری از قبل گره خورده باشد یا دست‌اندازش زیاد بوده باشد اما در دوره‌ای که ذیل دفتر شهردار بودید راحت‌تر پیش رفته باشد؟
محمد فرجود: باید چک کنم، اما اکثر مثال‌هایی که درخصوص راهاندازی سامانه‌ها زدم مربوط به همان دوره بود که ما ذیل دفتر شهردار بودیم. البته ترکیب هیئت‌مدیرهٔ سازمان فاوا هم خاص بود و افراد تأثیرگذاری در آن عضو بودند که به قدرتمندشدن سازمان فاوا کمک می‌کردند؛ خود آقای حناچی (شهردار تهران)؛ آقای کاظمی (مدیر حوزهٔ شهردار)؛ آقای مظاهریان (معاون برنامه‌ریزی، توسعۀ سرمایه انسانی و امور شورا )؛ و سید مهدی نادمی (مدیرعامل سازمان بازنشستگی شهرداری تهران) از اعضای هیئت‌مدیرهٔ سازمان فاوا بودند.
اگر بخواهم در این مورد مثال بزنم، باید به کلان پروژهٔ شهر هوشمند اشاره کنم. در حوزۀ اسمارت سیتی تعداد زیادی پروژه تعریف شده بود. یک روز پیش آقای حناچی رفتم و گفتم کار واقعاً سخت شده، ما دائماً پروژهها را از معاونت‌ها پیگیری می‌کنیم، معاونت‌ها هم پروژهها را به ادارات یا شرکت‌های زیرمجموعه‌شان داده‌اند اما کار خیلی پیش نمی‌رود. گفت چه کار کنیم؟ گفتم من فرصتی می‌خواهم که هم شما و هم معاون‌های شما حضور داشته باشید و آنجا گزارشی از وضعیت پروژهها ارائه دهیم و حداقل بگوییم هر کدام از این سی-چهل پروژه مربوط به کدام معاونت است و چقدر پیشرفت داشته است. یادم است آقای حناچی از یک جایی به بعد گفت شما در همهٔ جلسات شورای معاونان شهرداری شرکت کنید و ده دقیقه-یک‌ربع اول گزارش بدهید. خب، از آنجا به بعد روال کار خیلی خیلی عوض شد و پیگیری معاون‌ها از زیرمجموعه‌هایشان خیلی جدی‌تر شد. بعضی مواقع ما هنوز از جلسهٔ شورای معاونان به دفتر خودمان نرسیده بودیم که خبر می‌رسید با پیگیری معاون‌ها یک‌سری کارها انجام شده است. چندین بار این اتفاق افتاد و خیلی به ما کمک کرد.
ببینید، معاون‌های محترم هم چالش‌ها و مشکلات مختلفی داشتند و شاید اصلاً خبردار نمی‌شدند که یک‌سری کارها در زیرمجموعه‌شان مسکوت مانده است. با ارائهٔ آن گزارش‌ها در جلسه آنها هم متوجه وضعیت می‌شد. البته من موقع گزارش‌دادن رعایت انصاف را میکردم و مراقب بودم که به معاونی برنخورد. صرفاً توضیح می‌دادم که در حال پیگیری چه کارهایی هستیم و آخر سر هم یک گزارش ارائه می‌دادیم که وضع کدام پروژهها بحرانی شده و نیاز به توجه معاون دارد. همین گزارش، کار خودش را می‌کرد و خیلی اثر داشت. حتی بعضی مواقع برای پروژههای بحرانی، جلسهٔ جداگانه می‌گذاشتند. همهٔ این‌ها که گفتم در همان دوره‌ای اتفاق افتاد که سازمان فاوا ذیل دفتر شهردار قرار گرفت.
واقعیت این است که پروژه‌هایی مثل اسمارت سیتی، که بالاخره زیرساخت‌های شفافیت را هم تأمین می‌کند، پیش نمی‌رود مگر آنکه شخص اول مجموعه هم بخواهد. معاونان و مدیران شهرداری هم دیدگاه‌های متفاوتی نسبت به پروژههای شهر هوشمند داشتند؛ بعضی‌ها می‌گفتند این پروژههای آی‌تی برای ما چالش ایجاد می‌کند، یکی دیگر میگفت این‌ها کارهای خوبی است اما معاونت ما مشکلات دیگری دارد، دیگری میگفت من نمی‌دانم هدف شما از دریافت این اطلاعات چیست، آن یکی میگفت ما سال‌های طولانی با این روند و فرایند فعالیت کردیم و نمیشود که شما بخواهید روال ما را عوض کنید و همهٔ فرایندهای ما را تغییر بدهید، آن یکی میگفت سازمان فاوا اگر هنر دارد، به‌جای پروژهٔ جدید، آن ده سامانهٔ دیگر ما را که قدیمی هستند و ما را گرفتار کرده تغییر دهد.
همهٔ این موارد نظرات بخش‌های مختلف بود و واقعاً وقتی شما می‌خواهید چهل-پنجاه پروژه انجام دهید، این گونه نیست که همهٔ آنها عالی و به نحو احسن انجام شود. ولی با نظارت و پیگیری و بالابردن اولویت پروژههای شهر هوشمند، خیلی از آنها بالاخره جلو رفت. یعنی ما خیلی پیگیری می‌کردیم، می‌رفتیم و می‌آمدیم و دائماً گزارش می‌دادیم که این کار عقب است و آن کار عقب است، یک ستادی هم گذاشته بودیم به نام مرکز تهران هوشمند که نمی‌گذاشت کارها استاپ شود. باوجوداین، پروژه‌هایی هم بود که هیچ‌وقت جلو نرفت، مثل پروژهٔ راهاندازی الآرتی[۱۴] که سازمان حملونقل و ترافیک معرفی کرده بود. وقتی پیشرفت کار را پیگیری می‌کردیم، می‌گفتند هنوز سیاست‌گذاری در این زمینه انجام نشده و یا تأمین مالی صورت نگرفته است. در آخر ما الآرتی را حذف کردیم و به سازمان حملونقل اطلاع دادیم که فعلاً لازم نیست در این خصوص فعالیتی داشته باشند. یا مثلاً خودرو برقی، ایستگاه‌های باتری برقی و این چیزها را در برنامه‌ها گذاشتند که پیش نرفت. نکته این است که ما برنامهٔ تهران هوشمند را از خودمان که نمی‌توانستیم بنویسیم. روزی که برنامه را نوشتیم با تک‌تک معاونت‌ها صحبت کرده بودیم و سعی ما این بود که حرفهای خام و سطحی در برنامه نیاید. اما وقتی معاونتی می‌گوید الآرتی اولویت اول من است، خب ما هم در برنامه قرارش می‌دهیم.
مصاحبه‌کننده: بعضی‌ها میگویند در شرایطی که ما در الکترونیکی‌کردن فرایندهایمان مانده‌ایم، شهر هوشمند موضوع بی‌ربطی است.
محمد فرجود: این حرف ناشی از عدم تخصص است. اولاً که ما یک فرایند خطی نداریم که ابتدا الکترونیکی کنیم، بعد دیجیتال کنیم، بعد هوشمند کنیم. شما باید چشم‌انداز هوشمندشدن داشته باشید و به سمت آن حرکت کنید. اتفاقاً وقتی به سمت هوشمندشدن می‌روید، کارهایی هم که در حوزۀ الکترونیکی‌کردن می‌کنید معنادار می‌شود و در جهت درست‌تری قرار می‌گیرد. هیچ کجای دنیا این‌طور نیست که همهچیز از اول هوشمند و سیستمی باشد.
ببینید، کلاً حوزهٔ آی‌تی این‌طوری است که هیچ‌وقت هیچ‌کس از آن راضی نیست. به‌علاوه این را هم در نظر بگیرید که در شهرداری دویست سامانه وجود دارد که وقتی ما سازمان فاوا را تحویل گرفتیم تکنولوژیِ خیلی از آنها قدیمی بود. مگر چندتا از آنها را می‌توانستیم غیرفعال کنیم و دوباره از اول و با فناوری جدید ایجاد کنیم؟ درنتیجه مجبور بودیم قدم به قدم جلو برویم و سعی کنیم همین‌ها را improve کنیم. ولی آیا لازم بود همۀ این‌ها را improve کنیم و بعد به فکر رفتن به سمت هوشمندسازی باشیم؟ اصلاً این‌جوری نیست. کانسپت هوشمندسازی می‌گوید همین‌ها را هم اگر بخواهی درست کنی یا هر کاری دیگری با آنها بکنی، باید حواست به integration باشد، حواست به دیتاها باشد و تصویری از این داشته باشی که سامانه‌ها و دیتاها در وضع مطلوب قرار است چطور باشند، و با درنظرداشتن این تصویر بروی و آنها را درست کنی.
بگذارید مثال بزنم. ما چهار-پنج سامانۀ AVL tracking[15] یا مدیریت ناوگان خودرویی داشتیم. آتش‌نشانی این سامانه را داشت ولی تقریباً استفادۀ مناسبی از آن نمی‌کرد. شاید هم نداشت. یکی-دوتا سازمان دیگر هم چنین سامانه‌ای داشتند، مثلاً اتوبوسرانی داشت و بیشتر برای اینکه ببیند چه اتوبوسی کجاست از آن استفاده می‌کرد. سازمان تاکسیرانی این سامانه را نداشت. سازمان مدیریت پسماند به آن نیاز داشت. خلاصه چند سامانهٔ قدیمی داشتیم و چند سازمان که به سیستم مدیریت ناوگان خودرویی نیاز داشتند.
یک روز من گفتم ببینیم کدام‌یک از این سامانه‌ها کار می‌کند. متوجه شدیم که تقریباً هیچ‌کدام کارکرد مناسبی ندارد، به‌جز همان سامانۀ اتوبوسرانی. اول گفتیم برویم یکی‌یکی سامانه‌ها را درست کنیم اما بعد تصمیم گرفتیم یک پلتفرم واحد ایجاد کنیم که همهٔ فیچرها را داشته باشد و به همۀ این سازمانها سرویس بدهد، البته هر سازمانی هم فقط ماشین‌های خودش را ببیند. کار سختی بود؛ پیمانکار گرفتیم و یک سال هم طول کشید تا این کار را انجام دهیم؛ مثلاً درخصوص پسماند موردبه‌مورد پیمانکار جمع‌آوری زباله را راضی می‌کردیم جی‌پی‌اس‌های خراب ماشین‌هایشان را فعال کند تا ماشین‌ها در سامانه قابل مشاهده باشند.
بعد این سامانه را وصل کردیم به سیستم ارزیابی عملکرد ماشین‌ها. بعد اتوبوسرانی و بهشت زهرا هم توانستند ماشین‌هایشان را ببینند. درواقع کاری که ما کردیم این بود که در راهاندازی سیستم مدیریت ناوگان خودرویی، کانسپت اسمارت سیتی را در نظر گرفتیم و حواسمان بود که باید دیتاهایمان integrate باشد، باید سعی کنیم به‌شکل پلتفرمی به موضوع نگاه کنیم و نه بهصورت نرم‌افزارهای جداگانه.
آن دوستان چون اطلاع زیادی ندارند، فکر می‌کنند یک چیزی هست به نام سیستم الکترونیک و یک چیز دیگری هست به نام سیستم هوشمند. نه، هوشمندسازی یعنی اینکه شما به سمت اصولی بروید که بر اساس آنها شهر را هوشمندتر اداره کنید، و این یک journey (سِیر) است و آرام‌آرام تحقق می‌یابد. برخی از پروژهها جدیدند و یک‌سری کارهای قبلی هم مانده است. پیش‌بردن آن کارهای قبلی را هم باید با نگاه شهرهوشمندی انجام دهید. ما با همین نگاه شهرهوشمندی تصمیم گرفتیم که بسیاری از سامانه‌ها را kill (متوقف) یا در هم ادغام کنیم، و علاوه بر آن کلی چیزهای جدید هم اضافه کردیم. اگر این نگاه را نداشتیم، وقتی «تهران من» می‌خواست طراحی و راهاندازی شود، نه به سمت اپلیکیشن‌کردن آن می‌رفتیم و نه به سمت multi mega platform (پلتفرم چندوجهی) کردن آن، و درنهایت «تهران من» هم تبدیل می‌شد به سامانۀ دیگری کنار آن دویست سامانه.
اما ما «تهران من» را مبتنی بر کانسپت شهر هوشمند توسعه دادیم. بنا بر این کانسپت شما باید سعی کنید همۀ سرویس‌ها را روی یک درگاه واحد بیاورید و آنجا integrate کنید و به‌جای پاس‌دادن شهروند به درگاه‌های مختلف، فقط یک جا از او دیتا بگیرید. در حوزه‌های تخصصی -مثلاً حملونقل، سلامت، محیط‌زیست- موضوع کمی عمیق‌تر است، یعنی باید اقدامات بیشتری برای یکپارچه‌سازی خدمات معاونت‌های مختلف انجام داد. مثلاً در حوزۀ حملونقل و ترافیک، باید کار خیلی عمیق‌تری انجام شود تا سیستم واقعاً هوشمند شود و واقعاً هوشمند تصمیم‌گیری کند که الان کدام خیابان را ببندیم و کدام را باز کنیم، ترافیک را چطور مَنیج کنیم و از این دست مسائل. خیلی هم در این حوزه تلاش کردیم و همه کارش را هم کردیم. آراف‌پی‌ش را هم نوشتیم که یک پلتفرم اسمارت موبیلیتی در تهران داشته باشیم. ولی درنهایت در لایه‌های حمل‌ونقلی شهر هوشمند توفیق زیادی نداشتیم. البته یک‌سری کارها در حوزه‌های دیگر به نتیجه رسید.
مثلاً در حوزهٔ شهرسازی در حد توانمان قدم‌هایی برداشتیم. البته به نظرم هنوز زمان زیادی لازم داشت که کل سامانهٔ شهرسازی به یک سیستم هوشمند تبدیل شود، چون سامانهٔ موجود با دیزاین لازم برای ایجاد یک سیستم هوشمند تطبیق نداشت. بااینحال ما کارهایی انجام دادیم تا فرایندهای renovation (نوسازی) این سامانه سریع‌تر انجام شود و درخواست‌های renovation سامانهٔ شهرسازی زودتر به نتیجه برسد.
بنابراین اینکه تا فلان سامانه را نداریم یا تا سامانه‌هایمان قدیمی هستند نباید به سمت هوشمندسازی برویم حرف عجیبی است. به نظرم اگر ما آن نگاه شهرهوشمندی را نداشتیم همین کارهایی که در زمینهٔ بهبود سامانههای شهرداری انجام شد هم عملی نمی‌شد. اصلاً شما باید نگاه تحول دیجیتال داشته باشید تا بتوانید چنین سازمان‌هایی را تکان بدهید. در غیر این صورت، اگر قرار باشد در همان چارچوب معمول که یک واحد به شما اوردر میدهد و شما برایش نرم‌افزار می‌نویسید کار کنید، بی‌فایده است.
مصاحبه‌کننده: در ابتدای مصاحبه اشاره کردید که شما ایدۀ شهر هوشمند را داشتید و کمیتۀ شفافیت هم خیلی از این فضا دور نبود و یک همسویی کلی بین سازمان فاوا و کمیتهٔ شفافیت وجود داشت. البته آنها وزن بیشتری به شفافیت داده بودند، ولی شهر هوشمند هم جزء دغدغه‌هایشان بود. سازمان فاوا در آن دوره لیستی از پروژههای اولویت‌دارِ شهر هوشمند شهرداری به کمیتۀ شفافیت ارائه می‌کند و کمیته هم، بنا بر اولویت‌های خودش، آن را مرتب می‌کند. نکتهٔ جالب برای من این است که اولویت‌های سازمان فاوا با اولویت‌های کمیتهٔ شفافیت اشتراک خیلی کمی دارند. در چهارده پروژهٔ اولِ کمیتهٔ شفافیت، تنها سه پروژه حضور دارد که مطابق با اولویت‌بندی سازمان فاوا، جزء چهارده پروژهٔ اول این سازمان است: یکی همین پروژهٔ سامانۀ قراردادها، یکی ریزمتره، که نوشته‌اید عنوانش هم باید اصلاح شود، و مورد آخر، سامانهٔ رصد و پایش وسایل نقلیه.
محمد فرجود: می‌شود لیست را ببینم؟
مصاحبه‌کننده: بفرمایید.
محمد فرجود: این لیست مربوط به چه تاریخی است؟ به نظرم خیلی قدیمی است چون خیلی از این موارد در آن لیستی که بعداً لیست پروژههای ما شد وجود ندارد یا عوض شده است. حالا الان سؤال شما چیست؟
مصاحبه‌کننده: به نظر می‌آید اولویت‌های سازمان با اولویت‌های کمیته در بحث شهر هوشمند همپوشانی نداشته است.
محمد فرجود: یادم نمی‌آید که تفاوت جدی‌ای وجود داشته باشد. البته طبیعتاً ما متولی جمع‌کردن برنامه‌های طیف گسترده‌ای از سازمانها و معاونت‌ها و … بودیم و برای خودمان مکانیسم مجزایی برای تعریف و اولویت‌بندی پروژهها داشتیم. با یک لیست بلند شامل تقریباً پانصد پروژه شروع کردیم، تعدادی را حذف و موارد باقی‌مانده را وزن‌دهی کردیم. ما یک کمیتۀ راهبری تهران هوشمند هم داشتیم که شامل شهردار و چهار معاون او، چهار عضو از بیرون از مجموعهٔ شهرداری، و خانم آروین به‌عنوان نمایندهٔ شورا می‌شد -البته خانم آروین در جلسات شرکت نمی‌کرد. در آن کمیته پروژهها را اولویت‌بندی می‌کردیم. فرایند اولویت‌بندی چندمرحله‌ای بود و لیست نهایی ما را ۵۰ پروژهٔ اول تشکیل داد. ما در زمان خودمان نزدیک چهل‌وخرده‌ای از این ۵۰ تا را توانستیم استارت بزنیم. دلیل هم داشت که برخی از پروژهها استارت نخورد. مثلاً معاون حملونقل تأکید زیادی روی پروژۀ الآرتی داشت. چندین بار من گفتم که به نظرم شدنی نیست. اما ایشان اصرار داشت که من معاون حملونقل و ترافیک هستم و تو هم داری اسمارت موبیلیتی را استارت می‌زنی و باید این پروژه را هم در لیست پروژهها بگذاری.
بعداً معاون حملونقل تغییر کرد و معاون جدید اعتقاد چندانی به این پروژه نداشت و الآرتی را از لیست ما حذف کرد. ولی در ابتدا که می‌خواستم پلن را بنویسم باید می‌رفتم پیش معاون وقت حملونقل و معاون شهرسازی و دیگران که روی پروژههای آنها توافق کنیم. نمی‌شد به‌شکل دستوری به آنها بگوییم شما باید فلان کار را انجام دهید.
بالاخره روی چهل-پنجاه تا پروژه توافق شد. هر سال هم ما یکی-دو بار لیست را ریوایز می‌کردیم. بسیاری از پروژهها هم در این ریوایزها حذف می‌شد و یا دوباره add می‌شد. ولی آن لیست نهایی، که با این لیست شما فرق دارد، بالاخره از حاصل این فرایند درآمد. در خاطرم نیست که هیچ‌وقت شورا ایرادی به لیست ما وارد کرده باشد و گفته باشد بخشی از آن باید تغییر کند.
مصاحبه‌کننده: در سطح کلانِ شورا من هم موردی در خاطرم نیست، ولی به یاد می‌آورم که کمیتۀ شفافیت خیلی پیگیر این بود که دربارۀ اولویت‌بندی‌های پروژههای شهر هوشمند با سازمان فاوا به توافق برسد.
محمد فرجود: من چیزی در خاطرم نیست، ولی ما حداقل دربارۀ موضوعات اساسی اختلاف‌نظر جدی با کمیته نداشتیم و، تا جایی که یادم هست، همۀ پروژه‌هایی که برای کمیته مهم بود در لیست ما هم بود. ما هم داشتیم همۀ اولویت‌ها را تقریباً بهصورت همزمان با هم جلو می‌بردیم و در بعضی مواقع سی تا پروژه با هم در جریان بود که موضوعاتش هم با هم متفاوت بود و تیم‌های متفاوتی روی آن کار می‌کردند؛ در سازمان یک تیم کارهای نرم‌افزاریِ حوزۀ حملونقل را انجام می‌دادند، یک تیم کارهای حوزۀ شهرسازی و معماری را انجام می‌دادند، و … . مثلاً پانزده نفر در قالب تیم‌های کوچک‌تر مستقل روی پروژههای حوزۀ شهرسازی متمرکز بودند. درنتیجه پروژهها با هم انجام می‌شد و این‌طور نبود که یکی انجام شود و یکی نشود. ممکن بود که بعضی از پروژهها دیروزود شود، مثلاً درمورد شفافیت اطلاعات شهرسازی، مجبور شدیم چند جلسه با خانم آروین و آقای گلپایگانی داشته باشیم، ولی به‌طور کلی اختلاف‌نظر جدی‌ای بین ما و کمیته یادم نمی‌آید.
مصاحبه‌کننده: روی هرکدام از کارت‌هایی که مقابل شما قرار دارد یک تصمیم نوشته شده؛ تصمیمی که یا سازمان فاوا در دورهٔ حضور شما در سازمان گرفت یا در مسیر اخذ آن تصمیم قرار داشت. لطفاً کارت‌ها را به‌ترتیب بردارید و داستان تصمیمی که روی آن نوشته شده است را برای ما بگویید.
محمد فرجود: نپیوستن به سامانهٔ تدارکات الکترونیکی دولت (ستاد)[۱۶]. نپیوستن به ستاد بیشتر یک تصمیم بالاسری بود تا تصمیم سازمان ما. دو-سه دلیل پشت این تصمیم بود. یک دلیل این بود که سامانهٔ ما خیلی مفصل‌تر از ستاد بود. مثلاً در سازمان خود ما، از لحظه‌ای که فرد یا واحدی اعلام نیاز می‌کرد و درخواست کار می‌داد تا برگزاری مناقصه یا مزایده تا عقد قرارداد را می‌توانستیم بهصورت الکترونیکی انجام دهیم. درست است که برخی مراحل مربوط به انجام معامله هنوز الکترونیکی نشده بود، مثل بازگشایی پاکت «ج»[۱۷] که البته آن هم زیرساختش فراهم بود، اما بههرحال چیزی که ما پیاده‌سازی کرده بودیم خیلی کامل‌تر از ستاد بود؛ ما نه‌تنها امکان بارگذاری الکترونیکی اسناد، که امضای دیجیتال و بازگشایی الکترونیکی پاکات را هم پیاده‌سازی کرده بودیم.
به‌علاوه، در شهرداری، سامانهٔ قراردادها، سامانهٔ مالی و سامانهٔ صورت‌وضعیت به همدیگر متصل و با هم یکپارچه شده بودند و تا جایی که بخش‌های مختلف شهرداری از این سامانه‌ها استفاده می‌کردند، همهٔ عملیات‌های مالی و معاملاتی، با جزئیات، در این سامانه‌ها ثبت می‌شد. این موضوع خودش مزیتی برای استفاده از سامانهٔ قراردادهای شهرداری به‌جای سامانهٔ ستاد بود.
یادم است ستادی‌ها از ما می‌خواستند یک تکه از فرایند انجام معاملات را از سامانهٔ خودمان درآوریم و آن قسمت را روی سامانهٔ ستاد انجام دهیم. این کار سامانهٔ ما را تبدیل به یک چیز ناقص‌الخلقه می‌کرد. ضمن آنکه بعد از چند جلسه با ستادی‌ها، به این جمع‌بندی رسیدیم که پیاده‌سازی مراحل انجام معاملات شهرداری روی ستاد، به واسطهٔ جزئیات بسیاری که این مراحل دارد، به‌لحاظ فنی برایشان ممکن نیست. خب، چیزی هم که شورا به ما تکلیف کرده بود خیلی مفصل‌تر از چیزی بود که ستاد از آن پشتیبانی می‌کرد. مجموعهٔ این دلایل موجب شد تا پیوستن شهرداری تهران به سامانهٔ ستاد منتفی شود. حداکثر کاری که می‌شد کرد این بود که ما یک گزارش دستی، مثلاً یک فایل اکسل، از معاملاتمان به آنها بدهیم تا روی ستاد بارگذاری کنند، اما امکان برقراری سرویس الکترونیکی بین این دو سامانه وجود نداشت.
شهرداری برای نپیوستن به ستاد یک دلیل دیگر هم داشت و میگفت بودجۀ شهرداری از سمت دولت تأمین نمیشود، پس الزامی وجود ندارد که به سامانهٔ دولت بپیوندم. اگر هدف شفافیت و اطلاع‌رسانی است که من دارم این کار را از طریق سامانههای خودم می‌کنم. فرایند انجام معاملات را هم که آنلاین کرده‌ام و هرکس می‌خواهد شرکت می‌کند. درنهایت نپیوستن به ستاد یک تصمیم بالادستی بود.
مصاحبه‌کننده: شما به‌عنوان سازمان فاوا چه نقشی در این تصمیم داشتید؟
محمد فرجود: ما با دوستان ستاد جلسه گذاشتیم و صحبت کردیم. به آنها گفتیم امکانات سامانهٔ شما خیلی کمتر از سامانۀ ایجادشده توسط سازمان فاوای شهرداری است. یادم است خود آنها گفتند که ما نمی‌توانیم مدل مدنظر شما را در سامانه پیاده کنیم. بنابراین اگر می‌خواستیم از سامانهٔ ستاد استفاده کنیم، بیشترین کاری که می‌توانستیم انجام دهیم این بود که یک نسخهٔ آفلاین از همهٔ کارهایی که در سامانهٔ قراردادها می‌کنیم برداریم و در سامانهٔ ستاد بارگذاری کنیم.
ما این جمع‌بندی و نظر کارشناسی را به مقامات بالادست انتقال دادیم، اما واقعیت این است که اگر شهرداری میگفت باید به سامانهٔ ستاد بروید، خب می‌رفتیم. درنهایت تصمیم این شد که لزومی ندارد ما به آن سامانه‌ای که خیلی ناقص‌تر از سامانهٔ خود ماست بپیوندیم؛ سامانهٔ خودمان دارد خیلی بیشتر از آن کاری که آن سامانه می‌خواهد انجام دهد را انجام میدهد -در پرانتز بگویم که الان دارند پیمانکار سامانهٔ ستاد را عوض می‌کنند.
مصاحبه‌کننده: برویم سراغ کارت بعدی.
محمد فرجود: استفاده از سامانهٔ قراردادها به‌عنوان بستر اجرای مصوبهٔ «الزام شهرداری تهران به انجام الکترونیکی و اعلان عمومی اطلاعات معاملات». مصوبه شهرداری را ملزم کرده بود تا بستر انجام الکترونیکی تمامی انواع معاملات در شهرداری را فراهم و اطلاعات آن را منتشر کند. این‌طور به یاد دارم که ما همیشه نگاه می‌کردیم ببینیم که چه چیزی داریم و چطور می‌توانیم از آن استفاده کنیم. زمانی هم که بحث انجام الکترونیکی معاملات و انتشار اطلاعات آن مطرح شد، با تیم‌های مرتبط در سازمان فاوا جلساتی گذاشتیم و به این نتیجه رسیدیم که همان سامانه‌ای که از قبل برای انجام مناقصات در شهرداری ایجاد شده بود را مبنا قرار دهیم و کاملش کنیم. اسم دقیق این سامانه سامانهٔ «مناقصات و امور پیمانکاران» بود ولی از آن به بعد عملاً به آن سامانهٔ قراردادها می‌گفتیم. این سامانه در ابتدا قرار بود کار درخواست مناقصه و فرایند تأیید آن تا رسیدن به مرحلهٔ برگزاری مناقصه را انجام دهد. این قسمت و همچنین قسمت مربوط به ثبت اطلاعات قراردادهای منعقدشده را در دوره‌های قبل از ما سفارش داده بودند و آماده شده بود. می‌ماند قسمت میانی فرایند معاملات یعنی مراحلی مثل اعلام مناقصه، دریافت و بازگشایی پاکات و امضای صورتجلسه.
قرار شد این قسمت میانی را بنویسیم -که کار خیلی مفصلی هم بود- و بعد آن را به سامانه add کنیم. همزمان، قسمت‌های موجود را برای آنکه از کلیهٔ انواع معاملات، و نه فقط مناقصات، پشتیبانی کند و فرایندهای معاملاتی سازمانها و شرکت‌ها هم به آن اضافه شود، ارتقا دهیم. به این ترتیب، ما اول دیدیم چه چیزی داریم و بعد هم بررسی کردیم که چه چیزهایی را باید به آن اضافه کنیم.
یادم است پیاده‌کردن همهٔ قابلیت‌های سامانه برای برخی بخش‌ها سخت بود. دلیل هم داشت؛ قوانین معاملات در خیلی از شرکت‌ها با یکدیگر فرق می‌کرد و پیاده‌سازی برخی از آنها خیلی پیچیده بود. درنتیجه ما یک نسخهٔ سبک‌تر از سامانه برای آنها پیاده کردیم که حتی اگر فرایند درخواست مناقصه یا فرایند عقد قرارداد را در سامانه طی نمی‌کنند، دست‌کم بتوانند پس از انعقاد قرارداد، اطلاعات قرارداد خود را در سامانه وارد کنند. اما قسمتی که مربوط به برگزاری مناقصه یا مزایده بهصورت الکترونیک بود اساساً جدید بود و ما در همان دوره آن را به‌عنوان یکی از پروژه‌هایمان تعریف کردیم. واقعاً هم در آن مقطع از لحاظ فنی کار خیلی خوب و مناسبی انجام شد. وقت زیادی صرف کردیم که ببینیم باید چه کار کنیم تا سیستم واقعاً کار کند، به این معنا که فرد بتواند پی‌دی‌اف اسناد معاملات را بهصورت الکترونیکی دریافت و آن را پر کند، اسناد را بهصورت دیجیتالی sign (امضا) کند، بعد داکیومنت را بارگذاری کند و ما با کلید و امضای دیجیتال آن را باز کنیم -توجه داشته باشید که این داستان مربوط به سه سال پیش می‌شود که بحث امضای دیجیتال به اندازهٔ الان مطرح نبود، الان مردم با این مفهوم بیشتر آشنا شده‌اند. پیاده‌سازی این قابلیت‌ها در دورهٔ قبل اتفاق افتاد و قبل از آن اصلاً چنین قابلیت‌هایی در سامانه وجود نداشت.
مصاحبه‌کننده: شما رئیس سازمانی شده بودید که سابقهٔ کار قبلی در آن را نداشتید و معاونان و مدیران آن را نمی‌شناختید. درعین‌حال می‌خواستید بر مبنای گزارش‌های کارشناسی آنها -چه در موضوع سامانهٔ ستاد و سامانهٔ قراردادها، چه در موضوعات دیگر- تصمیم‌گیری کنید. چطور گزارش‌هایی که به شما می‌رسید را ارزیابی و به آن اعتماد می‌کردید؟
محمد فرجود: این سؤال خیلی کلی است و به مقطع زمانی‌ای که دربارهٔ آن حرف می‌زنیم هم بستگی دارد. طبیعتاً شما خودت نمی‌توانی بروی جای کارشناس بنشینی و همیشه باید تا حد زیادی به نظر کارشناسی اعتماد کنی. فرایند اعتمادکردن یک‌روزه اتفاق نمی‌افتد. وقتی شخصی سازمانی را تحویل می‌گیرد، به‌خصوص اوایل کار، باید کلی دیتا از منابع مختلف جمع کند، کم‌کم با سازمان و کار آن آشنا شود، بفهمد که چه کسی چه کار کرده، چه دیتایی دارد، شیوه و رویه‌اش چیست و مواردی از این دست. این فرایندِ شناخت اصلاً به این راحتی‌ها طی نمیشود و شخص به‌تدریج و با تجربه‌کردن می‌فهمد که چی به چی است.
ما افرادی را که به‌عنوان معاون یا مدیر منصوب می‌کردیم با جست‌وجو و بررسی زیاد انتخاب کرده بودیم. ضمن اینکه ما در سازمان فاوا خیلی از افراد را از سمت کارشناسی به‌مرور زمان تا سمت مدیریت ارتقا دادیم و این افراد خیلی هم به ما کمک کردند. بالاخره هم من و هم آقای مقصودلو (جانشین مدیرعامل در سازمان فاوا) و هم تیم مدیریتی که کنار ما بودند تا حد زیادی دستمان آمده بود که چه کسی در چه کاری متخصص است، یا اگر دیتای اشتباه می‌آید چطور باید اطلاعات را ارزیابی و صحت‌سنجی کنیم؛ از افراد مختلف گزارش می‌گرفتیم و تقاطع می‌دادیم و سعی می‌کردیم با گزارش‌گیری و سؤالات مکرر به داده‌های موردنظرمان برسیم. به‌علاوه، در حوزهٔ نرم‌افزار و حوزهٔ شبکه مشاورانی داشتیم که اگر سواد ما نمی‌رسید آنها هم نظر می‌دادند. اصلاً معاون شبکه را من خودم از خارج از سازمان آورده بودم و می‌دانستم که اطلاعات اشتباه نمی‌دهد.
نکتهٔ دیگری که می‌خواهم بگویم این است که قاعدتاً ما هم مکانیسمی برای شناختن بیشتر معاون و نیروهای زیرمجموعه داشتیم. این‌طور نبود که فقط به حرف یک نفر گوش کنیم. همهٔ پرسنل، از مدیر تا کارشناس، را می‌شناختیم. در صورتی که به گزاش مدیر بالادست شک می‌کردیم، سراغ کارشناس می‌رفتیم. بالاخره در این مدت افرادی هم جذب شده بودند که زمان خود ما آمده بودند و تراست ما به آنها بیشتر بود.
ببینید، همیشه این امکان وجود دارد که گزارشی که به دست مدیر می‌رسد بایاس داشته باشد یا اشتباه باشد؛ این واضح است. اما بالاخره مدیر باید این قدرت را داشته باشد که بتواند این موارد را بفهمد. ما اغلب می‌توانستیم این موارد را تشخیص دهیم و خیلی بعید بود که تصمیمات بزرگ را با داده‌های ناقص بگیریم. شاید روزهای اول احتمال خطا در تصمیم‌گیری‌های ما بیشتر بود اما روزهای آخر امکان اینکه با اطلاعاتی که ۱۸۰ درجه با واقعیت فرق کند روبه‌رو شویم و نفهمیم بعید بود. هرچند در تصمیم‌گیری این امکان وجود داشت که به‌خاطر کارهای دیگری که داشتیم، مثلاً بهبود سامانه‌ای که می‌دانستیم عملکرد مناسبی ندارد را در اولویت نگذاریم. یا ممکن بود ایده‌آل ما این باشد که سطح کوالیتی تیم‌هایمان دوبرابر شود اما وقتی شهرداری میگفت نمی‌گذارم نیرو بگیری، نمی‌شد شرایط تیم‌ها را خیلی change کرد (تغییر داد). یکسالونیم طول کشید تا ما توانستیم از همین نیروهای پارت‌تایم شهرداری سی نفر را جذب کنیم. تازه شورای جدید ما را بازخواست کردند که چرا نیروی جدید گرفتید. می‌گفتند این‌ها (یعنی ما) زمانی که به پایان دوره نزدیک شده بودند و در دقیقهٔ نود، نیرو اضافه کردهاند. من هم به صحن شورا رفتم و گفتم تاریخ ورود همهٔ کسانی که جذب سازمان فاوا شدند به دورهٔ مدیریت‌های قبلی برمی‌گردد. آنها هم دیگر چیزی نگفتند.
کارت بعدی. محدودیت مشاهدهٔ اطلاعات شهرسازی برای هر کاربر. منظورتان از این کارت چیست؟
مصاحبه‌کننده: بعد از انتشار پرونده‌های ساخت‌وساز روی نقشهٔ تهران، با انتخاب بلوک-ملک و کلیک روی آن می‌شد اطلاعات پروندهٔ شهرسازی مربوط به آن را دید. اما هر کاربر در هر روز فقط می‌توانست اطلاعات پنج پرونده را ببیند.
محمد فرجود: در ابتدا چنین محدودیتی وجود نداشت. این‌طور که یادم است، مشکلی که پیش آمد این بود که معاملات ملکی‌ها دائماً روی ملک‌ها استعلام می‌گرفتند و دیتا را fetch (فراخوانی) می‌کردند. این کار باعث کندی سامانهٔ شهرسازی ما شده بود و برای ما چالش ایجاد می‌کرد. روی همین حساب، با معاونت شهرسازی و شورا و بقیه متولیان مشورت کردیم و گفتیم یک فرد عادی قاعدتاً نمی‌آید هر روز استعلام ده تا ملک را بگیرد، بنابراین کسانی که مدام در حال استعلام‌‌گرفتن هستند استفاده‌های دیگری جز بحث شفافیت و نظارت بر تخلفات ساخت‌وساز از این دادهها دارند، پس ما بیاییم یا از یک تعداد بیشتر استعلام در روز را پولی کنیم و یا روی تعداد استعلام روزانه لیمیتیشن بگذاریم. گفتند پولی نکنیم، و به این ترتیب قرار شد روی تعداد استعلام در روز لیمیتیشن بگذاریم. این تصمیم هم یک تصمیم جمعی بود و تصمیم انفرادی سازمان فاوا نبود.
بنابراین محدودیتی که ما اعمال کردیم مربوط به اصل دسترسی به اطلاعات نبود؛ همه می‌توانستند به دیتای منتشرشده دسترسی داشته باشند. اما ما به‌لحاظ فنی در ایجاد دسترسی به تعداد بالای استعلامات مشکل داشتیم، چون سامانهٔ شهرسازی سامانهٔ سنگینی بود و تعداد زیاد استعلامات هم لود زیادی روی سامانهٔ ما ایجاد می‌کرد. اگر وضع به همان منوال پیش می‌رفت، دیگر هیچ‌کس نمی‌توانست از سامانه استفاده کند و عملاً نقض غرض می‌شد.
مصاحبه‌کننده: از کجا فهمیدید تعداد بالای استعلامات مربوط به املاکی‌هاست؟
محمد فرجود: خب معلوم است کاربری که روزی صدتا ملک را استعلام می‌گیرد مشاور املاک است. بههرحال ما حالت رایگانِ این امکان را برای نیاز مردم عادی فعال نگه داشته بودیم. قرار بود که حالت تجاری‌اش هم فعال شود و فکر کنم ای‌پی‌آی آن را هم گذاشتیم که اگر کسی می‌خواهد بیاید پکیج تجاری‌اش را بگیرد (وقتی پول می‌دهید دیگر استعلام بیهوده نمی‌کنید) در بحث ای‌پی‌آی ، دسترسی برای شرکت‌های واسط ایجاد می‌شد که از طریق ای‌پی‌آی می‌توانستند اطلاعات را فراخوانی کنند، به همین خاطر برای هر فراخوانی باید هزینه‌ای پرداخت می‌شد. این روند، مجزا از دسترسی عمومی‌ای بود که در سامانه ایجاد کرده بودیم. یعنی دسترسی عمومی را از بین نبردیم، ولی برای دسترسی رایگان محدودیت برقرار کردیم، چون اطلاعات پرونده‌های شهرسازی سنگین بود، هر کدام اطلاعات متفاوتی داشت و اگر هرکسی می‌خواست هر روز برود همۀ این‌ها را ببیند، لودش خیلی زیاد می‌شد، نمی‌توانستیم آن را کنترل کنیم و سِرور با مشکل مواجه می‌شد.
با این اوصاف، طبیعی بود که یک جاهایی محدودیت‌هایی اعمال کنیم. البته اطلاعاتِ بیسیک، پابلیک بود و این محدودیتی که می‌گویم مربوط به دیتیل پرونده‌ها بود، یعنی اینکه بخواهید همۀ اطلاعات پرونده را ببینید.
مصاحبه‌کننده: به‌جای ایجاد محدودیت مشاهده، به سمت ارتقادادن سیستم‌ها نرفتید؟
محمد فرجود: ببینید، سامانهٔ شهرسازی سامانهٔ خیلی سنگین و پیچیده‌ای بود. بیست‌و‌خرده‌ای زیرسامانه داشت. به این راحتی‌ها نبود که بگوییم برویم سیستم را ارتقا دهیم. اگر می‌شد این کار را انجام داد، می‌کردیم، که البته خیلی جاها هم این کار را کردیم. ضمن آنکه لیمیت‌گذاشتن روی سرویس آزاد و رایگان هم کار عجیبی نیست و متداول است. عمدهٔ کاربران این سرویس هم مردم نبودند. یعنی من هیچ‌وقت کسی از مردم را ندیدم که شکایت کند، بگوید من امروز می‌خواستم پنجاه تا استعلام بگیرم و نتوانستم، چون نیاز مردم عادی در این حد نیست. مثلاً می‌خواهند یک خانه بخرند. حالا اگر در روز بنگاهی پنج تا خانه هم به آنها نشان بدهد و آنها بخواهند اطلاعات این پنج خانه را ببینند، همان پنج استعلام کافی است. مشخص بود که تعداد زیاد استعلامات از یک آدرس مشخص (آی‌پی[۱۸])، بنگاهی‌ها هستند و نه شهروند معمولی. پیشنهاد ما این بود که اگر بنگاهی‌ها سرویس می‌خواهند، ما یک سرویس برایشان درست کنیم و داده را به آنها بفروشیم که در این حالت چون برای دریافت اطلاعات هزینهٔ مالی می‌کردند، در استفاده از آن دقت می‌کردند و فشاری به سیستم وارد نمی‌آمد. اما آن موقع تصمیم معاونت شهرسازی بر چنین رویه‌ای نبود و گفتند فعلاً موقعیت را با همین لیمیتیشن‌گذاشتن مدیریت کنید.
مصاحبه‌کننده: کلاً سازمان فاوا ایدهٔ درآمدزایی از طریق داده را داشت؟
محمد فرجود: بله.
مصاحبه‌کننده: عملیاتی هم شد؟
محمد فرجود: قرار بود کمیته‌ای راجع به بحث درآمدزایی از داده تصمیم‌گیری کند اما جلسات آن تشکیل نشد -با وجود اینکه حتی احکام اعضایش را که عمدتاً صاحب‌نظران و معاونان سازمان فاوا و مرکز آمار و رصد شهری بودند را هم زده بودند. به همین خاطر ما خودمان در مواردی مثل سرویس نقشه، سرویس‌های جی‌آی‌اس[۱۹]، بخشی از ای‌پی‌آی‌هایی که روی api.tehran.ir ارائه می‌شد و نظایر آن مجوز گرفتیم تا روی این سرویس‌ها درآمدزایی کنیم. برای درآمدزایی از ای‌پی‌آی‌ها ما مدل pricing (قیمت‌گذاری) داشتیم؛ تعدادی از ای‌پی‌آی‌ها رایگان بود و تعدادی پولی. در شهرداری هم فقط ما این کار را می‌کردیم و کس دیگری دنبالش نبود. هدف اصلی ما هم این نبود که بخواهیم درآمدزایی داشته باشیم، چون مبلغی که از این طریق به دست می‌آمد مبلغ قابل‌توجهی نبود. بیشتر به خاطر این بود که بههرحال فرایند آماده‌سازی این سرویس‌ها هزینه داشت و طرفِ سرویس‌گیرنده هم راغب بود که هزینهٔ آن را بپردازد. درنتیجه روی ارائهٔ ای‌پی‌آی‌های مختلف، قیمت‌گذاری هم می‌کردیم و درمورد آن جدی بودیم. اصلاً بخش فروش و پشتیبانی مشتری در سازمان فاوا یک تیم داشت که به درخواست‌های دریافت ای‌پی‌آی رسیدگی می‌کرد. فکر می‌کنم این سیستم هنوز هم در شهرداری فعال باشد.
کارت بعدی. فعال‌کردن کمیتهٔ اطلاع رسانی. این چیست؟
مصاحبه‌کننده: پیشتر اشاره کردید که شما تلاش کردید تا فرایندی برای تأیید محتواییِ دیتا برای انتشار عمومی در شهرداری تعریف شود. آن‌طور که ما می‌دانیم، کمیته‌ای با نام کمیتهٔ اطلاع‌رسانی برای این منظور تشکیل شد -یا از قبل وجود داشت و در دورهٔ قبل فعال شد- تا تأیید نهایی انتشار اطلاعات را بدهد. نقش شما در فعال‌کردن این کمیته چه بود؟
محمد فرجود: نه، کمیتهٔ اطلاع‌رسانی که شما می‌گویید چیز دیگری بود. ببینید، شهرداری یک کمیتهٔ اطلاع‌رسانی داشت که اگر اشتباه نکنم در معاونت اجتماعی تشکیل می‌شد و از خود معاونت، سازمان فاوا، روابط عمومی، سازمان فرهنگی و هنری و شاید برخی بخش‌های دیگر در آن عضویت داشتند. دستورکار این کمیته از آن چیزی که شما می‌گویید متفاوت بود؛ دستورکارش تصمیم‌گیری درمورد نحوهٔ اطلاع‌رسانی موضوعات مختلف به شهروندان بود. حالا ما چرا در آن کمیته عضو بودیم؟ چون در دوره‌ای سایت شهرداری و اکانت‌های شهرداری در شبکه‌های مجازی در اختیار سازمان فاوا بود. حتی تیم تولید محتوا هم در سازمان فاوا بود. من که به سازمان فاوا آمدم، مدیر وقتِ روابط عمومی گفت سایت و اکانت توییتر و غیره را در اختیارشان قرار بدهیم. من طبق منطق خودم دیدم درست می‌گوید و مسئولیت تولید محتوا نباید دست سازمان فاوا باشد؛ سازمان فاوا باید سایت را ایجاد کند و روابط عمومی باید محتوا را روی این سایت بگذارد. بنابراین با روابط عمومی جلسه گذاشتیم و سایت و اکانت‌های مجازی را به آنها تحویل دادیم. اما بعد از مدتی مشکلی پیش آمد.
زمانی که ما اکانت‌ها را به روابط عمومی تحویل دادیم، برای هر کدام یک پسورد ساده، چیزی شبیه ۱۲۳۴۵، گذاشته بودیم و به آنها گفتیم خودتان این پسورد را تغییر دهید. آنها این کار را نکردند و مثلاً بعد شش ماه، یک نفر اکانت توییتر شهرداری را هک کرد. فکر می‌کنم اوایل سال ۹۷ بود. در پی این اتفاق چالش‌ها و بحث‌های مختلفی ایجاد شد. ما با سختی زیاد اکانت را پس گرفتیم، یعنی درواقع فقط توانستیم آن را inactive (غیرفعال) کنیم. به هرحال نکتهٔ اصلی که می‌خواهم بگویم این است که رویکرد ما این بود که سازمان فاوا فقط ابزار را فراهم می‌کند و مسئول اطلاعات نیست. درحالیکه قبلاً این‌جوری نبود و همانطور که گفتم، تیمی در سازمان فاوا گذاشته بودند که خبر تولید می‌کرد و توییت می‌زد. این سیستم بر اساس اعتمادی که شهردار وقت به مدیرعامل سازمان فاوا داشت شکل گرفته بود وگرنه از نظر فانکشنال این اتفاق نباید می‌افتاد. دلیل حضور ما در کمیتهٔ اطلاع‌رسانی هم همین سیستم باقی‌مانده از دورهٔ قبل از ما بود. البته با انتقال مسئولیت تولید و تأیید محتوا به روابط عمومی، حضور ما به‌تدریج کم‌رنگ شد.
کارت بعدی، جایگزینی سامانهٔ جامع مالی با سامانههای مالی موازی. به نظرم راجع به این موضوع به قدر کافی صحبت کردیم. این کار از آن کارهای سخت بود، ولی درنهایت شهرداری خیلی از بابت انجامش خوشحال بود.
مصاحبه‌کننده: منظورتان از شهرداری، شهرداری مرکز است؟
محمد فرجود: بله، شهرداری مرکز. سازمانها و شرکت‌ها اعتراضاتی داشتند، ولی واقعیت این است که درنهایت خیلی به نفعشان شد چون دیگر از داستان‌های توسعه و پیشتیبانی سامانه راحت شدند و همهچیز مرکزی شد.
خب، کارت بعدی توسعۀ سامانۀ صورت‌وضعیت بهصورت امانی است. کمی دربارهٔ این کارت توضیح می‌دهید؟
مصاحبه‌کننده: قرار بود در شهرداری -به‌طور خاص در معاونت‌های خدمات شهری و فنی‌عمرانی که خیلی با بحث صورت‌وضعیت درگیرند- سامانه‌ای برای مدیریت بحث‌های مربوط به صورت‌وضعیت در شهرداری راه بیفتد. پیمانکارانی بودند که بعضاً سابقۀ کار برای شهرداری تهران یا تجربۀ راهاندازی سامانه برای شهرداری‌های شهرهای دیگر را داشتند و این معاونت‌ها داشتند به این سمت می‌رفتند که برای توسعهٔ سامانهٔ صورت‌وضعیت با این پیمانکارها کار کنند. اما درنهایت تصمیم بر آن می‌شود که این کار به پیمانکار سپرده نشود و سازمان فاوا خودش بهصورت امانی کار را انجام دهد. این ماجرایی بود که در مصاحبه‌های دیگر گزارشش به ما رسید. می‌خواستیم ببینیم مبانی این تصمیم چه بوده است؟
محمد فرجود: یادم نیست. این را باید بپرسم.
مصاحبه‌کننده: به‌طور کلی تصمیم‌گیری راجع به اینکه کار یک سامانه را خودتان در سازمان انجام دهید یا آن را به پیمانکار دهید چطور انجام می‌شد؟
محمد فرجود: تصمیم به برون‌سپاری یا استفاده از ظرفیت‌های داخلی تصمیمی بود که ما روزانه با آن روبه‌رو بودیم. در سازمان زیاد از این داستان‌ها داشتیم و یک فرایند و مکانیسم درونی هم داشتیم که ببینیم چه کاری را به پیمانکار بدهیم؛ بیشتر درمورد نرم‌افزار بود، اما درمورد جی‌آی‌اس هم بود. در آن مواردی که واحدهای ذی‌ربط و معاونت‌های سازمان فاوا می‌توانستند تصمیم بگیرند که تصمیم می‌گرفتند، در آن مواردی که سطحش بالاتر بود، معمولاً موضوع به شورای معاونان سازمان فاوا می‌آمد، یا جلسات ویژه می‌گذاشتیم که تصمیم بگیریم، یعنی، غیر از معاونان، ما هم به موضوع ورود می‌کردیم. درکل فراوان پیش می‌آمد که مثلاً تصمیم بگیریم کاری را که تا الان خودمان انجام داده‌ایم برون‌سپاری کنیم، یا کاری را که بیرون انجام می‌شود برگردانیم داخل. دلایل مختلفی هم داشت. به‌طور معمول، من خیلی سعی کردم که ما خودمان توسعه‌دادن همهچیز را به عهده نگیریم و تا جایی که می‌توانیم از ظرفیت بقیه استفاده کنیم. اما یکی از مشکلات سازمان این بود که اکثر پیمانکارهایش در حد و اندازهٔ سازمان فاوا نبودند.
ما پیمانکارهایی داشتیم که کل درآمدشان از ما بود، یعنی اگر ما به آنها کار نمی‌دادیم، شرکتشان تعطیل می‌شد. خیلی از این پیمانکارها اصلاً سابقه‌ای نداشتند؛ روزی آمده بودند و مسئولیتی را قبول کرده بودند و بعد همین‌گونه فعالیتشان ادامه پیدا کرده بود. به همین دلیل، اتفاقات نامناسبی هم افتاده بود؛ مثلاً پیش می‌آمد که نیروهای یک شرکت رفته بودند ولی شرکت همچنان پیمانکار شهرداری باقی مانده بود و به همین دلیل کیفیت سرویسی که ارائه می‌شد مناسب نبود، و مثلاً وقتی از او می‌خواستیم که کار جدیدی را دولوپ کند، چون نیروهایش کم شده بود نمی‌توانست کار را به‌درستی انجام دهد. ما خیلی از این شرکت‌ها داشتیم. پیمانکار هم باید از نظر فنی هم‌اندازهٔ کارفرما باشد. به همین دلیل یکی از کارهایی که ما کردیم این بود که دائماً فراخوان‌های باز گذاشتیم، یعنی می‌گفتیم در حوزه‌های مختلف هرکسی هرموقع علاقه‌مند بود بیاید خدماتش را ارائه کند. دائم این لیست‌هایمان را نگاه می‌کردیم و سعی می‌کردیم شرکت‌های جدید را وارد بازی کنیم. پیمانکارهای بزرگ نرم‌افزاری خیلی کم با شهرداری همکاری می‌کردند. اکثر پیمانکارهایی که ما داشتیم شرکت‌هایی بودند که وقتی از آنها می‌پرسیدیم چند درصد درآمدت از سازمان فاوا است، می‌گفتند ۹۰ یا ۹۵درصد. حتی یکی از آنها میگفت همۀ درآمد من از شماست و اگر شما کار ندهید ما باید تعطیل کنیم. خب این‌ها از نظر اندازه کوچک بودند.
پس آن موضوعی که می‌گویید -تصمیم به توسعهٔ سامانهٔ صورت‌وضعیت بهصورت امانی- محتمل است. البته دربارهٔ جزئیات این مورد خاص باید پرس‌وجو کنم. اما بههرحال ممکن است متوجه شوید که پیمانکارتان نمی‌تواند کار را انجام دهد و یک جایی، برای اینکه کار شهرداری به سرانجام برسد، تصمیم بگیرید که آن را برگردانید داخل. ولی روال این نبود. روال ما این بود که تا جای ممکن ظرفیت بیرونی را اضافه و پیمانکار اضافه کنیم و مشاوران و پیمانکاران بزرگ و باتجربه بیاوریم.
مصاحبه‌کننده: پیمانکارهای قَدَر خودشان مایل نبودند با شهرداری کار کنند یا شهرداری راهشان نمی‌داد؟
محمد فرجود: به نظرم هیستوری طولانی‌ای دارد و یک ماجرای دوطرفه است. مثلاً اینکه شهرداری خوب پول نمی‌دهد یا نمی‌داد‌ه یکی از عوامل عدم تمایل شرکت‌های بزرگ به کارکردن با شهرداری است. از این طرف شهرداری گاهی سطح کارها را خیلی پایین می‌آورد تا آن را به یک پیمانکاری بدهد که فقط محصول یا خدمتی ایجاد شود. وقتی خودتان چشم‌انداز کاملی از آنچه باید انجام شود ندارید، ممکن است آن کار را به شرکتی دهید که در حد و اندازهٔ خواسته و برنامهٔ شما نباشد و در این صورت محصول مناسبی ایجاد نخواهد شد. کم نبودند پروداکت‌های ناقص‌الخلقه و ضعیف و سامانه‌هایی که روزی نوشته شده بودند و می‌پرسیدی چه کسی از آنها استفاده می‌کند، می‌گفتند فقط چند نفر از چند سازمان که تعداد قابل ملاحظه‌ای هم نبود. ولی چالش اصلی این بود که چه زمانی می‌توانیم منابع مالی تغییردادن این سامانه‌ها را تأمین کنیم.
مشکل دیگر این بود که شهرداری تهران، وقتی ما به آن وارد شدیم، به اکوسیستم خودش در حوزهٔ شرکت‌های آی‌تی و حتی مخابراتی چندان متصل نبود، یعنی خیلی از شرکت‌ها می‌گفتند ما خواستیم با شهرداری همکاری کنیم و آمدیم و رفتیم ولی خبری نشد یا شهرداری اصلاً از حال ما و کارهای ما خبر ندارد. ما دائم با بخش‌های مختف نظام صنفی امور رایانه‌ای استان و کشور جلسه می‌گذاشتیم یا برای اینکه چهار تا شرکت قوی‌تر هم بیایند کنار همین‌هایی که هستند، فراخوان می‌گذاشتیم. ما پیمانکاران قبلی را هم اخراج نکردیم و به خیلی‌هایشان کمک کردیم که تقویت شوند. ولی واقعیت این است که خیلی ضعف وجود داشت، یعنی آن زمانی که من وارد شدم واقعاً نمی‌توانم بگویم که پنج تا پیمانکار بزرگِ well-known (شناخته‌شده) در حوزۀ آی‌تی در سازمان وجود داشت. آن‌هایی که بودند اکثراً کوچک بودند، کوچک‌هایی که، با وجود سال‌های همکاری با شهرداری، رشد هم نکرده بودند. مثلاً دو-سه تا دولوپر نرم‌افزار گرفته بودند و گذاشته بودند آنجا. رشد هم خب طبیعتاً اتفاق نمی‌افتاد، چون پول را می‌گرفتند و خرج می‌کردند و دیگر کاری در جهت رشد نمی‌کردند.
مصاحبه‌کننده: زیرساخت فناوری اطلاعات شهرداری در مقایسه با سایر سازمانهای دولتی و عمومی چه وضعیتی داشت؟
محمد فرجود: شهرداری به نسبت بهتر از خیلی سازمانهای دولتی دیگر بود. هرچند ما سازمان‌هایی ذیل بعضی از وزارتخانهها داریم که پول‌دار بودند و پول‌های خوبی در حوزۀ آی‌تی خرج کرده بودند و بنابراین نمی‌توانم حکم کلی بدهم. درکل باید ببینید چقدر منابع به حوزهٔ آی‌تی اختصاص می‌دهید. شهرداری، به‌واسطۀ اینکه در مقاطعی وضع مالی‌اش خیلی خوب بوده، به نسبت عموم سازمانهای دولتی اوضاع بهتری داشت. قبل از ما، به‌ویژه در دورۀ آقای قالیباف که ذاتاً به آی‌تی علاقه داشت، زیرساخت‌های شهرداری توسعهٔ زیادی پیدا کرده بود. البته مدلی که در دورهٔ آقای قالیباف کار شده بود به نظر من خیلی capital intensive (سرمایه‌بر) بود. در مقایسه، ما چون منابع مالی مناسبی نداشتیم، بیشتر روی software (نرم‌افزار) و این چیزها کار کردیم، ولی آنها روی زیرساخت شبکه و سخت‌افزار بیشتر سرمایه‌گذاری کردند که در آن مقطع شاید واقعاً کمک‌کننده هم بوده. بههرحال آنها به آی‌تی از یک سطح بالاتر نگاه می‌کردند و زیرساختی را آماده کرده بودند که ما بعداً کارهایمان را روی آن سوار کردیم. ما هم بیشتر تلاشمان صرف این می‌شد که سرویس بیشتری بدهیم، چون من نمی‌توانستم آن خرج‌هایی را که آنها به دلار کرده بودند بکنم؛ تمام پول ما طی چهار سال، بعضاً به‌اندازۀ پولی که آنها در یک سال صرف توسعهٔ سخت‌افزاری زیرساخت آی‌تی شهرداری کرده بودند نمی‌شد. درکل اگر بخواهم استیت را بگویم، وضعیت شهرداری از خیلی از سازمانهای دولتی بهتر است یا بهتر بود، چون الان را نمی‌دانم که اوضاع به چه ترتیب است، ولی در مقایسه با خیلی از سازمانهای بخش خصوصی ضعیف‌تر است.
در مقایسه با دنیا هم وضع بد نبود؛ در شهرداری تهران، با تمام ضعف‌هایی که وجود دارد، از خیلی از کشورهای دنیا جلوتریم. دلیلش این است که اولاً ما در حوزۀ سرویس‌های شهرداری‌ها و شهر تهران، که خب از سایر شهرهای ایران جلوتر است، سامانههای زیادی داشتیم و داریم که خیلی از کشورها نداشتند و ندارند. ثانیاً IT readiness (آمادگی فناوری اطلاعات) ما در ایران هم در مردم هم در کارکنان بد نیست، یعنی اکثر کارکنان ما حداقل مدرک لیسانس دارند و بخش قابل‌ملاحظه‌ای از مردم هم گوشی‌های تلفن همراه هوشمند دارند و کارکردن با آن را بلدند.
شما نمی‌توانید ده کشور در دنیا را پیدا کنید که پلتفرم خدمات شهری مثل «تهران من» داشته باشند، پلتفرمی که چهارمیلیون یوزر داشته باشد، تنوعی از سرویس‌ها را ارائه بدهد، سیستم payment (سیستم پرداخت) آن آنلاین باشد و امثالهم. البته یک دلیل آنکه ما اینجا با سهولت بیشتری می‌توانیم چنین پلتفرمی داشته باشیم این است که ما یک‌سری از محدودیت‌ها یا شاید بگویم رگولیشن‌هایی مثل Visa و Master را که سایر جاهای دنیا دارند نداریم. ما در اینجا یک سیستم بانکی داریم، کیف پول راه می‌اندازیم، و دستمان در software بازتر است چون کپی‌رایت نداریم. ولی بههرحال چیزی مثل «تهران من» با این معماری و مدلی که دارد و شما می‌توانی اطلاعات عوارض شهرداری خانه‌ات را ببینی، ترددت را ببینی، payment خودت را ببینی، می‌توانی در آن بلیت بخری و از این کارها نمونه‌های مشابه زیادی ندارد و خیلی‌ها وقتی آن را می‌دیدند تعجب می‌کردند. می‌پرسیدند همهچیز آنلاین است؟ مثلاً فلان چیز را هم می‌توانی ببینی؟
حالا کشورهایی مثل آمریکا را باید استثنا کنیم. هرچند در همان آمریکا هم سرویس برنامه‌های کاربردی شهریِ زیادی وجود ندارد. از آن‌طرف مثلاً دُبی بود که در حوزهٔ دولت الکترونیک از ما خیلی جلوتر است و پلتفرم خدمات شهری‌اش با فاصلۀ زیاد از ما پیشرفته‌تر بود و سرویس‌های خیلی زیادی را روی همین پلتفرم آورده بود، ولی البته تعداد یوزرهایش ۳۰۰-۴۰۰هزار نفر بود -در زمان ما این‌قدر بود، حالا بیشتر شده- ولی ما چهارمیلیون کاربر داشتیم؛ خب این را هم باید در نظر بگیریم. بههرحال، حداقل در آن مقطع، تعداد کشورهایی مثل دبی خیلی زیاد نبود. به همین خاطر، در مقام مقایسه با خیلی از کشورهای دیگر، استیت شهرداری تهران چندان بد نبود. مثلاً در دوربین‌های ترددی و پلاک‌خوانی، در مقایسه با شهری مثل بارسلونا، ما سه-چهار برابر یا حتی بیشتر دوربین پلاک‌خوان داشتیم که دیتایش به سیستم پلاک‌خوان می‌آمد. در بعضی بازه‌های زمانی ده میلیون تصویر را پردازش می‌کردیم؛ در بارسلونا این عدد یک‌دهم یا یک‌هشتمِ ما بود.
مصاحبه‌کننده: ده میلیون تصویر در روز؟
محمد فرجود: بله، ده میلیون در روز. البته در دورۀ کرونا کمتر شد، ولی ما بعضی روزها تا ده میلیون تصویر پلاک را پردازش می‌کردیم. سطح کار و حجم کار خیلی زیاد بود. خب یکی از دلایلش این است که تهران بزرگ است. تهران جزء چند شهر اول بزرگ جهان است. بعضی شهرها الان در اسمارت سیتی بِرند شده‌اند، ولی اگر بررسی کنید می‌بینید پانصد هزار یا یک‌میلیون نفر جمعیت دارند. با یک‌میلیون نفر جمعیت هر کاری می‌شود کرد، ولی با ده میلیون نفر نمیشود همۀ آن کارها را کرد، چون اصلاً سطح پردازش و دیتایی که باید جمع کنید و خطوط شبکه‌ای که باید به همه‌جای شهر بکشید از لحاظ عددی خیلی متفاوت است. پس وقتی می‌خواهید شهرها را مقایسه کنید، scale (مقیاس) مقایسه هم مهم است.
نکتۀ دیگر اینکه کار برای یک شهر جدید راحت‌تر است تا کار برای شهرهایی مثل تهران که مثلاً به‌محض اینکه برای کابل‌کشی بروید زیر زمین، یا لولهٔ آب می‌ترکد یا لولهٔ گاز، بنابراین در آن مقطع که ما وضعیت شهرداری تهران را با بقیهٔ شهرداری‌های دنیا مقایسه می‌کردیم، و وقتی در این مقایسه بقیۀ مسائلی که در کشور داشتیم را هم لحاظ می‌کردیم، به این نتیجه می‌رسیدیم که وضع شهرداری تهران به نسبت شهرهای دیگر دنیا بهتر است. البته قبل از آن مقطع هم همین‌جور بود. الان را نمی‌دانم.
خب برویم سراغ کارت بعدی، تعویض سامانۀ قراردادها. منظور از این کارت چیست؟
مصاحبه‌کننده: اگر اشتباه نکنم، سال ۹۸ سامانۀ قراردادها کلاً کنار گذاشته شد و یک سامانۀ جدید به اسم سامانهٔ جامع معاملات جایگزین آن شد. این اتفاق در شرایطی افتاد که، غیر از شهرداری‌های مناطق و ستاد، سامانهٔ قراردادها در حدود ۷۰ درصد از سازمانها و شرکت‌های زیرمجموعهٔ شهرداری هم راهاندازی شده بود.
محمد فرجود: نه، این‌طوری که نبود، ولی یادم هست که یک تغییر داشتیم، یعنی تا یک جایی رفتیم جلو و بعد مجبور شدیم سامانه را تغییر دهیم. تیم دیگری، غیر از آن تیمی که سامانۀ جامع مالی را نوشته بود، این سامانه را نوشته بود و ما آن سامانه را در واحدهای مختلف راهاندازی کرده بودیم ولی به سامانۀ جامع مالی متصل نمی‌شد. یعنی در integration سامانه‌ها به مشکل خوردیم. بعد از چندین بار رفت‌وآمد، وقتی مشکل حل نشد، درنهایت در سازمان تصمیم گرفتیم که کار توسعهٔ سامانهٔ قراردادها را به همان تیمی بسپاریم که سامانۀ مالی را نوشته بود. تا جایی که می‌دانم درمورد این تصمیم و changeای که اتفاق افتاد چالش زیادی وجود داشت. در خاطرم هم نیست که تیم جدید آیا کارشان را کلاً از ابتدا شروع کردند یا نه، ولی چون تیم قبلی بخشی از راه را رفته بود، احتمالاً تیم جدید هم همان را ادامه داده است.
ببینید، ما در سازمان مدام از این جنس تصمیمات می‌گرفتیم. مثلاً دو تا تیم داشتیم که هر کدام می‌خواستند کار تازه‌ای که راه افتاده بود را بگیرند؛ جلسه می‌گذاشتیم و تصمیم می‌گرفتیم که فلان تیم فلان کار را دولوپ کند و آن‌یکی کار دیگری را. فکر می‌کنم دربارۀ موضوع مدنظر شما هم به همین ترتیب بود، یعنی ما کار سامانهٔ قراردادها را از یک تیم داخلی به یک تیم داخلی دیگر دادیم. حالا یادم نیست که سامانهٔ جدید را مجدداً از ابتدا نوشتند یا نه؛ زمان زیادی گذشته، حدود چهار-پنج سال.
یک دلیل تغییر تیم‌ها شاید این بود که در سازمان، بخش‌ها و زیربخش‌هایمان را عوض کردیم، یعنی تصمیم گرفتیم که یک تیم فقط مسئول سامانههای مالی، قراردادها، و حقوقی باشد، یک تیم مسئول سامانههای حملونقل، یک تیم مسئول سامانههای فرهنگی و حوزۀ خدمات شهری (یعنی نیازمندی‌های دو معاونت را پاسخ دهد)، یک تیم هم مسئول شهرسازی، و مواردی اینچنینی. احتمالاً این تغییرات بر تصمیم به انتقال کار سامانهٔ قراردادها از یک تیم به تیم دیگر تأثیر گذاشته باشد. البته آن سامانه احتمالاً از نظر فنی هم مشکلاتی داشته که باید بازنویسی می‌شده یا از اول طراحی می‌شد. از این موارد زیاد داشتیم، مثلاً درمورد خود سامانۀ منابع انسانی، وقتی من به سازمان آمدم به من گفتند که در سه-چهار سال اخیر، این بار چهارمی است که این سامانه را نوشته‌ایم. نمی‌خواهم این را بگویم که نباید از روز اول سعی کرد با حواس جمع تصمیمی را گرفت که در ادامه نیازی به تغییر آن نباشد، اما هرچقدر هم سعی کنید تصمیم درست را بگیرید، بالاخره ممکن است به نقطه‌ای برسید که لازم باشد تصمیم دیگری بگیرید و تصمیم قبلی‌تان را override (لغو و بازنویسی) کنید.
ما خیلی جاها تصمیمی می‌گرفتیم و بعد می‌دیدیم که نمیشود، اشتباه کرده‌ایم و باید برگردیم و از مسیر دیگری برویم تا بتوانیم حتماً کار را انجام دهیم و این بهتر از آن است که کار را بلاتکلیف بگذاریم. توجه داشته باشید که کارهای زیادی در سازمان فاوا بود که در رودربایستی، بلاتکلیف مانده بود. مثلاً ما می‌پرسیدیم این سامانه چیست؟ می‌گفتند ما در یک سازمان راه‌اندازی‌اش کرده‌ایم ولی در بقیۀ بخش‌ها چندان پیاده‌سازی نشد. بعد می‌پرسیدیم متولی آن کیست؟ چه کسی پیگیر آن است؟ چرا در بخش‌های دیگر راهاندازی نشده؟ می‌گفتند ما وظیفه نداریم برویم آن را در همۀ بخش‌های شهرداری راهاندازی کنیم، وظیفۀ ما فقط این است که آن را توسعه دهیم. الان هم شهرداری هر موقع دستور دهد، می‌رویم آن را در بخش‌های دیگر هم راهاندازی می‌کنیم. از این موارد زیاد بود، بنابراین ما هم تا حدی نقشمان را تغییر دادیم؛ به خود شورا یا به معاونت‌ها می‌گفتیم فلان کار مربوط به اسمارت سیتی است، یک اجازۀ حکومتی می‌گرفتیم و کار را انجام می‌دادیم.
خلاصه اینکه بله، ممکن است ما در مواردی تصمیم گرفته باشیم که کاری را که خودمان انجام داده‌ایم از لحاظ فنی، معماری و این‌ها مجدداً بررسی کنیم. مثلاً تا جایی که یادم می‌آید، معماری و طراحی بک‌اِند «تهران من» را، همانطور که این پلتفرم بزرگ‌تر می‌شد و سرویس‌های جدیدی روی آن می‌آمد و به مشکلات جدیدی برمی‌خوردیم، سه یا چهار بار عوض کردیم چون توسعهٔ چنین پلتفرمی خیلی ظرافت دارد، حجم زیادی دیتا می‌آید و ممکن است بخش‌هایی از آن با بقیه سازگار نباشد و کل پلتفرم دچار اختلال شود و از کار بیفتد. تا یک جایی سعی می‌کردیم با بهبود همان محصول موجود مشکلات را رفع کنیم، ولی از یک جایی به بعد می‌دیدیم دیگر نمیشود، باید تغییراتی اساسی در محصول ایجاد کنیم و کل کار را یک ورژن ارتقا دهیم. ایجاد چنان تغییراتی خیلی زحمت داشت ولی وقتی سیستم توسعهٔ محصول پویا باشد، این تغییرات را می‌پذیرد و در خودش هضم و حل می‌کند. اتفاقاً سیستمی که پویا نباشد به مسائل و مشکلاتی که در حین کار پیش می‌آید واکنش نشان نمی‌دهد و ترجیح میدهد کلیت محصول به همان صورت باقی بماند. بنابراین من مشکلی در این نمی‌بینم که بعضی جاها از تصمیمات قبلی‌مان برگشته باشیم و آن را اصلاح کرده باشیم.
مصاحبه‌کننده: لطفاً فرایند گرفتن تصمیمی مثل تعویض سامانهٔ قراردادها را یک مقدار توضیح دهید. شما مدیرعامل سازمان فناوری بودید و قاعدتاً خودتان پشت سیستم نمی‌نشستید که کد بزنید و خودتان از منظر فناورانه و دانش طراحی نرم‌افزار به ماجرا ورود نمی‌کردید، ولی درنهایت مسئولیت برخی از این تصمیماتِ ناظر به تغییرات با شما بود.
محمد فرجود: این تصمیمات اکثراً بهصورت تیمی گرفته می‌شد. ببینید، ما در سازمان یک‌سری کمیته داشتیم که راجع به مسائل مختلف در آن کمیته‌ها تصمیم می‌گرفتیم. علاوه بر آن، در برخی موارد تقسیم‌کار هم کرده بودیم، مثلاً درمورد نرم‌افزار بیشتر خود آقای مقصودلو همراه با معاون نرم‌افزار تصمیمات را می‌گرفتند و فقط در صورتی که لازم بود، موضوع روی میز من می‌آمد. معمولاً هم همیشه تصمیمات بهصورت دسته‌جمعی گرفته می‌شد، یعنی معاونان مربوطه حضور داشتند و بعضاً مشاوران ما هم می‌آمدند، خودمان هم بودیم، بعد pros & cons (جوانب مختلف مثبت و منفی) موضوع را بررسی می‌کردیم تا به تصمیم برسیم. من اصولاً معتقدم که در عصر ما پارامترهای تصمیم‌گیری برای موضوعات آنقدر زیادند و شرایط آنقدر به‌سرعت عوض می‌شود که هنر یک مدیر آن است که بتواند، در عین اینکه نگاه استراتژیک دارد، دائماً تصمیمات مختلف بگیرد و حتماً هم این کار را انجام دهد و تصمیم‌گیری را معلق نکند. پیشتر هم گفتم که سرعت تصمیم‌گیری در سازمان خیلی زیاد بود. ما هر روز باید دربارۀ مسائل فراوانی تصمیم می‌گرفتیم، حتی اگر دیتای ما برای تصمیم‌گیری کامل نبود. البته این‌طور نبود که بدون فکر و شتاب‌زده تصمیم بگیریم، ولی بههرحال گاهی مسائلی وجود دارد که باید همین امروز راجع به آنها تصمیم بگیرید. در خیلی از موارد هم به همین ترتیب بود: همکارانِ سازمان تحلیل را می‌آوردند و دربارۀ منابعشان، معماریِ کار، ظرفیت‌هایشان و اینکه تیم‌ها مشغول کدام پروژهها هستند و اینکه الان خودمان می‌توانیم کار را انجام دهیم یا باید برون‌سپاری کنیم توضیح می‌دادند. یا مثلاً، ضمن توضیح دربارۀ معماری پروژه، و ذکر این نکته که می‌دانیم بهتر است یا می‌توانیم معماری جدیدتری بنویسیم، می‌گفتند چون این کار به ده تا مسئلۀ دیگر متصل است و الان فرصت کافی نداریم، بنابراین اگر با همان معماری قبلی آن را بنویسیم کار سریع‌تر پیش می‌رود. حالا ما باید تصمیم می‌گرفتیم که بر اساس این پارامترهای مختلف با حرفشان موافقت کنیم یا نه.
پارامتر دیگر نیروی انسانی بود. مثلاً می‌دیدیم الان تیم لازم برای فلان کار را نداریم، یا آن تیم در حال حاضر مشغول کار دیگری است، بنابراین مجبوریم کار را عقب بیندازیم و مثلاً برویم با معاونت شهرسازی مذاکره کنیم و توضیح دهیم که من که الاستیک نیستم که بتوانم در آنِ واحد ده تا کار را انجام بدهم و دقیقاً فردای همان روزی که دستور می‌دهید، آن هم با آن شرایط شهرداری، بروم ده تا نیرو از بیرون به کار بگیرم. اگر هم بخواهم برون‌سپاری کنم، بالاخره کارهای مربوط به فراخوان و قرارداد و مناقصه و چیزهایی از این قبیل مثلاً دو ماه زمان می‌برد. بنابراین یا باید صبر کنید، یا باید اجازه دهید تا ما ظرفیت ایجاد کنیم. ظرفیت هم به‌شکل دستوری و در یک چشم‌به‌هم‌زدن ایجاد نمیشود.
به‌طور کلی فرایند تصمیم‌گیری به این شکل بود که معمولاً با تیم‌های خودمان مشورت می‌کردیم و اگر لازم بود مشورت خارجی هم می‌گرفتیم. ولی مهم این بود که سعی می‌کردیم به هر صورتی که هست تصمیم بگیریم و نمی‌گذاشتیم تصمیمات خیلی معلق بمانند، ولو اینکه بعداً لازم بود تصمیم را به هر دلیلی عوض کنیم، مثل اینکه می‌فهمیدیم تصمیم اشتباهی بوده و به نتیجه نمی‌رسد، یا اصلاً اشتباه هم نبوده ولی تا یک جایی از مسیر را پیش می‌رفتیم و می‌دیدیم از یک جایی به بعد دیگر امکان پیشروی نیست. از این موضوعات زیاد داشتیم، حتی درمورد خود افراد؛ فرض کنید مثلاً مدیر یکی از پروژههای ما پیشنهاد کاری می‌گرفت و می‌رفت. حالا باید کارش را می‌دادیم به یک تیم دیگر، و تا آن تیم جدید روی کار مسلط شود و راه بیفتد مدتی طول می‌کشید و یک‌سری مشکلات پیش می‌آمد. از این موارد زیاد پیش می‌آمد.
یک بار با خانم آروین هم صحبت می‌کردیم، و ایشان معترض بود که چرا درمورد فلان مسئله به این شکل تصمیم‌گیری شده است. من به ایشان گفتم این قبیل مسائل خیلی زیاد است و اصلاً کار من و سازمان همین تصمیم‌گیری‌هاست. مضاف بر اینکه من مدیرعاملم و نباید در همۀ موارد دخالت کنم. یک‌سری تصمیم‌گیری‌ها کار معاون است. مثلاً وقتی در معاونت نرم‌افزارِ من صدوپنجاه تا سامانۀ کوچک و بزرگ وجود دارد، معاون مربوطه به‌طور مداوم دارد درمورد این‌ها تصمیم می‌گیرد، ادلۀ خودش را می‌گوید و توضیح میدهد که هر کسی را مسئول چه بخشی کرده و کدام کارها را چون فرصت کافی ندارد باید برون‌سپاری کنیم یا از این پیمانکار بگیریم و بدهیم به آن‌یکی. اتفاقاً در خیلی از موارد هم نتیجۀ کار خوب از کار درمی‌آمد، مثلاً یک پیمانکار آمده بود کاری را انجام داده بود و ما به ذهنمان می‌رسید که برای انجام کاری دیگری هم مناسب است. کار را به او می‌دادیم و بعد هم می‌دیدیم نتیجه خیلی خوب از کار درآمد، درحالیکه شاید روز اول به آن فکر نکرده بودیم. خلاصه اینکه طبیعتاً متناسب با اقتضای زمان و شرایط و منابعمان تصمیم می‌گرفتیم.
مصاحبه‌کننده: تصمیماتی را که در سازمان می‌گرفتید، وقتی می‌بردید به سطوح بالاتر یا درواقع به معاونت‌های مربوطه، آیا به‌راحتی و بدون چالش پذیرفته می‌شد؟
محمد فرجود: بعضاً ممکن بود سؤال و چالشی پیش بیاید. من در پاسخ می‌گفتم بالاخره سازمان فاوا برای شما در حکم solution provider (ارائه‌دهندهٔ راه‌حل) است و باید یک جاهایی هم به آن اعتماد کنید تا ما بتوانیم ابزارهای خودمان را جابه‌جا کنیم یا ترکیب‌هایمان را عوض کنیم. در مواردِ خیلی حساس طبیعتاً آنها را در جریان می‌گذاشتیم یا با آنها مشورت هم می‌کردیم، که زیاد هم پیش می‌آمد. مثلاً من با خود معاون‌ها هم مشورت میکردم. اصلاً در حوزهٔ شهرسازی، تیم شهرسازی ما آنقدر با معاونت شهرسازی کار کرده بودند که دیگر خودشان جزء معاونت شهرسازی به حساب می‌آمدند، و گاهی راجع به نحوهٔ سازماندهی نیروهای شهرسازیِ خودمان از معاونت مشورت می‌گرفتیم و نظراتشان را اعمال می‌کردیم. مثلاً می‌گفتند شخصی ده سال با ما کار کرده، پس بگذاریدش سر آن یکی پروژه که مهم‌تر است. منظورم این است که با معاونت‌ها تعامل می‌کردیم و این‌طور نبود که بگوییم همین است که ما می‌گوییم، یا بگوییم ما یک شرکت بیرونی هستیم و شما هم شهرداری هستید، بنابراین هر کاری دلمان بخواهد می‌کنیم. بااینحال این تصمیمات فنی core کار ما بود و اگر کسی می‌پرسید چرا فلان کار را کردید، از تصمیمات فنی خودمان دفاع می‌کردیم و این هم طبیعی است، چون بالاخره وقتی روی صندلی مدیریت می‌نشینید و مسئولیت کاری را می‌پذیرید، باید کارها را به‌نحوی پیش ببرید.
ممکن است هر کسی از بیرون بگوید چرا فلان سامانه را عوض کردی یا چرا فلان سامانه از این پیمانکار گرفته شد و به آن پیمانکار داده شد و از این شرکت رفت به آن شرکت. در این شرایط باید دلایلتان را توضیح بدهید، ولی درنهایت یکی از شاخص‌های عملکردی شما این است که کارها انجام شود. بعضی مواقع من این‌طور با معاونت‌ها توافق میکردم که به آنها می‌گفتم شما نگران نباشید، نهایتش این است که من تیمم را چند روز بیشتر نگه می‌دارم تا کارشان را مطابق استانداردهای خودمان و ددلاین مورد انتظار شما به شما تحویل دهند، ولی بالاخره ما باید ملاحظات و استانداردهای خودمان را در کاری که انجام می‌دهیم لحاظ کنیم و اگر تصمیم ما این بوده که کار را از آن تیم بگیریم و بدهیم به این تیم، یا تصمیم ما این بوده که فلان پلتفرم عوض شود و پلتفرم دیگری جایگزین آن شود، باید این کار را بکنیم تا بعداً به مشکل جدی‌تری برخورد نکنیم. به آنها می‌گفتم بالاخره این تصمیم سازمان است و اصلاً وظیفۀ سازمان همین است که چنین تصمیماتی را بگیرد.
کارت بعدی، کنارگذاشتن پروژۀ ZRM[20]. منظورتان از این کارت چیست؟
مصاحبه‌کننده: کمیتهٔ شفافیت خیلی به‌دنبال ارتقادادن سامانههای ۱۳۷ و ۱۸۸۸ -یا به تعبیر کمیته، سامانههای نظارت همگانی- بود تا ثبت پیام و پیگیری گردش کار در این سامانه‌ها بهبود یابد. سازمان فاوا ارتقای این سامانه‌ها را ذیل پروژهٔ ZRM یا همان پروژۀ درگاه واحد تماس شهروندی، که یکی از پروژههای شهر هوشمند هم بود، تعریف کرده بود اما از یک جایی به بعد به کمیتهٔ شفافیت گفته شد که این پروژه کنار گذاشته شده است.
محمد فرجود: بگذارید ابتدا توضیح دهم که ایدهٔ پشت پروژهٔ ZRM چه بود. اگر شهرداری را یک سازمان یا شرکت در نظر بگیریم، در هر سازمان تیم‌های مختلفی وجود دارد مثل تیم فنی، تیم فروش و تیم بازاریابی. اما علاوه‌براین‌ها باید یک بخش امور مشتریان هم وجود داشته باشد. شهرداری امور مشتریان متمرکز نداشت. نزدیکترین چیز به بخش امور مشتریان در شهرداری سامانهٔ ۱۳۷ بود که مدیریت آن در اختیار سازمان بازرسی بود.
آن اوایل ما پیشنهادی برای یکپارچه‌کردن درگاه تماس شهروندان با شهرداری و یکی‌کردن همهٔ سرشماره‌ها به سازمان بازرسی ارائه دادیم که طرح جالبی بود. اسم پروژه‌اش را ZRM گذاشتیم. برای آن مناقصه برگزار شد و یکی از شرکت‌های شرکت‌کننده در مناقصه برنده شد. در ادامه، خود سازمان بازرسی این‌قدر در طرح اولیه دست برد و گفت این قسمت یا آن قسمتش نباشد که عملاً پروژه را از بین برد. ما هم دیگر از اجرای پروژهٔ یکی‌کردن مرکز تماس‌ها ناامید شدیم چون هم با سازمان بازرسی به جمع‌بندی نرسیدیم و هم دیدیم که جز سازمان بازرسی، بخش دیگری در شهرداری نیست که بتواند متولی این پروژه باشد؛ یعنی پروژه بدون متولی شد. البته ما بخشی از کارهایی که در پروژه می‌خواستیم انجام دهیم را در قالب «تهران من» به نتیجه رساندیم تا کاربر، برای دسترسی به خدمات الکترونیکی شهرداری، مجبور نباشد در چند درگاه لاگین کند و یک‌سری دیتاها یکپارچه شود. از جمله اینکه ثبت پیام ۱۳۷ و ۱۸۸۸ را هم روی «تهران من» آوردیم و زیرساخت آن را هم کلاً عوض کردیم و بهصورت کال‌سنتر درآمد. پس یکپارچه‌کردن درگاه دریافت خدمات شهروندی تا حد خوبی انجام شد، اما کارهایی مثل ایجاد مرکز تماس یکتا را دیگر نتوانستیم انجام دهیم. دلیل اصلی‌اش هم این بود که آن کار متولی نداشت و دغدغهٔ کسی نبود که همۀ این سرشماره‌ها، یا حداقل یک‌سری از آنها که ضرورت دارد، یکی شود.
کارت بعدی، حذف اطلاعات ایمنی ساختمان از سایت شفاف.
خب، ما در تصمیمی که آن موقع درخصوص این اطلاعات گرفته شد مسئولیتی نداشتیم.
مصاحبه‌کننده: بالاخره شما یک node (مرحله) فرایند انتشار و حذف اطلاعات بودید.
محمد فرجود: بله، همۀ کارهای فنی‌اش را ما کردیم. چند مرحله تیم جی‌آی‌اس ما با سازمان آتش‌نشانی اطلاعات مربوط به ساختمان‌ها از قبیل زمان ساخت، سن ساختمان و نظایر آن را جمع کرد. فرم‌های الکترونیکی ارزیابی ایمنی را طراحی کردیم و در اختیار سازمان آتش‌نشانی گذاشتیم. دیتای اولیه‌ای که آتش‌نشانی به ما داد خیلی بی‌کیفیت بود. آن را به خودشان برگرداندیم و گفتیم اصلاحش کنید. ازآنجاکه این پروژه جزء کارهای تهران هوشمند ما هم بود، چندسری از آتش‌نشانی پیگیری کردیم و حتی در چند تا از جلسات شورای معاونان شهرداری موضوع را مطرح کردیم تا این دیتاها تکمیل شد. اینجا دو مسئله وجود داشت، یکی تجمیع دیتاها بود و دیگری انتشار آنها. به سازمان آتش‌نشانی تکلیف شده بود که ساختمان‌ها را درجه‌بندی کنند؛ پرخطر، کم‌خطر، ایمن. بعد این درجه‌بندی را به ما بدهند و ما درجۀ ساختمان‌ها را روی جی‌آی‌اس ببریم.
ما این کار را خیلی جدی پیگیری کردیم و به انجام رساندیم. البته خب طبیعتاً فقط می‌توانستیم روی آن دیتایی که به ما دادند، که همان هم حجم زیادی داشت، کار کنیم چون جمع‌آوری دیتا در اختیار ما نبود؛ آتش‌نشانی باید ساختمان‌ها را شناسایی و اطلاعات ایمنی آنها را در فرمی که ما به‌شکل سیستمی درست کرده بودیم وارد می‌کرد. اطلاعات واردشده می‌آمد روی سِل و پارسل خودش در نقشهٔ تهران می‌نشست. همۀ این کارها انجام شد. اما درمورد انتشار این دیتاها، در خود شهرداری -اگر اشتباه نکنم در حراست- بحث شد که این موضوع امنیتی است. می‌گفتند اینکه ساختمان‌های پرخطر را اعلام کنیم می‌تواند آنها را تارگت خرابکاری کند. یادم هست از این مرحله بود که کار با مشکل مواجه شد، واِلّا همه‌چیزِ ما آماده بود. یعنی روزی که ما خروجی کار را بهصورت آزمایشی نمایش دادیم، اگر یک کلیک می‌زدیم اطلاعات ساختمان‌ها روی نقشهٔ تهران پابلیش می‌شد.
مصاحبه‌کننده: پس درنهایت حراست شهرداری با انتشار عمومی اطلاعات مخالفت کرد؟
محمد فرجود: فکر می‌کنم حراست بود ولی شاید جاهای دیگری هم بودند. دغدغه‌شان همان مسئله‌ای بود که گفتم و البته از منظر خودشان لزوماً دغدغۀ اشتباهی نبود. می‌گفتند اگر گریدبندی ساختمان‌ها را به این شکل ارائه کنیم و به‌خصوص اگر پرخطرها را اعلام کنیم، خودش می‌شود تارگت خرابکاری. اتفاقاً این بحث‌ها حول‌وحوش همان زمانی بود که بیمارستانی در تهران آتش گرفت.[۲۱] حرفشان این بود که اگر کسی بخواهد خرابکاری و شیطنت کند و مثلاً بمبی کار بگذارد، اعلام ساختمان‌های پرخطر کار را برایش آسان می‌کند. بنابراین به نظرم اتفاقی که افتاد این بود که مجموعهٔ شهرداری و شورا به جمع‌بندی نرسیدند که ابعاد ریسک انتشار عمومی اطلاعات چقدر است و چه پیامدهایی خواهد داشت. حتی فکر می‌کنم یک بار هم اطلاعات را پابلیش کردیم و بعد به ما گفتند که اطلاعات را حذف کنیم.
مصاحبه‌کننده: چه کسی به شما گفت اطلاعات را بردارید؟
محمد فرجود: تصمیمی بود که در جلسه گرفته شد. فکر کنم جلسه در سطح شورای معاونان بود و شهردار هم حضور داشت و مفصلاً دربارهٔ این موضوع بحث شد و بعد هم دستور عدم انتشار آمد. یعنی اصلاً این‌طوری نبود که اتفاق پنهانی‌ای افتاده باشد. اتفاقاً با جدیت هم از حرفشان دفاع می‌کردند. فکر کنم سازمان مدیریت بحران شهرداری هم با آنها هم‌عقیده بود که اگر این اطلاعات را اعلام کنیم، تبعاتی دارد و ساختمان‌های ناایمن تارگت خرابکاری می‌شوند. درنهایت جمع‌بندی این شد که دیتاها را از روی سایت برداریم، و ما هم برداشتیم. البته به خود شهرداری همۀ دیتاها را دادیم و کار خوبی هم از کار درآمد. بعداً از آن تجربه برای طراحی مجدد سیستم ممیزی املاک[۲۲] استفاده کردیم که یکی از کارهای سختی بود که انجام دادیم.
ممیزی املاکِ قبلی تماماً بهصورت دستی و کاغذی انجام شده بود؛ ممیزها برای هر ملک یک فرم کاغذی پر می‌کردند، بعد این فرم‌ها را به شهرداری منطقه می‌بردند و اطلاعات آن را بهصورت دستی وارد سیستم می‌کردند. برای ممیزی پنجم، این فرایند به گمانم پنج سال طول کشیده بود و آخر سر هم نتیجۀ دقیق و کاملی حاصل نشده بود. مثلاً یک بار در آماری که از آن گزارش شد، اعلام کردند که ۴۰ یا مثلاً ۶۰ درصد از املاک شهر تهران استخر دارند که واضح بود این آمار غلط است. حالا این اعداد از کجا آمده بود؟ احتمالاً دلیلی شبیه به این داشته که مثلاً املاک استخردار عوارض کمتری پرداخت می‌کردند و بنابراین یک‌سری املاک بدون استخر را هم استخردار ثبت کرده بودند، یعنی دیتای خلاف واقع وارد سیستم کرده بودند. هیچ نظارتی بر فرایند ثبت داده نبود و حتی معلوم نبود واقعاً کسی برای بازدید ملک رفته است یا نه.
برای ممیزی ششم، من خیلی جنگیدم و تلاش کردم تا اجازه ندهم حتی یک برگه کاغذ در فرایند ممیزی استفاده شود و، به‌جای آن، همهچیز سیستمی و آنلاین باشد. خود این کار چهار سال زمان سِیو می‌کرد. آن سیستم قبلی هیچ‌وقت به خروجی موردنظر نرسیده بود. حجم عظیمی از داده باید جمع‌آوری و در سیستم وارد می‌شد -برای هر ملک، سیصد-چهارصد آیتم اطلاعاتی ثبت می‌شد. مضاف بر اینکه اصلاً معلوم نبود ممیز واقعاً به ملک مراجعه کرده است یا نه. ما علاوه بر حذف کاغذ، کلی قاعده و ضابطه چیدیم تا از درست‌انجام‌شدن کار مطمئن شویم. مثلاً جی‌پی‌اس ممیز را در منطقهٔ مأموریتش قفل می‌کردیم؛ یا به هر ممیز یک آی‌دی بارکد دوبعدی می‌دادیم که صاحب ملک می‌توانست آن را اسکن کند و مطمئن شود که شخص مراجعه‌کننده مأمور شهرداری است. اطلاعات ممیزی املاک باید دست‌آخر در دیتابیس سامانهٔ شهرسازی می‌نشست و دیتابیس سامانهٔ شهرسازی هم سنگین بود. فرایندی طراحی کردیم که اطلاعاتی که در فرم‌های الکترونیکی وارد می‌شود، بدون ایجاد مشکل در سامانهٔ شهرسازی، در دیتابیس این سامانه بنشیند. تازه این اتفاق بعد از آن می‌افتاد که ناظران و مسئولان ذی‌ربط، ثبت اطلاعات را approve می‌کردند. قبلاً یک ساختار عریض و طویل برای خودشان طراحی کرده بودند که در همۀ مناطق شهرداری ساختمان‌هایی را در اختیار بگیرند؛ فرم‌هایی که مأموران ممیزی پر می‌کنند آنجا ماشین شود؛ بعد یک‌سری افراد در اتاق‌های دیگری این‌ها را تأیید کنند، و …. برای این کار می‌خواستند دو هزار نفر را استخدام کنند که ما گفتیم این کار لازم نیست. گفتیم همهچیز باید سیستمی باشد، و نیازی هم به دراختیارگرفتن ساختمان جدید نیست. ناظران می‌توانند در شهرداری‌های مناطق مستقر شوند و از همان‌جا فرم‌ها را در کامپیوترشان ببینند و تأیید کنند. تنها چیزی که باقی ماند بحث آن مأمورانی بود که باید به منازل شهروندان مراجعه می‌کردند.
این طرحی که ما ریختیم به بحث ممیزی املاک محدود نماند و ما نیازمندی‌های سازمان آتش‌نشانی، نیازمندی‌های سازمان بوستان‌ها برای ممیزی درخت‌ها و خیلی چیزهای دیگر را به آن add کردیم. حرفمان این بود که اطلاعات مختلفی که واحدهای مختلف شهرداری باید از املاک شهر جمع‌آوری کنند بهصورت یک‌جا گرفته شود، نه اینکه هر واحدی بهصورت جداگانه برود و اطلاعات را از شهروندان جمع‌آوری کند. خیلی طرح خوبی از کار درآمد، هرچند نمی‌دانم درنهایت عملیاتی شد یا نه. اما واقعاً به‌رغم همۀ بحث‌ها و چالش‌ها مصوب شد که هیچ چیزی کاغذی نباشد؛ همهچیز باید روی تبلت ثبت شود و مستقیماً هم برود روی سیستم. بعد هم lock (قفل) شود، یعنی وقتی مأمور فرم را پر می‌کند، دیگر نه خودش و نه هیچ کس دیگری نتواند چیزی را عوض کند. هر عملیاتی هم که در سیستم انجام شود، لاگ آن گرفته شود. علاوه‌براین‌ها، کارهای دیگری هم انجام دادیم، مثلاً برای مأموران ممیزی route planning (برنامه‌ریزی مسیر حرکت) درست کردیم که وقتی مأمور مثلاً باید ده تا ملک را ببیند، بداند از کجا برود به کجا.
خلاصه در بحث data gathering (جمع‌آوری داده) ممیزی املاک سعی کردیم مشابه کاری را انجام دهیم که با همکاری سازمان آتش‌نشانی برای جمع‌آوری دیتای ایمنی ساختمان‌ها انجام داده بودیم. ولی خب چالش اصلی در انتشار اطلاعات بیشتر امنیتی و امنیت شهری بود. من به‌شخصه می‌گفتم که اگر این اطلاعات را منتشر کنید بهتر است و مسئولیت از گردن شما برداشته می‌شود. درمورد تبعاتش هم استدلالم این بود که اگر کسی بخواهد خرابکاری کند، اطلاعات بیشتری نسبت به آنچه منتشر می‌شود دارد ولی به هر ترتیب شاید جسارتش نبود یا می‌ترسیدند که تبعات انتشار خیلی جدی باشد. فکر می‌کنم شورای فعلی هم مجدداً راجع به این موضوع بحث کرده است.
مصاحبه‌کننده: انتشار اطلاعات ایمنی ساختمان‌ها؟
محمد فرجود: بله. چندین بار فکر کنم دربارۀ آن بحث شده است. هم موافقانی دارد، هم مخالفانی.
مصاحبه‌کننده: لیستی هم در خبرگزاری‌ها منتشر شد.
محمد فرجود: بله. درنهایت یک خروجی‌ای ارائه دادند.
مصاحبه‌کننده: یکی از دوستان ما که داده‌های این لیست را چک می‌کرد میگفت این دادهها همان داده‌هایی است که در دورهٔ قبل گردآوری شده است.
محمد فرجود: بعید نیست، چون کار جدید انجام نشده است.
مصاحبه‌کننده: فکر می‌کنید دلایل یا انگیزه‌های دیگری پشت این استدلالی که در مخالفت با انتشار اطلاعات ایمنی ساختمان‌ها مطرح می‌شد وجود داشت؟
محمد فرجود: نه، به نظرم نبود. چون اتفاقاً به نفع شهرداری بود که این اطلاعات را منتشر کند؛ در صورت انتشار، آن بخشی از شهرداری که در قبال فروریختن ساختمان‌ها باید پاسخگو باشد در جواب می‌توانست بگوید من مکرراً به مالک اعلام کرده‌ام و ابلاغیه زده‌ام -همانطور که دربارۀ پلاسکو اتفاق افتاد. چون پیش از هر جای دیگری به شهرداری میگویند تو چرا به موضوع ایمنی این ساختمان که اوضاعش این‌قدر خراب است ورود نکرده‌ای. با انتشار اطلاعات، اگر حادثه‌ای برای یک ملک ناایمن اتفاق می‌افتاد شهرداری می‌توانست بگوید این ابلاغیه‌ها موجود است و به مردم هم وضعیت این ساختمان را اعلام کرده‌ام. تازه انتشار اطلاعات می‌توانست با ایجاد فشار عمومی باعث شود که مالک برود و ایرادات ایمنی ملکش را درست کند. به نظرم ذات انتشار اطلاعات ایمنی ساختمان‌ها اتفاق بدی نبود.
مصاحبه‌کننده: درمورد ساختمان‌های باارزش این‌طور می‌گفتند که انتشار اطلاعات ایمنی ممکن بود ارزش اقتصادی این ساختمان‌ها را تحت تأثیر قرار دهد -ارزش آن را کم کند- و دلیل واقعی مخالفت با انتشار اطلاعات چنین موضوعی بوده است.
محمد فرجود: ممکن است این هم باشد. ولی بسیاری از این‌ها ساختمان‌های دولتی بودند.
مصاحبه‌کننده: کارت آخر.
محمد فرجود: تبدیل شهرداری مرکز به میانی. این چیست؟
مصاحبه‌کننده: در بحث امضای الکترونیک، گویا ایدۀ سازمان فاوا این بوده که، به‌جای استفاده از خدمات شرکت‌هایی که زیرساخت امضای الکترونیک و سند الکترونیک ارائه می‌دهند (مراکز میانی)، خود شهرداری این زیرساخت را توسعه دهد.
محمد فرجود: بله، این پیشنهاد مطرح بود. ایده این بود که برای ارائه خدمت به خودمان و حتی به سایر شهرداری‌ها، مجوز مرکز میانی بگیریم. یعنی ایده‌مان محدود به شهرداری تهران نبود و گفتیم مرکزی باشد که به همۀ شهرداری‌ها سرویس دهد. پیش‌بینی ما این بود که در سال‌های آینده، به تعداد زیادی امضای دیجیتال برای سرویس‌های شهرداری‌ها نیاز هست و این امضاها یک‌سری شرایط خاص دارند که خوب است مرکزی مختص همین حوزه وجود داشته باشد. عملی هم بود.
بانک مرکزی هم می‌خواست کار مشابهی در حوزهٔ بانک‌ها کند. البته کیس بانک مرکزی پیچیدگی‌های بیشتری داشت چون بانک مرکزی میگفت من زیرنظر وزارت صمت نمی‌آیم -متولی بحث امضای الکترونیک در کشور مرکز توسعهٔ تجارت الکترونیکی است که ذیل وزارت صمت قرار دارد. خلاصه یک اختلاف‌نظری بین آنها وجود داشت که درنهایت وزارت صمت برندۀ آن بحث شد و سیاست ارائهٔ مجوز مرکز میانی هم به سمت محدودسازی رفت -خب وزارت صمت هم رگولاتور این حوزه است و حق دارد در این خصوص تصمیم بگیرد- و الان به گمانم تعداد مراکز میانی بیشتر از چهار-پنج تا نباشد. ما هم دیگر از گرفتن مجوز مرکز میانی منصرف شدیم.
مشابه ایدهٔ ایجاد مرکز خاص برای شهرداری‌ها را در حوزه‌های دیگری مثل اتصال به جی‌اس‌بی[۲۳] دولت هم داشتیم. دولت یک زیرساخت تبادل خدمات الکترونیکی به اسم جی‌اس‌بی دارد که قرار است تمام خدمات و استعلامات سازمانهای دولتی از یکدیگر از طریق آن انجام گیرد. یک پی‌جی‌اس‌بی[۲۴] هم دارد که مخصوص سرویس‌دادن به سازمانهای بیرون از دولت و بخش خصوصی است. خیلی از سازمانهای دولتی بزرگ مثل ثبت‌احوال، پلیس، برخی بانک‌ها و شهرداری تهران به جی‌اس‌بی متصل هستند. ما جزء اولین سازمان‌هایی بودیم که به جی‌اس‌بی وصل شدیم تا سرویس‌هایی را که پیش از آن باید بهصورت مستقل از سازمان مربوطه می‌گرفتیم، مثل سرویس ثبت‌احوال که از سازمان ثبت‌احوال می‌گرفتیم، از جی‌اس‌بی بگیریم. خود ما هم سرویس‌های زیادی روی جی‌اس‌بی به بخش‌های دیگر می‌دادیم.
به‌مرور تعداد سرویس‌گیرندگان از جی‌اس‌بی زیاد شد و شهرداری‌های شهرهای دیگر هم گفتند که ما هم مثلاً سرویس ثبت‌احوال را می‌خواهیم و می‌خواهیم احراز هویت افرادی که به شهرداری می‌آیند را انجام دهیم. دولت هم میگفت من ظرفیت این کار را ندارم که به دویست شهر روی جی‌اس‌بی سرویس بدهم و باید بروید از پی‌جی‌اس‌بی سرویس بگیرید. بعضی شهرداری‌ها سراغ من هم آمدند تا کمکشان کنم، چون دبیر کارگروه کلان‌شهرها بودم.
ما پیشنهاد دادیم که در کنار جی‌اس‌بی، یک گذرگاه دیگر، مثلاً سی‌اس‌بی[۲۵] راه بیندازند که مخصوص تبادل سرویس بین شهرداری‌ها باشد و همچنین تعدادی از سرویس‌های دولتی که مورد نیاز شهرداری‌هاست هم روی آن بیاید. این‌طوری دیگر لازم نبود همهٔ شهرداری‌ها به جی‌اس‌بی وصل شوند. هنوز هم به نظرم ایدۀ خوبی است، و شاید حتی ضروری باشد چون اگر تبادل داده و استعلامات کل سازمانهای دولتی و عمومی کشور بخواهد روی یک گذرگاه تجمیع شود، خودش یک bottleneck (گلوگاه) می‌شود و برای رفع آن باید کلی هزینه کنند. این در حالی است که ما موضوعات زیادی داریم که می‌توان در همین لوپ شهرداری‌ها حلشان کرد، یعنی یک service bus (گذرگاه خدمت) برای شهرداری‌ها باشد که آنجا اطلاعات و داده‌هایشان را تبادل کنند، وزارت کشور دیتاهایش را از آنجا بگیرد، و تعدادی از دولتی‌ها هم آنجا سرویس بدهند و هر شهر کوچک و بزرگی هم بتواند به آن وصل شود و لازم نباشد به جی‌اس‌بی وصل شود. اما این پیشنهاد در دستورکار قرار نگرفت. درنهایت پذیرفتند که تهران و مشهد روی جی‌اس‌بی بیایند و بقیهٔ شهرها را روی پی‌جی‌اس‌بی فرستادند.
مصاحبه‌کننده: تا اینجای مصاحبه، دربارهٔ برخی مطالبات کمیتهٔ شفافیت از شهرداری و به‌طور خاص سازمان فاوا صحبت کردیم و با جزئیات فرایند تصمیماتی که شما از جایگاه مدیرعامل سازمان فاوا باید می‌گرفتید آشنا شدیم. در اینجا من از شما می‌خواهم تا قدری بیشتردر رابطه با کمیته و نوع تعاملتان با آن صحبت کنید و در ادامه نقاط قوت و ضعف کمیته را برشمارید.
محمد فرجود: ببینید، طبیعتاً هرچقدر هم شما بخواهید جایگاه سیاست‌گذاری و نظارتی شورا را به شهرداری نزدیک کنید، دست آخر باز هم با دو نقش متفاوت مواجه خواهید شد. یعنی شما در قامتِ مدیر اجرایی با مسائل و ملاحظات فراوانی روبه‌رو هستید و، در این بین، حتماً باید یکی از پارامترهایتان تعامل با نهاد بالادستی باشد که ناظر و سیاست‌گذار است. ولی بههرحال، جنس نقش مدیر اجرایی با جنس نقش نمایندهٔ شورا فرق می‌کند. پس باید درک کرد که سیاست‌ها و استراتژی‌هایی که در نگاه کلان خوب هستند، وقتی به مرحلهٔ اجرا می‌رسند، لزوماً همانطور که باید باشند محقق نمی‌شوند.
درمورد کمیتهٔ شفافیت، با توجه به ترکیب اعضای این کمیته و نگاهی که خانم آروین داشت، ما در خیلی از موارد، آن همسویی و alignment (هم‌راستایی) لازم را داشتیم. حداقل من هم فکر میکردم که شفافیت خوب است. همچنین، این موضوع که کارها تا حد ممکن اتوماسیونی شوند طبیعتاً جزء هدف‌هایمان بود، اینکه تا حد ممکن، سامانه‌ها به هم متصل شوند و نقش آدم‌ها در فرایندها کم شود، دیتاها یکپارچه شوند و مردم سرویس‌های الکترونیکی را بهصورت یکپارچه دریافت کنند. نگاه ما و کمیتهٔ شفافیت در همهٔ این موضوعات به هم نزدیک بود و اگر این‌طور نبود، خیلی از کارهایی که انجام شد اصلاً نمی‌توانست پیش برود.
به نظرم نقطهٔ قوت کمیته نسبت به باقی کمیته‌های شهرداری پیگیریِ آنها بود، اینکه بیایی و با تیم اجرا بنشینی و پیشرفت کار و چالش‌ها و فراز و نشیب‌های آن را بهصورت جزئی دنبال کنی. خیلی از کمیته‌های شورا این‌گونه نبودند و یک‌سری کارهای نرمال و روتین نظیر تعیین‌تکلیف پرونده‌های باغات در آنها انجام می‌شد. ولی برعکس، پیگیری و درگیرِ کار بودن از نقاط قوت کمیتۀ هوشمندسازی بود. منتها، ما در بحث‌های اجرایی یک‌سری محدودیت و لیمیتیشن داشتیم؛ گاهی کار عقب می‌افتاد یا مثلاً کسی گفته بود کار را به شکل خاصی انجام دهیم و بعد مجبور به تغییر شکل کار و انجام دوبار‌هٔ آن می‌شدیم. در این مواقع، بین ما و کمیته اختلاف‌نظر پیش می‌آمد و بحث درمی‌گرفت که چرا کار پیش نمی‌رود.
از یک نظر کمیته حق داشت که معترض شود، چون ما در خیلی از موارد به ددلاین‌هایی که گفته بودیم نمی‌رسیدیم. به‌خصوص که سیستم پیگیری در کمیته خیلی دقیق بود؛ سر همان موعدی که قرارمان بود پیگیری می‌کردند و مثلاً می‌گفتند که سازمان فاوا قول یک ماه دیگر را داده بود، پس چرا محقق نشد؟ اما منِ مدیرعامل هم، به اعتبارِ حرف معاون این قول را داده بودم، و معاون هم به اعتبارِ حرف مدیرش چنین گفته بود و مدیر هم به اعتبارِ حرف کارشناسش. ولی خب ممکن بود اتفاق‌های مختلفی در این میان رخ دهد که کار آن‌طور که باید پیش نرود. هم از جانب ما ممکن بود یک‌سری مشکلات پیش آمده باشد و هم از جانب دیگر واحدهای متولی در شهرداری. مثلاً در خیلی از موارد پیش می‌آمد که من باید دستور از سمت کمیته را اجرا میکردم، ولی آن کسی در شهرداری که باید اجازهٔ اجرا را صادر می‌کرد حضور نداشت، یا نمی‌گذاشت و نمی‌شد. در این‌جور مواقع، بر سر اینکه چرا کار پیش نرفته دچار چالش می‌شدیم. البته ما هم دوباره می‌آمدیم و پیگیری می‌کردیم؛ این‌طور نبود که برویم بگوییم ببخشید دیگر، ما خواستیم کار را انجام دهیم اما نشد و تمام. درواقع نکته‌ام این است که تقریباً هیچ‌کدام از مسائل و اختلاف‌نظرهایی که بین ما و کمیته پیش می‌آمد ناشی از اختلاف‌های عمیق نبود. کارها بالاخره با دو ماه تأخیر -یا بعضاً بیشتر- انجام می‌شد.
به‌طور کلی من از پیگیری‌های کمیتهٔ شفافیت استقبال میکردم. یک بار هم در یکی از جلسات به خانم آروین گفتم که ما در یک‌سری موضوعات، از خواسته‌ها و مطالبات شما هم جلوتر رفته‌ایم، دیگر این‌قدر در جلسه از بچه‌های ما انتقاد نکنید. [می‌خندد] ولی نهایتش من استقبال میکردم که کسی غیر از خود ما هرازگاهی تیم‌های ما را صدا کند و بگوید باید این کار را می‌کردی، چرا نکردی؟ چون چنین پیگیری‌هایی باعث می‌شد تا متولی انجام پروژه پاسخگو باشد و به تعهداتی که داده است پایبند بماند. شما خودتان خانم آروین را می‌شناسید و می‌دانید که مدلش این‌گونه نبود که از ما تشکر کند. یک بار هم به شوخی به او گفتم لااقل اینهمه ایرادهای کارمان را می‌گویی، به کارهایی که انجام شده هم اشاره کن. [می‌خندد] حالا از شوخی گذشته، بله، خیلی وقت‌ها هم پیش می‌آمد که ایشان به کارهای انجام‌شده اشاره می‌کرد. ولی به‌خاطر آن کمالگرایی‌ای که در ایشان وجود داشت، نمرهٔ ما هیچ‌وقت ۱۰۰ نمی‌شد. می‌دانستیم هرچقدر هم کار انجام دهیم، باز ایشان ده تا کار دیگر را فهرست می‌کند که انجام نداده‌ایم. ولی نکته این بود که من مقاومتی نداشتم و در مقابل ایشان جبهه نمی‌گرفتم. ما سعی کردیم سازمان را هیچگاه بر مبنای سوگیری منفی نسبت به انتقادها اداره نکنیم. ولی تقریباً در هر جلسه‌ای که با کمیتهٔ شفافیت داشتیم، بالاخره این موضوع طرح می‌شد که فلان کارها عقب مانده است.
کمیتهٔ شفافیت درحوزهٔ قراردادها جلسات متعددی برگزار کرد. در این جلسات، ما می‌آمدیم، اداره‌کل مالی می‌آمد، اداره‌کل حقوقی می‌آمد، و همه باید درخصوص پیشرفت پروژه و چالش‌های آن پاسخگو می‌بودیم. من از این رویکرد یعنی برگزاری جلسه با حضور ذی‌نفعان مختلف استقبال میکردم. مثلاً در خیلی از کارها، ما به‌تنهایی نمی‌توانستیم بقیه بخش‌های شهرداری را در زمینه پیاده‌سازی سامانه‌ها هم‌راستا و همسو با خود کنیم. باید حتماً فورس از طرف شورا، حالا یا در قالب برگزاری جلسه یا مثلاً تماس مستقیم خانم آروین با شهردار یا راه‌های دیگر، می‌بود تا کار متوقف نماند. خیلی وقت‌ها خودم به خانم آروین می‌گفتم فلان کار الان رسیده به جایی که دیگر ما نمی‌توانیم با بقیهٔ واحدهای اجرایی تعامل داشته باشیم و نیاز است شما جلسهٔ مشترکی بگذارید تا همکاری کنند و وظایفشان را انجام دهند. می‌خواهم بگویم که وجود این جلسات به‌نظرم در ذاتش خیلی به پیشبرد کار کمک کرد و مسیری که خانم آروین و کمیتهٔ شفافیت در پیش گرفته بود درمجموع مسیر خوبی بود.
اما چطور می‌شد بهتر باشد؟ شاید اگر بخواهیم بلندمدت‌تر فکر کنیم، در ترکیب تیم کمیتهٔ شفافیت باید تعداد آدم‌های فنی که به حوزهٔ آی‌تی مسلط باشند بیشتر می‌بود؛ منظورم افراد فنیِ دولوپر نرم‌افزار نیست، بلکه کسانی که جنس توسعهٔ پروژههای نرم‌افزاری، و جنس تغییرات را در پروژههای دولتی که هزار تا پارامتر غیرفنی هم دارد، بشناسند. یعنی اگر افرادی با سابقهٔ جدی در بخش product development (توسعهٔ محصول) یا مدیریت محصول در ترکیب کمیتهٔ شفافیت حضور داشتند، شاید بهتر می‌توانستند حرف ما و حرف کمیته را برای هم translate (ترجمه) کنند. این در حالی بود که اکثر دوستان کمیته مدیریت یا رشته‌های دیگر خوانده بودند. شاید حضور افراد فنی می‌توانست لینک و ارتباط متقابل ما و کمیته را بهبود دهد.
مصاحبه‌کننده: درواقع منظورتان این است که انتظارات دو طرف را به هم نزدیک‌تر کند؟
محمد فرجود: بله دیگر. چون بالاخره پیش می‌آمد که ما به ددلاینی که اعلام کرده بودیم نرسیم یا کار را به شکلی جز آن شکل توافق‌شده انجام دهیم. برای همهٔ این‌ها هم دلایلی داشتیم، اما از نظر کمیته ما کم‌کاری کرده بودیم یا خلاف دستور عمل کرده بودیم. شاید اگر فردی از کمیته در کنار ما بود که می‌دانست ساختار شکست پروژه چیست، لیمیتیشن‌ها چیست، مسائلی که بین ما و کمیته پیش می‌آمد زودتر حل می‌شد و اصلاً لازم نمی‌شد که منِ مدیرعامل و خانم آروین و بقیهٔ اعضای تیم بخواهیم جلسهٔ مشترک بگذاریم که جمع‌بندی‌اش هم این باشد که نشدنی‌بودن توافقات اولیه از همان اول هم معلوم بوده است. بنابراین به نظرم حضور آدم‌های فنی می‌توانست به ما کمک کند.
مورد بعدی این است که به نظرم، شرکت‌نکردن خانم آروین در جلسات کمیتهٔ راهبردی تهران هوشمند، خود، موجب بروز چالشهایی می‌شد. درواقع من باید یک بار اعضای کمیتهٔ راهبردی را مجاب میکردم و بعد مجبور بودم همین کار را جداگانه در جای دیگری انجام دهم. البته در این رابطه، خانم آروین سیاست خودش را داشت. شاید هم حق داشت. میگفت شأن شورایی نباید با شأن اجرایی قاطی شود. بالاخره شهرداری سازمان اجرایی است و شورا سازمان نظارتی. البته الان که ما راجع به نسل جدید سیاست‌گذاری و G5 و تنظیم مقررات بهصورت مشارکتی و این‌گونه مفاهیم حرف می‌زنیم، می‌شد که آن مسائل را هم یک مقدار راحت‌تر گرفت. چه‌بسا اگر ایشان در جلسات شورای راهبردی حضور پیدا می‌کرد و نکاتش را در همان صحن جلسه میگفت، مسائل راحت‌تر حل می‌شد تا اینکه ما در جلسه حرف‌هایی بزنیم و تصمیماتی بگیریم و بعد شورا هم نظر خودش را بدهد و بگوید فلان کار را بکنید و دوباره از اول. بههرحال آن موقع، مناسبات بین شورا و شهرداری این‌گونه بود و موضوعی هم نیست که من خیلی صلاحیت اظهارنظر راجع به آن را داشته باشم.
درنهایت شاید مهمترین چالش مشترک ما موقعیت‌هایی بود که ما و کمیته با همدیگر در برابر قدرت‌های درون شهرداری نمی‌توانستیم کاری انجام دهیم، موقعیت‌هایی که معاون شهردار یا مدیران پایین‌تر از او به دلایل مختلف با کارهای مدنظر ما موافق نبودند یا آن حدی از change را که ما می‌خواستیم نمی‌خواستند ببینند. البته خب خیلی از مدیران شهرداری قدیمی بودند. این‌طور نبود که بگوییم همه تجددخواه و تغییرگرا بودند؛ نه، یک‌سری کارها سختشان بود. مثلاً باید ده تا جلسه با آنها می‌گذاشتیم تا بالاخره بتوانیم به یک جمع‌بندی برسیم و بعضی وقت‌ها هم نمی‌شد به جمع‌بندی رسید. لزوماً نمی‌توانستیم ذهن افراد را تغییر دهیم. خلاصه یک جاهایی با جمع‌شدن پاوِر کمیته و سازمان فاوا روی همدیگر هم کار پیش نمی‌رفت. به همین دلیل برای ارزیابی نتیجهٔ کارِ ما باید ببینید ظرف همان سه یا چهار سال چه کاری امکان‌پذیر بود. مثلاً موضوع املاک را ما خیلی پیگیری کردیم. در موضوع املاک، قدرت‌های زیادی درگیر بودند و پرسش این بود که آیا آنها می‌گذارند همهچیز را شفاف کنی یا خیر. یعنی در آخر، در خیلی از پروژهها، ما و کمیتهٔ شفافیت هم‌نظر بودیم، ولی طرف‌های دیگر نه.
مصاحبه‌کننده: آن طور که من فهمیدم، موضوع شهر هوشمند هم اولویت شما بود و هم اولویت کمیته. آیا همان‌قدر که کمیته روی شفافیت تمرکز داشت شما هم این تمرکز را داشتید؟
محمد فرجود: بله، ما که برنامه جدی‌مان بود.
مصاحبه‌کننده: آیا هنوز هم بعد از پایان تجربهٔ دورهٔ قبل فکر می‌کنید تمرکز بر موضوع شفافیت کار درستی بود یا اساساً باید روی موضوع دیگری تمرکز می‌شد؟
محمد فرجود: برای ما که وظیفه‌مان بود و درست هم بود. از نظر من، همۀ شهرداری‌های دنیا باید به این سمت پیش بروند، به طوری که در هر شهرداری واحدی مسئول حرکت به سمت هوشمندشدن و تحول دیجیتال در حوزهٔ مدیریت شهری شود. اصلاً گریزی از این کار نیست. ما هم در دورهٔ قبل سعی کردیم نقش سازمان فاوا را بازتعریف کنیم، به‌گونه‌ای که سازمان بتواند نقش راهبری شهرداری به سمت هوشمندشدن را بپذیرد. این کار آسانی نبود و ۱۰۰ درصد هم اجرایی نشد. اصلاً دلیل اینکه ما سازمان را ذیل دفتر شهردار آوردیم همین بود. بماند که بعدتر یکی از اعضای شورا آمد و گفت یعنی چه که یک سازمان برود ذیل دفتر شهردار. من گفتم نظر من این است که سازمان فاوا با همهٔ سازمانهای دیگر فرق می‌کند، چون این سازمان قرار است شهرداری را تغییر دهد. به همین خاطر بگذارید سازمان همچنان ذیل شهردار بماند و اگر کسی هم خواست این جایگاه را تغییر دهد، دورهٔ‌بعدی‌ها باشند. حداقل شما این را عوض نکنید. گفتند نه، سازمان فاوا باید برگردد ذیل معاونت برنامه‌ریزی. گفتم بسیار خب، بالاخره این شما هستید که تصمیم می‌گیرید، بروید و ساختار را عوضش کنید. البته این موضوع برای من چندان فرقی نمی‌کرد، چراکه من، حتی وقتی سازمان فاوا ذیل دفتر شهردار نبود هم، کارهایم را با شهردار چک میکردم و پیش می‌بردم.
درمجموع می‌خواهم بگویم تمرکز بر شهر هوشمند ذاتاً نه‌تنها اشتباه نبود، بلکه می‌توانست خیلی بیشتر و بهتر از این هم باشد. یعنی اگر مثلاً آن تیم اجرایی شهرداری که تقریباً دو سال آخر دوره در زمان آقای حناچی تشکیل شد از روز اول می‌بود، شاید پروژه خیلی سریع‌تر پیش می‌رفت، چون ما بالاخره با آقای حناچی و آقای مظاهریان به تعامل و همفکری مناسبی رسیدیم. این ترکیب دو سال به‌طور واقعی با هم کار کردند. قبل از آن ما چالش‌های زیادی داشتیم؛ تا آمدیم با تیم آقای نجفی به تعامل برسیم ایشان رفت. بعد از آن، تیم آقای افشانی آمد که آن هم تغییر کرد و در آخر، تیم آقای حناچی. این تغییرات انرژی ما را خیلی گرفت. با اینکه آقای نجفی خودش به موضوع شهر هوشمند خیلی علاقه‌مند بود و رابطهٔ خیلی خوبی با هم داشتیم ولی تیم او تیمی نبود که از آن اسمارت سیتی دربیاید. بههرحال، من اصلاً در این موضوع شک ندارم که اگر قرار باشد چیزی شهرداری را نجات بدهد همین حرکت به سمت برقراری اسمارت سیتی است؛ اسمارت سیتی نه به‌عنوان یک پروژه، بلکه به‌عنوان یک کانسپت. در این تعریف، نقطهٔ شروعِ شهر هوشمند، حکمروایی هوشمند است، یعنی اول باید بروی ببینی حکمرانی شهری چطور انجام می‌شود و از کجا شروع می‌شود. حکمرانی شهری از شورای شهر و شورای معاونان شهردار و از این سؤال شروع می‌شود که این شوراها چقدر درست تصمیم‌گیری می‌کنند. می‌خواهم بگویم اگر کانسپت اسمارت سیتی درست درک شود، دیگر موضوع فقط تمرکز بر تکنولوژی و ابزار و این حرف‌ها نیست. در اسمارت سیتی، همهچیز باید بر محور شهروند باشد. واقعاً الان چنین است؟ چقدر همین الان نظر شهروندان را در اجرای کارها اعمال می‌کنند؟ از این حیث، فاصلۀ ما با دنیا بیشتر هم شده است.
موضوع اسمارت سیتی ترند روز دنیاست. الان موج تحول دیجیتال، دیجیتال‌شدن و هوشمن شدن در همۀ حوزهها به وجود آمده است. ما الان داریم روی مفهوم Industry 4.0[26] کار می‌کنیم که راجع به هوشمندشدن صنایع است. همهٔ صنایع دارند عوض می‌شوند، همه دارند هوشمند می‌شوند، تکنولوژی‌های جدید دیجیتالی و هوش مصنوعی می‌آید و اصلاً شما گریزی از این تحولات ندارید. حالا شما ممکن است دولتی باشی، و برای خودت نشسته باشی یک جا و خودت را تغییر ندهی. ولی یک روز، طوری که متوجه نشوی، موجی می‌آید و تو را برمی‌دارد و با خودش می‌برد. این اتفاق همین الان هم افتاده؛ در شهرداری هم کم کم دارد این نیاز احساس می‌شود چراکه دیگر درآمدها و هزینه‌های آنها با یکدیگر همخوانی ندارد. اینجا شما مجبور می‌شوی سازمانت را تغییر دهی؛ سازمانت باید agile (چابک) شود، کوچک‌تر شود، به سمت استفاده از ابزارهای جدید برود، داده‌هایش مرتب‌سازی شود و قس‌علی‌هذا. به نظرم افتادن در این مسیرْ انتخابی نیست، بلکه اجباری است. ولی خب حالا در دورۀ جدید این موضوعات خیلی فهم نمیشود. اما چه کار می‌توانیم بکنیم؟
مصاحبه‌کننده: البته منظور من این بود که حتی در شرایطی که همه به شفافیت باور داریم و می‌دانیم راه درستی است و در آن مسیر هدف‌گذاری می‌کنیم، ممکن است درعمل ببینید که مسیرش خیلی طولانی است و اول باید موانع زیادی را از سر راه برداشت و بعد به فکر شفاف‌شدن دادهها افتاد.
محمد فرجود: یک نکته را باید در نظر بگیریم. به نظرم نباید این مسائل را با هم اشتباه گرفت. شفافیت یک کانسپت است، و این یک استراتژی است که من سعی کنم به سمت شفاف‌شدن بروم. بااینحال خود شفافیت فقط یک تکه از پازل خیلی بزرگ چیزی مثل شهر هوشمند یا تحول دیجیتال است. به نظرم قبل از هر چیز باید ببینیم تعریف ما از ابعاد شفافیت چیست. معنای شفافیت این نیست که همه از همۀ دیتاها مطلع باشند؛ دیتای شخصی را نباید همه بدانند، دیتای محرمانه را همه نباید بدانند طبیعتاً. تعریف من از شفافیت این است که مردم، به‌موقع، به اندازۀ لازم و در جای درست، درمورد آنچه در یک سازمان بزرگ اتفاق می‌افتد اطلاعات داشته باشند، مثلاً دربارۀ اینکه فرایند شهرسازی چیست و ضوابط چیست اطلاع داشته باشند. ولی وقتی شما مثلاً چندهزار نقش و وظیفه در شهرسازی داری، باید دکترا داشته باشی تا متوجه شوی برای تخریب یک ملک چه کارهایی می‌شود کرد و چه کارهایی نمیشود کرد. در شهرسازی تعدد قوانین وجود دارد. حالا هرچقدر هم که بخواهید این‌ها را مکتوب کنید، اصلاً تبدیلش کنید به کتاب، باز هم چیزی نخواهد شد که عموم افراد بتوانند آن را بفهمند. منظورم این است که یک بُعد شفافیت هم ساده‌کردن قوانین است. بله، مسیر این شفافیت مهم است، ولی شفافیت فقط منحصر در این نیست که یک سازمان را ترنسفورم کنید به سمت یک چیز جدید و متفاوت، یعنی فقط بروید و آن سازمان را شفاف کنید. به نظرم در خیلی از موارد شفافیتْ خروجیِ یک پروژه است، نه خود پروژه. یعنی اگر در مسیر data driven (داده‌محور) وهوشمندکردن یک سازمان حرکت کنید، یکی از بای‌پروداکت‌ها و خروجی‌ها این است که موضوعات مختلف مربوط به آن سازمان برای مردم شفاف‌تر می‌شود. چطور؟ مثلاً شما به مردم می‌گویید برای اینکه کارهایتان در شهرداری را انجام دهید، لازم نیست به دفتر من مراجعه کنید. همۀ قوانین و مراحل داخل سامانه قابل‌دسترسی است؛ از همان داخل خانه، دکمه را می‌زنید، اطلاعات را بارگذاری می‌کنید و کار تمام می‌شود. خب این یعنی فرایند شفاف‌تر شده است.
برای رسیدن به این خروجی، باید از قبل پلن کنید، ذهن آدم‌ها را عوض کنید. مهمترین لازمهٔ چنین کاری از نظر من این است که واقعاً خواهان تغییر باشید. من خیلی نشانه‌ای از این تغییرخواهی در دورهٔ جدید نمی‌بینم.
مصاحبه‌کننده: اگر نکتۀ پایانی دارید بفرمایید.
محمد فرجود: امیدوارم این حرف‌ها بتواند برای بقیه کمک‌کننده باشد؛ چه شکست‌ها و چه تجربه‌ها و چه موفقیت‌ها، امیدوارم ترکیب این‌ها به بقیه کمک کند. ما عادت داریم که وقتی در سازمانی مسئولیت می‌گیریم، اولین حرفمان این باشد که قبلی‌ها کاری نکرده‌اند و اوضاع چقدر بد و خراب است. همه یاد گرفته‌ایم برای کِرِدیت خودمان بگوییم که با درنظرگرفتن چیزِ خرابی که تحویل گرفته بودیم، عملکردمان خیلی خوب بوده است. این فایده ندارد. اصولاً من معتقدم که هرچه تحویل گرفته‌ای مهم نیست، هنر این است که بروی ببینی خودت چه کار می‌کنی. حالا امیدوارم این نگاه موجود در شهرداری تهران هم انشاءالله تغییر کند، چون اوضاع کنونی خوب نیست. به گمانم اکثر سرویس‌هایی که داشتیم، همۀ آن مواردی که در این گفتوگو راجع به آن حرف زدیم، استاپ شده است. تصور کنید سی-چهل پروژه بود که بهصورت هفتگی پیگیری می‌شد و الان دو سال است که کسی آنها را پیگیری نکرده است. زمان ما، برای «تهران من» یک رودمَپ داشتیم و تقریباً ماهی نبود که دو سرویس به «تهران من» اضافه نشود. حتی می‌خواستیم قابلیت نمایش امتیاز شهروندان را هم به آن اضافه کنیم. اما الان همان سرویس‌های قبلی هم یکی‌درمیان کار می‌کند.
مصاحبه‌کننده: آیا شما و تیمی که در دورهٔ فعلی به شهرداری و سازمان فاوا آمدند جلساتی با هدف انتقال دانش و تجربه و تحویل‌دادن و گرفتن کار با هم داشتید؟
محمد فرجود: بله، خیلی زیاد. من قبل از آنکه به‌طور کامل از سازمان فاوا بیرون بیایم، حدود چهار ماه همراه تیم جدید ماندم، چون واقعاً دلم می‌خواست انتقال تجربه صورت بگیرد. وگرنه همان روز اول راحت می‌توانستم بیایم بیرون. خیلی هم سعی کردم که در این چهار ماه، انتقال دانش و تجربه اتفاق بیفتد و تا حدی هم که می‌شد منتقل کردم -بعد از من هم تیم من ماندند و عوض نشدند. ولی درنهایت آن کسی که در صدر کار است تصورات و برنامۀ دیگری دارد.
ببینید، آقای حناچی معمار بود و واقعاً در آی‌تی تخصصی نداشت، سروکارش هم هیچ‌وقت با این مسائل نبود. ولی ایشان چند ویژگی مهم داشت: اول اینکه اعتماد می‌کرد و میگفت من اگر در فلان حوزه تخصص ندارم، متخصصش را گذاشته‌ام تا کار را انجام دهد؛ دوم اینکه وقتی موضوعی مطرح می‌شد، گوش می‌کرد و سعی می‌کرد با آن ارتباط برقرار کند و آن را بفهمد. ادلۀ ما را گوش می‌کرد و واقعاً هم از ما حمایت می‌کرد. درواقع من هیچ‌وقت احساس نکردم که در کاری که داریم می‌کنیم حمایت ایشان را نداریم. این خیلی کمک می‌کرد. الان اوضاع به این منوال نیست. الان موضوعاتی مثل شهر هوشمند دغدغه نیست؛ اما برای ایشان دغدغه بود، و مثلاً اگر چهارتا برنامۀ مهم داشت، یکی از آنها شهر هوشمند بود. البته بهادادن به شهر هوشمند برایشان دستاورد هم داشت؛ ما در جایزه‌های جهانی رتبه می‌آوردیم، مردم فیدبک مثبت می‌دادند و ایشان هم بالاخره می‌توانست از خروجی کارها گزارش بدهد. الان این‌گونه نیست و شهرداری این دغدغه را ندارد که مثلاً مردم بگویند چقدر خوب که سرویس‌های شهرداری الکترونیکی شده و نیاز به مراجعهٔ حضوری نیست. در لایه‌های پایین‌تر سازمان فاوا هم به دلایل مختلفی کارها اجرایی نشده، مهم‌تر از همه به این دلیل که سازمان بی‌سامان بوده و بعد از یکسالونیم، تازه مدیرعامل حکم گرفته که امیدوارم بعد از این اتفاق اوضاع کمی بهتر شود.
مصاحبه‌کننده: در دورهٔ قبل اقدامی برای پایدارسازی کارهایی که در حوزهٔ فاوا و شهر هوشمند صورت گرفت انجام دادید؟
محمد فرجود: پایدارسازی از ابتدا دغدغۀ ما بود. به نظر من همین که «تهران من» هنوز پابرجاست و تا به حال از بین نرفته است به همین دلیل است. «تهران من» همین‌طور بزرگ و بزرگ‌تر می‌شد و یک جایی دیدیم که اصلاً نمیشود با مدل عادی مدیریتش کرد. مثل یک اپراتور اینترنت شده بود. مثلاً های‌وب و ایرانسل را در نظر بگیرید؛ چطور به شما سرویس می‌دهند؟ یک تیم آن پشت نشسته که جواب شما را میدهد، یک تیم دیگر محصول را develop می‌کند، یک تیم دیگر وظیفه‌اش فقط این است که این محصول، هرچه که هست، زنده بماند.
ما هم دیدیم «تهران من» به چنین چیزی تبدیل شده، یعنی یک عده باید دائماً دولوپ کنند، یک عده باید اینترفیس را درست کنند، یک عده باید حواسشان به عملکرد باشد. روزانه پانصدهزار نفر از اپلیکیشن استفاده می‌کردند و تعداد زیادی پرداخت از طریق آن انجام می‌شد و یک تیم باید حواسش به آنها می‌بود و تیم دیگری هم باید جواب مردم را می‌داد، حالا چه بهصورت تلفنی یا از طریق تیکت و راه‌های دیگر.
دیدیم دیگر نمیشود به همان منوال قبلی کار را مدیریت کرد. شهرداری یک ساختمان داشت که محل دانشگاه علمی-کاربردی شهرداری بود و آن موقع، در دورۀ کرونا، تعطیل شده بود. ما دانشگاه را به محل دیگری منتقل کردیم و آن ساختمان را به «تهران من» اختصاص دادیم. همهٔ تیم‌هایی که در «تهران من» کار می‌کردند و تا پیش از آن در بخش‌های مختلف سازمان فاوا پراکنده بودند -تیم payment، تیم حملونقل، …- را به آن ساختمان بردیم و در طبقات مختلف مستقر کردیم. در یک طبقه‌اش هم کال‌سنتر راه انداختیم. تیم «تهران هوشمند» هم در همان ساختمان مستقر بود. وقتی وارد آن ساختمان می‌شدید، می‌دیدید که کلاً با سیستم و فضای سازمان فاوا متفاوت است؛ رنگ همۀ درودیوارها شبیه استارتاپ‌ها بود و طراحی داخلی فضاهای کاری فِلَت بود. همهٔ افراد هم دولوپر نرم‌افزار بودند.
بعد از این انتقال، اتفاقات خوب زیادی افتاد؛ سرعت ما در توسعۀ سرویس، پاسخگویی به کاربران و بهبود خود اپلیکیشن خیلی ارتقا پیدا کرد و از نظر تعداد یوزر، تعداد تراکنش و تعداد سرویس با شیب خوبی در حال رشد بودیم. اما فکر کنم پنج-شش ماه بعد از اینکه من از سازمان بیرون آمدم، همۀ افرادی که روی «تهران من» کار می‌کردند را اخراج کردند، مدیرانش را از کار برکنار کردند، ساختمان را دادند به بخش دیگری در شهرداری و گفتند همهچیز برگردد به همان شکل قبلی. همهٔ دستاوردهایی که ایجاد شده بود را متوقف کردند. حالا چرا؟ چون می‌گفتند ما هر کاری در «تهران من» بکنیم به اسم قبلی‌ها تمام می‌شود. می‌خواهیم یک چیز دیگر درست کنیم به نام شهرزاد و این یکی باید تعطیل شود تا ما برویم سراغ آن. بعد هم رفتند قرارداد بزرگی با یک شرکتی بستند و آن هم یکسالونیم است که قرار است بیاید و چیزی به‌عنوان جایگزین «تهران من» بنویسد که دقیقاً هم عین همان باشد. البته او هم هنوز کاری نکرده و «تهران من» هم برقرار مانده. توجیهشان برای این کارها فقط همین بود که این «تهران من» متعلق به قبلی‌هاست. خب چه ایرادی دارد متعلق به قبلی‌ها باشد؟ چهارمیلیون یوزر دارند از «تهران من» استفاده می‌کنند. خب بیا از همین استفاده کن. هر کاری می‌خواهی بکنی از همین استفاده کن. به آنها گفتم که من طبق وظیفه‌ام تا اینجای کار را انجام داده‌ام، تحویل شما، از اینجا به بعد شما کار را جلو ببرید. ولی زیر بار نرفتند. اولش رفتند در این فاز که با تغییر ظاهر «تهران من»، مثلاً تغییر رنگ منوها و این‌ها، به کاربر این حس را بدهند که با محصول جدیدی طرف است. باور کنید پروژه تعریف کردند که حداقل ظاهر «تهران من» عوض شود که به اسم قبلی‌ها نباشد. ولی بعد به این تغییر ظاهر هم راضی نشدند و گفتند ما هر کاری در قالب «تهران من» انجام دهیم میگویند کار قبلی‌هاست. آن چیز دیگر هم که هنوز ایجاد نشده است. ساختار مدیریتی این یکی را هم متلاشی کردند. ما معاون داشتیم، بعد مدیر ارشد داشتیم و الی آخر. الان مثلاً مدیر ارشد را کردند کارشناس. مدیر ارشد حوزۀ ترافیک در «تهران من» که سال‌های سال کارش این بود و همۀ این پلاک‌خوانی‌ها و … را انجام داده بود و من هم از دورۀ قبلی او را آورده بودم را کردند کارشناس. این کارها معنادار است و به این معناست که من می‌خواهم هیچ چیزی از آن روال سابق باقی نماند.
حالا در انجام کار خودشان چقدر موفق بوده‌اند؟ دو سال گذشته و هیچ. بااینحال، همین که «تهران من» هنوز پابرجاست است تا حدی به‌خاطر محکم‌کاری‌های ما در دورهٔ قبل است. به‌علاوه، برخی سرویس‌های پرکاربرد و درآمدزا برای شهرداری را نمی‌توانند به‌راحتی دست بزنند، مثل سیستم وصول عوارض -عوارض ملک و راه و طرح ترافیک و …- که آن را اول در «تهران من» راه انداختیم، و بعداً ای‌پی‌آی بازش را هم ارائه کردیم. در این مورد خاص، هر کاری هم که بخواهند بکنند، حوزۀ مالی شهرداری اجازه نخواهد داد کسی خیلی به آن دست بزند چون شهرداری از طریق آن درآمد دارد. تا پیش از راه‌افتادن این سیستم، شهرداری برای وصول عوارض حاضر بود هر کاری بکند تا فرد عوارض را بدهد. کسانی بودند که به شهرداری پیشنهاد می‌دادند بدهی‌ها را وصول کنند و بخشی از آن را خودشان بردارند، یا اصلاً پیشنهاد می‌دادند که بدهی‌های شهرداری را از شهرداری بخرند و بعد بروند از سازمانهای بزرگ و سایرین وصول کنند و در این فرایند مثلاً چهل یا پنجاه درصدش را خودشان بردارند. هیچ راه دیگری هم برای شهرداری وجود نداشت. ما پیشنهاد کردیم که ای‌پی‌آی پرداخت عوارض و بدهی را در اختیار اپلیکیشن‌های دیگر مثل «آپ» و «تاپ» و «۷۲۴» و غیره بگذاریم؛ مردم از طریق این اپلیکیشن‌ها بتوانند بدهی‌های خودشان را ببینند، بدهی ملکشان، بدهی خودروشان، عوارض طرح ترافیکشان و همه را همان‌جا پرداخت کنند.
اجرای همین ایده، بدون اینکه هیچ الزام و جریمه‌ای اضافه شود، همهچیز را متحول کرد؛ شهرداری آنقدر از این طریق درآمد داشت که باورش نمی‌شد. سال آخر حضور ما، درآمد شهرداری و وصول مطالباتش در «تهران من» و سایر اپلیکیشن‌ها از سایر کانال‌هایی که پیش از این وجود داشت بیشتر شد و میزانش در حوزۀ ترافیک از همۀ حوزه‌های دیگر بیشتر بود. اصلاً باورشان نمی‌شد، چون تا پیش از آن چنین چیزی، یعنی کانال جدیدی که کارش وصول عوارض و مطالبات باشد، وجود نداشت. شهرداری به این راحتی‌ها نمی‌تواند به این بخش از سرویس‌های آنلاین دست بزند و مجبور است آن را به همان شکل سابق نگه دارد، چون پول لازم دارد. ولی حالا ممکن است خود اپلیکیشن «تهران من» و اسم و برندش را از بین ببرند.
مصاحبه‌کننده: سپاسگزارم.
محمد فرجود: موفق باشید.
[۱] open data
[۲] ای‌پی‌آی (Application Programing Interface) سرواژهٔ انگلیسی واسط برنامه‌نویسی نرم‌افزار است که به معنای استانداردی است که یک سامانهٔ نرم‌افزاری، طبق آن، با دیگر سامانه‌ها تبادل داده انجام میدهد.
[۳] منظور همان مرکز «ارتباطات و روابط بین‌الملل» شهرداری تهران است.
[۴] سازمان «بوستان‌ها و فضای سبز شهر تهران» ذیل معاونت «خدمات شهری و محیط‌زیست» شهرداری تهران. نام قبلی این سازمان «پارکها و فضای سبز شهر تهران» بوده است.
[۵] یکی از شرکت‌های ذیل معاونت «حملونقل و ترافیک» شهرداری تهران
[۶] شرکت واحد اتوبوسرانی تهران و حومه، ذیل سازمان «حملونقل و ترافیک» شهرداری تهران
[۷] User Experience: تجربهٔ کاربر
[۸] ای‌آرپی (Enterprise Resource Planning) سرواژهٔ انگلیسی مخفف برنامه‌ریزی منابع سازمانی است.
[۹] منظور کمیسیونی است بنا بر تبصرهٔ ۱ مادهٔ ۱۰۰ قانون «شهرداری»، مصوب ۱۳۳۴ با اصلاحات بعدی، تشکیل می‌شود. ترکیب اعضای این کمیسیون عبارت است از: نمایندهٔ وزارت كشور به انتخاب وزیر كشور، یكی از قضات دادگستری به انتخاب وزیر دادگستری، و یكی از اعضای انجمن شهر به انتخاب انجمن. وظیفهٔ این کمیسیون رسیدگی به موارد عملیات ساختمانی بدون پروانه یا مخالف مفاد پروانه است.
[۱۰] کمیتهٔ نما کمیسیونی است که بر مبنای تفاهم بین سازمان نظام مهندسی و معاونت معماری و شهرسازی شهرداری تهران از سال ۱۳۹۴ شکل گرفته و وظیفهٔ بررسی و صدور تأییدیهٔ نمای ساختمان‌ها را بر عهده دارد. اعضای این کمیته عبارت‌اند از: معاون شهرسازی و معماری شهرداری منطقه، کارشناس حوزهٔ شهرسازی و معماری شهرداری منطقه، نمایندهٔ اداره‌کل معماری و ساختمان، نمایندهٔ کمیسیون معماری و شهرسازی شورا، دو نفر از استادان صاحب‌نظر دانشگاهی به پیشنهاد مدیرکل معماری و ساختمان، یک نفر حرفه‌مند با تخصص معماری به پیشنهاد جامعهٔ مهندسان مشاور ایران.
[۱۱] نگاه کنید به business.tehran.ir
[۱۲] توکن (token) ابزاری سخت‌افزاری یا نرم‌افزاری است که در رمزنگاری و رمزگشایی اسناد و امضای دیجیتال، برای تأیید هویت افراد استفاده می‌شود و به ازای هر فرد حقیقی یا حقوقی تعریف می‌شود.
[۱۳] حامد مظاهریان، معاون «برنامه‌ریزی، توسعة سرمایه انسانی و امور شورا»ی شهرداری تهران از ۹۸ تا ۱۴۰۰
[۱۴] الآرتی (Light Rail Transit) سرواژهٔ انگلیسی مخفف قطار سبک شهری است.
[۱۵] automatic vehicle location tracking: ردیابی خودکار مکان وسیلهٔ نقلیه
[۱۶] سامانهٔ تدارکات الکترونیکی دولت (ستاد) بستر انجام الکترونیکی معاملات دولتی است که توسط مرکز توسعهٔ تجارت الکترونیک (ذیل وزارت صمت) راهاندازی شده است.
[۱۷] اسناد مربوط به تضمین
[۱۸] آی‌پی (Internet Protocol) سرواژهٔ انگلیسی مخفف پروتکل اینترنت است. پروتکل اینترنت نشانی عددی است که به هریک از دستگاه‌ها و رایانه‌های متصل به شبکهٔ رایانه‌ای که بر مبنای مجموعه پروتکل اینترنت کار می‌کند اختصاص داده می‌شود.
[۱۹] جی‌آی‌اس (Geographic Information System) سرواژهٔ انگلیسی مخفف سیستم اطلاعات مکانی است.
[۲۰] citiZen Relationship Management
[۲۱] حادثهٔ آتش‌سوزی در کلینیک سینا اطهر تهران در تیر ۹۹
[۲۲] بنا بر قانون «نوسازی و عمران شهری»، مصوب ۰۷/۰۹/۴۷ با اصلاحات و الحاقات بعدی، شهرداری‌ها موظف‌اند هر پنج سال نسبت به محاسبهٔ «بهای کلیهٔ اراضی، ساختمان‌ها و مستحدثات واقع در محدودهٔ قانونی شهر» اقدام نموده و بهای محاسبه‌شده را مبنای وصول عوارض قرار دهند.
[۲۳] جی‌اس‌بی (Government Service Bus) سرواژهٔ انگیسی مخفف گذرگاه خدمات دولت است.
[۲۴] پی‌جی‌اس‌بی (Public Government Service Bus) سرواژهٔ انگلیسی مخفف گذرگاه عمومی خدمات دولت است.
[۲۵] سی‌اس‌بی (City Service Bus) سرواژهٔ انگلیسی مخفف گذرگاه خدمات شهری است.
[۲۶] Industry 4.0 یا انقلاب صنعتی چهارم اصطلاحی است که به پیشرفتهای فناوری در قرن اخیر، از جمله هوش مصنوعی و رباتیک، و تأثیر آن بر حوزهٔ صنعت اشاره می‌کند.
