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

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

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

پروژه یا چرخه؟

پیش از آن‌که درباره عوامل موفقیت یا شکست معماری سازمانی صحبت کنیم، لازم است یک سوءتفاهم بسیار متداول را رفع کنیم، و آن خلط میان پروژه (Project) معماری و چرخه (Cycle) معماری است.

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

اما چرخه تغییر معماری سازمانی، یا به‌ اختصار چرخه معماری، از تعیین چشم‌انداز (فاز A) شروع می‌شود و با تحقق این چشم‌انداز (انتهای فازهای G و H) به انتها می‌رسد. به‌عبارت دیگر، هر چرخه معماری، با یک پروژه برنامه‌ریزی معماری شروع می‌شود، و با اجرای برنامه عملیاتی و تحقق چشم‌انداز به پایان می‌رسد.

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

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

عامل اول) چشم‌انداز معماری

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

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

هرگز پروژه معماری را بدون داشتن چشم‌انداز شروع نکنید. در غیر این‌صورت، خود را برای پایش و سنجش میزان موفقیت و شکست آن به دردسر نیاندازید!

عامل دوم) تعیین محدوده

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

برخلاف تصوری که به‌ویژه در بین تازه‌آشنایان با معماری سازمانی شایع است، چیزی به اسم «شرح خدمات تیپ» برای پروژه‌های معماری سازمانی وجود ندارد (با استثناهای معدود). محدوده هر پروژه‌ معماری سازمانی، پیش از شروع، یا در اولین مرحله اجرای آن باید برمبنای اهداف و دغدغه‌های ذی‌نفعان پروژه تدوین شود. در تعیین محدوده (Scoping) پروژه‌های معماری باید به چند سوال مهم پاسخ داده شود:

۱. چه محدوده‌ای از سازمان پوشش داده می‌شود؟ با آن که معماری سازمانی ذاتاً کل‌نگر و مربوط به همه سازمان است، همه محتوای مخزن معماری را نمی‌توان در یک پروژه تکمیل کرد. به‌همین دلیل انتخاب بخشی از سازمان که باید در پروژه پوشش داده شود، اهمیت دارد.

۲. تمرکز بر روی چه لایه‌های معماری است؟ مدل‌های معماری سازمانی معمولاً به همه لایه‌های معماری (کسب‌وکار، برنامه‌‌های کاربردی، تکنولوژی) مربوط می‌شوند و ارتباط این لایه‌ها را تحلیل می‌کنند، اما بسته به هدف پروژه، ممکن است تاکید و تمرکز بر روی همه لایه‌های معماری نباشد.

۳. چه مدل‌های معماری و با چه عمقی باید تهیه شود؟ مدل‌سازی معماری، کاری است پرهزینه، زمان‌بر و پرریسک. اگر دامنه یا عمق مدل‌سازی بیش از حد لازم تعیین شود، هزینه و زمان پروژه بی‌دلیل افزایش و احتمال موفقیت آن کاهش می‌یابد.

پاسخگویی به این پرسش‌های کلیدی، کاری است تخصصی که باید توسط مشاوران و کارشناسان زبده و کاردیده معماری سازمانی و با شناسایی و تحلیل اهداف و دغدغه‌های ذی‌نفعان و در نظر گرفتن محدودیت‌های زمانی و بودجه‌ای و تحلیل موازنه (trade-off) بین اهداف و محدودیت‌ها انجام شود.

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

عامل سوم) تکمیل تدریجی معماری

مخزن معماری (Architecture Repository) هر سازمان، پایگاه داده یا پایگاه دانشی است از اطلاعات مربوط به همه عناصر سازنده (building blocks) آن سازمان و ارتباطات بین این عناصر. تنها کسی که تازه با معماری سازمانی آشنا شده است ممکن است تصور کند همه محتوای این مخزن را می‌توان در یک پروژه تکمیل کرد. خطای مهلک سازمان‌هایی که در دهه ۸۰ در کشور ما اقدام به تعریف پروژه‌های معماری سازمانی می‌کردند (و متأسفانه هنوز هم بعضی سازمان‌ها این خطا را مرتکب می‌شوند،) این بود که همه مدل‌های معماری را از سیر تا پیاز، یعنی از مدل‌های کلان استراتژی سازمان گرفته تا جزئی‌ترین مدل‌های مربوط به شبکه و زیرساخت سازمان را در محدوده معماری تعریف می‌کردند. انگیزه اصلی ارتکاب این خطا این بود که تصور می‌کردند معماری سازمانی یک «پروژه» است که تنها یک بار می‌توانند آن را اجرا کنند و لاجرم در این یک بار باید همه مدل‌های معماری را تهیه کنند. برخی از سازمان‌ها هم فکر می‌کردند حالا که با گذر از هفت‌خوان فرآیند تعریف پروژه و مناقصه‌گذاری و انعقاد قرارداد، مشاوری انتخاب کرده‌اند، چه بهتر که تا می‌توانند این مشاور را به‌کارِ گل (مدل‌سازی) وادارند و به‌قول معروف، «از آب، کره بگیرند»! نتیجه: طولانی‌شدن بیش از حد پروژه‌ها، افزایش ریسک و هزینه آن‌ها و در نهایت شکست محتوم.

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

عامل چهارم) شروع از معماری استراتژیک

حال که نمی‌توان مخزن معماری را یکباره (یعنی در طی یک پروژه) تکمیل کرد، این سئوال مطرح می‌شود که: پس از کجا شروع کنیم؟ پاسخ متداول به این پرسش این است که از مهم‌ترین مسائل پیش‌روی سازمان. البته منظور مسائلی است که حل آن‌ها با کمک معماری سازمانی ممکن است. اما «مهم‌ترین مسائل پیش‌روی سازمان» کدام‌ها هستند؟ این پرسشی است که انتظار می‌رود پاسخ آن‌ها از حوزه استراتژی سازمان داده شود. به‌همین دلیل، چارچوب‌های متداول معماری سازمانی (از جمله توگف) پیشنهاد می‌کنند تکمیل مخزن معماری (یا به‌عبارت دیگر؛ نقشه‌راه توسعه معماری سازمانی) باید از سطح «معماری استراتژیک» شروع شود. بنابه روایت چارچوب توگف، این معماری با سه ویژگی زیر شناخته می‌شود:

۱. پوشش سازمانی: همه محدوده سازمانی را در برمی‌گیرد.

۲. افق زمانی: دوره نسبتاً طولانی را به‌عنوان چشم‌انداز سازمان، هدف‌گیری می‌کند.

۳. عمق مدل‌سازی: مدل‌های کلی و کلان، یعنی مدل‌هایی با عمق کم، در این معماری تولید می‌شوند.

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

عامل پنجم) نگهداشت معماری

همان‌طور که در یکی از یادداشت‌های قبلی خود اشاره کرده‌ام، بیشتر سازمان‌های ایرانی (احتیاط می‌کنم و نمی‌گویم: همه آن‌ها) با عارضه‌ای مواجه هستند که من اسم آن را «شوقِ ایجاد، ملالِ نگهداشت» گذاشته‌ام. یعنی این سازمان‌ها اشتیاق زیادی به ایجاد دارایی‌های فیزیکی و غیرفیزیکی و اجرای پروژه‌های مشاوره‌ای (به‌ویژه اگر موضوع این پروژه‌ها جدید و «مدِ روز» باشد!) دارند ولی به نگهداری و مراقبت و به‌ویژه بهنگام‌رسانی نتایج و دستاوردهای این پروژه‌ها، عنایت و اهتمامی ندارند. نتیجه این عارضه، انبوه پروژه‌های نوآورانه و تحولی است که در سازمان‌های ما اجرا شده ولی نتایج آن‌ها اجرا نشده و به‌قول معروف، سر از قفسه‌ها درآورده‌اند. پروژه‌های معماری سازمانی هم از این قاعده مستثنی نیستند و اگر سازمانی نتواند پروژه برنامه‌ریزی معماری سازمانی را به چرخه تغییر معماری تبدیل کند، تنها نتیجه‌ای که از این پروژه عاید سازمان می‌شود، مشتی مدل‌ معماری است. البته همین مدل‌ها هم دارایی ارزشمندی است که اگر امروز به کار نیاید، باری ممکن است فردا به دردی بخورد. به‌شرط آن‌که نظام نگهداشت مشخصی در سازمان وجود داشته باشد، که در نتیجه آن تغییرات معماری مستمراً در مدل‌ها منعکس شود. ما این نظام را «قابلیت مدیریت و راهبری معماری سازمانی» یا EAM/EAG می‌نامیم. قابلیتی که مثل بقیه قابلیت‌های سازمانی، نیازمند طراحی و استقرار و بهره‌برداری از سه بُعد ساختار، فرآیند و ابزار است. فاز Preliminary در متدولوژی ADM توگف برای پایه‌ریزی همین قابلیت پیشنهاد شده است.

عامل ششم) راهبری معماری

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

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