آسیب شناسی پروژه های برنامه‌ریزی فناوری اطلاعات

آسیب شناسی پروژه های برنامه‌ریزی فناوری اطلاعات

پروژه های برنامه ریزی فناوری اطلاعات، در مدت نسبتاً کوتاهی که از سابقه تعریف و اجرای آنها در کشور می گذرد، اغلب با مشکلات و چالشهایی روبرو هستند. برخی از چالشها ناشی از عوامل محیطی و پاره ای ناشی از ضعف عوامل اجرایی این پروژه هاست. در این مقاله، که برمبنای تجارب نگارنده در اجرای پروژه های برنامه ریزی فناوری اطلاعات در سازمانهای دولتی و خصوصی کشور، و با جمع بندی تجارب حاصل از اجرای این پروژه ها تهیه شده است، ابتدا معیارهای مــــوفقیت پروژه های برنامه ریزی فناوری اطلاعات برشمرده می شود، و سپس مهمترین چالشهای فراروی مجریان اینگونه پروژه ها تشـــــریح می گردد. در پایان نیز توصیه هایی برای مقابله با این مخاطرات و کاهش اثرات آنها ذکر می شود. ● زمینه با روند روزافزون توسعه فناوری اطلاعات درکشور ما، در سطــــح ملی و سازمانی که به افزایش سرمایه گذاری در توسعه زیرساختها و کاربردهای فنــــاوری اطلاعات در هر دو سطح منجــر شده است، تمایل فزاینده ای برای تعریف و اجرای پروژه های برنامه ریزی فناوری اطلاعـــــــات در سازمانها و موسسات دولتی وخصوصی کشور پدید آمده است. اینگونه پـــروژه ها که طیف نسبتاً وسیعی از برنامه ریزی سیستم های اطلاعاتی (ISP) تا تهیه طرحهای جامع و تدوین معماری سازمانی فناوری اطلاعات را دربرمی گیرند، سابقه طولانی درکشور ما ندارند و در مقــــایسه با پروژه های متعارف توسعه نرم افزار یا ایجاد زیرساخت، نسبتاً جدیدتر به شمار می روند. به همین نسبت نیز مشکلات بیشتری در تعریف، واگذاری، اجرا و پذیرش نتایج این پروژه ها در سازمانهای مختلف مشاهده می شود. بدبینی عمومی نسبت به پروژه های مشـــاوره ای و برنامه ریزی درکشور، که به این گونه پروژه ها عمدتاً به چشم فعالیتهای پرطمطراق «گزارش ساز» می نگرد، از یکسو، و عدم کفایت و صلاحیت برخی از مشاورانی که به انجام این پروژه ها مبادرت می ورزند، ازســـوی دیگر، نرخ موفقیت پروژه های برنامه ریزی فناوری اطلاعات را به شدت پایین آورده است. از این رو، شناسایی و تحلیل مخاطرات و مشکلات فراروی پروژه های برنامه ریزی فناوری اطلاعات هم برای مجریان و هم برای کارفرمایانی که قصد تعریف چنین پروژه هایی را دارند، بسیار ضروری است. بــــــرای آسیب شناسی پروژه های برنامه ریزی فناوری اطلاعات اصولاً دو رهیافت وجود دارد: اول رهیافت مطالعه تطبیقی مبتنی بر مطالعه میدانی پروژه های انجام شده و جمع بندی تجارب حاصل از آنها، و دوم مطالعه تحلیلی پروژه های انجام شده توسط هر مشاور برای درس گیری از تجارب موفق یا ناموفق. هرچند جای مطالعه ای از نوع اول در شرایط کنونی کشور ما خالی است(۱). اما دشواریهای طبیعی انجام چنین مطالعاتی ضرورت انتشار نتایج مطالعات نوع دوم را از سوی مجریان پروژه های برنامه ریزی فناوری اطلاعات آشکار می سازد. ● معیارهای موفقیت پیش از بررسی عوامل شکست پروژه های برنامه ریزی فناوری اطلاعات، باید ابتدا تعریفی از مـــوفقیت یا شکست این پروژه ها به دست دهیم. دیدگاههای سنتی درمورد موفقیت پروژه ها، بر سه عامل زمان، هزینه و کیفیت تاکید دارند. مطابق این تعریف، پروژه موفق پروژه ای است که در زمان تعیین شده و با هزینه پیش بینی شده به انجام رسیده و انتظارات اولیه از انجام پروژه را نیز برآورده سازد. در یک تقسیم بندی دیگر، پروژه های فناوری اطلاعات را می توان به سه دسته تقسیم کرد: الف) پروژه های موفق: پروژه هایی که در زمان تعیین شده، با هزینه پیش بینی شده و با کیفیت موردانتظار به اتمام می رسند؛ ب) پروژه های مشکل دار: پروژه هایی که به اتمام می رسند، اما ازنظر زمان، هزینه، کیفیت و یا هر سه جنبه با پیش بینی های اولیه تفاوت دارند؛ ج) پروژه های شکست خورده: پروژه هایی که هرگز به انتها نمی رسند. در دیدگاههای جدیدتر مدیریت پروژه، عــامل دیگری نیز به عنوان معیار موفقیت پروژه ها مطرح می شود، و آن میزان اثربخشی پروژه در درازمدت است. از دید برخی از صاحبنظران، ارزیابی موفقیت یا شکست یک پروژه تنها پس از گذشت زمانی بین ۳ تا ۵ سال پس از پایان پروژه ممکن می شود (۲). به عنوان مثال، موفقیت یک پروژه پل سازی در شهر، در افق کوتاه مدت تنها باتوجه به زمان، هزینه و دستیابی به مشخصات فیزیکی و ملموس پل ساخته شده قابل ارزیابی است، اما در درازمدت اثر این پروژه در اهداف کلان تری مانند روانسازی ترافیک شهر و... باید موردتوجه قرارگیرد. درمورد پروژه های برنامه ریزی فناوری اطلاعات که هدف از اجرای آنها، ایجاد تحول در سازمانها و ارتقای بهره وری و کیفیت خدمات نهایی است، این معیار باید با شدت بیشتــری موردتوجه قرارگیرد. هیچ پروژه برنامه ریزی فناوری اطلاعات برای نفس نتایج خود پروژه انجام نمی شود، بلکه معمولاً اینگونه پروژه ها در آغاز فرایندی از توسعه مستمر و برنامه ای زیرساختها و کاربردهای فناوری اطلاعات در سازمان تعریف می شوند که باید در درازمدت به ایجاد تحول سازمانی، کاهش هزینه ها، سرعت انجام فرایندها یا تنوع خدمات سازمان بینجامد. از این منظر می توان پروژه ای را موفق دانست که علاوه بر اجرا در زمان و با هزینه پیش بینی شده، به تولید خروجیهای توافق شده از قبل بینجــامد، و در درازمدت نیز فرایند توسعه ای مستمری در زمینه فناوری اطلاعات را در سازمان ایجاد کند. ● چالشها چالشهای فراروی پروژه های برنامه ریزی فناوری اطلاعات را در یک دید کلی می توان به سه دسته زیر تقسیم کرد: مشکلات ناشی از محیط تعریف و اجرای پروژه؛ مشکلات ناشی از روش (متدولوژی) پروژه؛ مشکلات ناشی از نحوه اجرای پروژه. هرچند از این سه دسته مشکل، تنها مشکلات دسته ۲ و ۳ مستقیماً به مجری پروژه مربوط می شود و مهار مشکلات ناشی از محیط، معمولاً خارج از کنترل تیم اجرایی است، با وجود این، شناخت و تحلیل این مشکلات، توانایی مجری را درکاهش اثرات ریسک های ناشی از این گونه مشکلات افزایش می دهد. ● مشکلات ناشی از محیط ▪ ابهام در استراتژی های سازمانـــی: یکی از اصلی ترین اهداف برنامه ریزی فناوری اطلاعات در سازمانها، همسوسازی فناوری اطلاعات با استراتژی های سازمانی است. در دهه ۱۹۹۰ بروز آنچه به «پــــــــارادکس بهره وری»(۳) شهرت یافت، موضوع همسوسازی استراتژیک را به پارادایم غالب برنامه ریزی فناوری اطلاعات تبدیل کرد، به گونه ای که امروزه در همه روشهای بـــــرنامه ریزی فناوری اطلاعات شناخت جهت گیریهای استراتژیک سازمان و عناصر برنامه استراتژیک آن، اولین گام در فرایند بــرنامه ریزی فناوری اطلاعات به شمــــار می رود. در سازمانهای دولتی و خصوصی کشور ما، عدم وجود فرهنگ و تفکر استراتژیک، که خود ناشی از رقابتی نبودن فضای کسب و کار در کشور است، وضعیتی را پدید آورده که در آن، وجود سازمانهای دارای برنامه استراتژیک مدون و توافق شده، استثناست نه قاعده. اقدام به اجرای پروژه های برنامه ریزی فناوری اطلاعات در سازمانهایی که هیچیک از عناصر جهت گیری استراتژیک سازمانی (ماموریت، چشم انداز، اهداف، استراتژی ها، سیاستها، عوامل عمده موفقیت، شاخصهای کارایی و...) مشخص و مدون نیست، مجریان را ناگزیر به اتخاذ یکی از این روشها می کند: - مجری در مراحل آغازین پروژه، به جای جمع آوری و دریافت نتایج برنامه ریزی استراتژیک سازمانی، خود اقدام به تحلیل و برنامه ریزی استراتــژیک سازمانی (ولو به شکل محدود) می کند. در این صورت ضمن انحراف منابع و زمان پروژه، توجه مجریان از دنبال کردن فرایند برنامه ریزی فناوری اطلاعات به تحلیل استراتژیک سازمانی منحرف می شود. - مجری بدون شناسایی عناصر برنامه استراتژیک سازمانی، پروژه برنامه ریزی فنـــاوری اطلاعات را پیش می برد. درنتیجه هیچ تضمینی برای آنکه چنین پروژه هایی به تحقق همسوسازی استراتژیک بینجامد، وجود ندارد. در هر صورت، اهمیت وجود حداقلی از برنامه استراتژیک ســازمانی برای موفقیت پروژه های برنامه ریزی فناوری اطلاعات به حدی است که از آن به عنوان پیش نیاز اجرای این گونه پروژه ها یاد می شود (۴). نیازبه باز مهندسی فرایندها: اگر اثربخشی یک پروژه برنامه ریزی فناوری اطلاعات را در میزان تحولی بدانیم، که این پروژه در بهبود عملکرد نهایی سازمان دارد، باید اذعان کرد که انجام این گونه پروژه ها در سازمانهایی که فرایندهای سنتی انجام کار در آنها به طور اساسی نیاز به باز طرحی و بازمهندسی دارند، از پیش محکوم به شکست است. برنامه ریزی فناوری اطلاعات که با هدف بهینه سازی استفاده از فناوری اطلاعات دردستیابی سازمان به اهدافش انجام می شود، درصورتی که در چنین سازمانهایی اجرا شود، درنهایت ممکن است به مکانیزه شدن فرایندهایی منجر گردد که یا میزان ارتباط آنها با اهداف استراتژیک سازمان موردتردید است، و یا به دلیل اشکالات فراوان در گردش کار، عملاً مانع از دستیابی به سطح بالایی از بهره وری سازمانی می گردند. ▪ عدم مشارکت مدیران و کارکنان: باتوجه به ماهیت مشارکتی فرایند برنامه ریزی در سازمانها، یکی از بزرگترین چالشهای مجریان پروژه های برنامه ریزی فناوری اطلاعات جلب مشارکت فعال مدیران ارشد، مدیران میانی و سایر کارکنان سازمان در این پروژه هاست. نقش هریک از این سطوح سازمانی در فرایند برنامه ریزی فناوری اطلاعات تفاوت می کند و از تعیین جهت گیری استراتژیک تا ارائه اطلاعات لازم برای مدل سازی معماری موجود سازمان متغیر است، اما در هر صورت بدون میزان معینی از مشارکت هریک از سطوح ذکر شده، نمــــی توان به موفقیت پروژه های برنامه ریزی فناوری اطلاعات خوشبین بود. میــــزان مشارکت کارکنان در فرایند برنامه ریزی به عوامل متعددی از قبیل منشا تعریف پروژه، میزان حمایت رسمی مدیریت ارشد، اطلاع رسانی درمورد پروژه، طراحی سازوکارهای تشویقی و جبرانی برای مشارکت کارکنان و... وابسته است، اما در کشور ما به دلیل عوامل فرهنگی و اجتماعی متعددی که مانع از مشارکت جویی کارکنان در مدیریت و بویژه در پروژه های توسعه ای می گردد، سطح این مشارکتها بسیار پایین و جلب کارکنان به همکاری در این گونه پروژه ها بسیار دشوار است. ● مشکلات ناشی از روش ▪ تعریف محدوده و اهداف: یکی از مراحل ابتدایی هر پروژه برنامه ریزی فناوری اطلاعات که متاسفــانه درعمل اهمیت چندانی به آن داده نمی شود، روشن کردن محدوده و کسب یک بینش مشترک درباره اهداف پروژه، بین همه عوامل دست اندرکار آن است. دستیابی به این بینش مشترک ازسویی به مجریان پروژه کمک می کند تا درک درستی از گامها و اقدامات ضروری پروژه پیدا کنند و بین این اقدامات و اقداماتی که می توان بسته به مقتضیات پروژه از آنها چشم پوشی کرد، تمایز قائل شوند، و از سوی دیگر انتظارات مدیران و کارکنان سازمان را از نتایج واقعی پروژه تعدیل می کند. تجربه نشان داده است که به دلیل نوپابودن فرهنگ برنامه ریزی فناوری اطلاعات در کشور ما، اغلب کارفرمایان چنین پروژه هایی دید درستی از نتایج موردانتظار نداشته و پروژه های برنامه ریزی فناوری اطلاعات را با تهیه سیستم جامع اطلاعاتی (MIS) و به طور خلاصه رفع همــــه مشکلات انفورماتیک سازمان یکی می دانند. چنین انتظاراتی در مرحله اجرا و پس از پایان پروژه، مجریان را با انبوهی از نیازها و توقعات غیرمعقول روبرو می سازد که درصورت عدم کنترل می تواند بر ارزیابی نتایج پروژه، اثرات منفی جدی به جای نهد. ▪ تمرکز بر روش، به جای توجه به نتایج: یکی از دامهایـی که بر سر راه مجریان پروژه های برنامه ریزی فناوری اطلاعات وجود دارد، عطف توجه بیش از حد به متدولوژی پروژه به بهای غفلت از نتایج آن است. هرچند فرایند برنامه ریزی فناوری اطلاعات فرایندی است روشمند که متدولوژی های مختلفی برای انجام آن پیشنهاد شده است، اما باید توجه داشت که همه این متدولوژی ها صرفاً الگوهای راهنمایی برای هدایت فرایند برنامه ریزی هستند؛ فرایندی که ذاتاً ماهیتی خلاق و پویا دارد و باید با توجه به مقتضیات محیطی خاص طراحی شود. به همین دلیل است که برخی از طراحان متدولوژی های برنامه ریزی فناوری اطلاعات که در سالهـــای اخیر رواج یافته اند، ترجیح می دهند روشهای پیشنهادی خود را در چارچوب بنامند، نه روش. تمرکز بر روش و غفلت از نتایج، در اکثر پروژه های برنامه ریزی فناوری اطلاعات، مجریان را به جمع آوری و تحلیل انبوهی از داده ها وامی دارد که در مراحل بعدی بخش عمده ای از آنها، مورداستفاده قرار نمی گیرند، یا در نتایج نهایی چندان تاثیری ندارند. همچنین عدم توجه به اولویت گذاری کاربردهای فناوری اطلاعات، که روشهای شناخته شده ای برای آن وجود دارد (۵)، مجریان را در مرحله برنامه ریزی اجرایی، با تعریف تعداد زیادی پروژه مواجه می کند که حجم زیاد منابع موردنیاز برای آنها، عاملی بازدارنده برای تصمیم مدیریت مبنی بر ادامه سرمایه گذاری در فناوری اطلاعات محسوب می شود.▪ تعداد مــــراحل: تعداد مراحل یک پروژه برنامه ریزی فناوری اطلاعات، به متدولوژی انتخاب شده بستگی دارد. به عنوان مثال، متدولوژی برنامه ریزی سیستم های تجاری (BUSINESS SYSTEM PLANNING=BSP) الگوی چهارمرحله ای استفاده می کرد (۶). در اکثر پروژه های اجرا شده برمبنای متدولوژی مهندسی اطلاعات (INFORMATION ENGINEERING=IE) پروژه از ۷ مرحله تشکیل شده است (۷). چارچوب معماری این گروپ (THE OPEN GROUP ARCHITECTURE FRAMWORK=TOGAF) چرخه ای مرکب از ۹ گام را پیشنهاد می کند (۸). با وجود این، بسته به مقتضیات پروژه می توان با ادغام یا تجزیه مراحل استاندارد، تعداد مراحل عملی هر پروژه را کم یا زیاد کرد. در انتخاب تعداد مراحل پروژه، در سازمانهایی که سطح مشارکت کارکنان در فرایند برنامه ریزی پایین است (مانند آنچه در اکثر سازمانهای کشور ما به چشم می خورد)، باید به این نکته توجه کرد که هرچه تعداد مراحل پروژه بیشتر باشد، نقاط تماس با مدیران و کارکنان سازمان (به منظور جمع آوری اطلاعات، تصحیح مدلها، صحه گذاری نتایج و...) افزایش می یابد، و به همین نسبت انرژی بیشتری باید برای جلب مشارکت کارکنان صرف شود. طولانی شدن زمان لازم برای اظهارنظر کارفرما درمورد گزارشهای هر مرحله، که اغلب در مرحله برنامه ریزی پروژه به درستی برآورد نمی شود، عامل مهمی در انحراف زمانی پروژه های برنامه ریزی فناوری اطلاعات از زمانبندی پیش بینی شده آنهاست. ▪ داده گرایی / فرایندگرایی:گذشته از تنوع روشهای مدل سازی که در پروژه ها به کار گرفته می شود، تقریباً همه روشهای شناخته شده برنامه ریـــــزی فناوری اطلاعات بر مدل سازی هر دو لایه عملیاتی و اطلاعاتی از معماری سازمان تاکید دارند. با وجود این، تاکید اصلی در هر روش متفاوت است. روشهای سنتی برنامه ریزی فناوری اطلاعات که بیشتر در زمینه برنامه ریزی سیستم های اطلاعاتی کاربرد داشته اند (مانند BSP وIE)، توجه اصلی خود را بر داده ها متمرکز می کنند و می کوشند از طریق ایجاد یک معماری اطلاعاتی یکپارچه، یکپارچگی و جامعیت سیستم های اطلاعاتی سازمان را تامین کنند. به همین دلیل، ماتریس های داده /فرایند که در این متدولوژی ها نقش اساسی در تعیین معماری سیستم های اطلاعاتی ایفا می کنند، معمولاً به طور مستقیم در طراحی و تفکیک بانک های اطلاعاتی سازمان درمراحل بعدی توسعه سیستم ها قابل استفاده است. در نقطه مقابل آن، رهیافتهای جدیدتر مبتنی بر خدمات سازمانی، به تحلیل داده ها تنها به عنوان مکملی برای مدل سازی فرایندها نگاه می کنند. انتخاب یکی از این دو دیدگاه، باتوجه به ماهیت کسب و کار و مدل کاری کلان سازمان، در ابتدای پروژه، اهمیت زیادی دارد. رهیافتهای داده گرا درمورد سازمانهایی که برمبنای ارائه خدمات یا انجام فرایندهای پیچیده و مرتبط شکل گرفته اند، معمولاً به شناسایی مجموعه ای از سیستم های اطلاعاتی یکپارچه می انجامد، بدون آنکه درعمل یکپارچگی عملیاتی مناسب را در سطح گردش کار روزمره سازمان، تامین کند. در مقابل رهیافتهای فرایندگرا در محیطهایی که کارکردهای تحلیلی و تصمیم گیری اولویت دارند، معمولاً از ایجاد یکپارچگی اطلاعاتی لازم برای پشتیبانی از روندهای تصمیم گیری کلان عاجزند. ● مشکلات ناشی از اجرا ▪ برنامه ریزی فرایند است، نه نتیجه: نکته ای که در اکثر پروژه های برنامه ریزی فناوری اطلاعات هم از سوی کارفرمایان، و هم از سوی مجریان، از آن غفلت می شود، ماهیت مستمر فرایند برنامه ریزی است. درواقع اجرای پروژه های برنامه ریزی فناوری اطلاعات را تنها باید به عنوان نقاط شروع این فرایند در سازمانها محسوب کرد. انجام این پروژه ها توسط مشاوران بیرونی، بیش از آنکه برای به سرانجام رساندن پروژه و تولید گزارشهای نهایی باشد، باید با هدف توانمندسازی ساختار داخلی سازمان برای ادامــــــه و استمرار فرایند برنامه ریزی صورت گیرد. عدم توجه به ماهیت فرایندی برنامه ریزی فناوری اطلاعات موجب می شود که مدیران از انجام نخستین پروژه برنامه ریزی فناوری اطلاعات، که دراکثر موارد پس از پایان پروژه به نحو موثری به استمرار فرایند برنامه ریزی منجر نمی شود، توقع تاثیر درازمدت در تصمیم گیریهای سازمانی درمورد فناوری اطلاعات داشته باشند. توقعی که معمولاً برآورده نخواهدشد. ▪ برآوردهای نادرست از زمان و هزینه پروژه: هرچند که زمان طبیعی برای انجام پروژه های برنامه ریزی فناوری اطلاعات بین ۶ تا ۹ ماه برآورد می شود، با وجود این، درکشور ما کمتر پروژه ای را می توان یافت که در این محدوده زمانی به نتیجه مطلوب رسیده باشد. یکی از دلایل عمده این امر، عدم تحلیل مخاطرات پروژه در ابتدای کار، یا عدم توجه کافی به برخی از ریسک های جدی مانند عدم مشارکت مدیران و کارکنان، یا تغییرات سازمانی است. تجربیات شخصــی نگارنده در اجرای پروژه های برنامه ریزی فناوری اطلاعات در سازمــانهای متعدد دولتی و خصوصی نشان می دهد که به طور متوسط ۳۰ تا ۴۰ درصد زمان واقعی پروژه صرف بررسی و اظهارنظر نتایج پروژه توسط نمایندگان کارفرما، و اصلاحات ناشی از این بررسیها می شود، درحالی که در برنامه ریزی پروژه این زمان چیزی در حدود ۵ تا ۱۰ درصد زمان کل پروژه برآورد می شود. ▪ ترکیب و تخصص تیم اجرایی: واقعیت آن است که اکثر شرکتهای مشاوره ای که در کشور ما اقدام به اجرای پروژه های برنامه ریزی فناوری اطلاعــات می کنند، در یکی از دو دسته زیر می گنجند: - شرکتهــــــــای با زمینه رایانه ای (اغلب نرم افزاری) که کارشناسان و تحلیلگران آنها معمولاً در رشته های مرتبط با نرم افزار تخصص و تجربه دارند. - شرکتهای مشاوره مدیریت که زمینه تخصصی کارشناسان آنها را رشته هایی مانند مدیریت، مهندسی صنایع، اقتصاد و رشته های مشابه تشکیل می دهد. درهریک از این دو صورت، غلبه یکی از دو دیدگاه مهندسی یا مدیریتی بر تیم اجرایی پروژه، می تواند توانایی این تیم را در تحلیل و مدل سازی همه لایه ها و ابعاد معماری فناوری اطلاعات را در سازمان هدف تضعیف کند. فرایند برنامه ریزی فناوری اطلاعات در یک سازمان فرایندی است پیچیده که به دانش نسبتاً بالایی در زمینه های متنوعی از مدیریت استراتژیک و مهندسی سیستم گرفته تا مهندسی نرم افزار و تخصصهای ارتباطات و شبکه نیاز دارد. فراهم آوردن ترکیب مناسبی از این تخصصها در تیم اجرایی پروژه، عامل مهمی در موفقیت پروژه است، که درعمل عدم تحقق آن به یکی از چالشهای جدی مدیران پروژه ها تبدیل می شود. ▪ ارتباط با پروژه های دردست اجرا: پروژه های برنامه ریزی فناوری اطلاعات معمولاً در سازمانهایی تعریف می شود که در سطوح مدیریتی آنها عزم مشخصی در زمینه توسعه فناوری اطلاعات در سازمان پدید آمده باشد، یا اینکه محرکهای بیرونی قــوی برای توسعه برنامه ای آن احساس شده باشد. در چنین مواردی، فشار برای ســـرمایه گذاری در پروژه های توسعه ای موازی در زمینه فناوری اطلاعات چندان غیرمعمول نیست. یکی از چالشهای اصلی تیم های اجرایی پروژه های برنامه ریزی فناوری اطلاعات در این سازمانها، چگونگی ارتباط فرایند و نتیجه پروژه، با دیگر پروژه های فناوری اطلاعات دردست اجراست. در چنین حالتهایی، از یکسو شمول نتایج پــروژه برنامه ریزی فناوری اطلاعات ایجاب می کند که پروژه های دیگر ازنظر تعریف و اجرا با این نتایج سازگار شوند، و از سوی دیگر، لزوم تسریع در اجرا و بهره برداری از پروژه های دیگر، فشار مضاعفی را برای تسریع در ارائه نتایج پروژه برنامه ریزی فناوری اطلاعات وارد می کند. درعمل بسیاری از مجریـــــان پروژه های برنامه ریزی ناگزیر می شوند پیش از پایان پروژه خود و نهایی شدن نتایج آن، در مقام مشاور برای تعریف و راهبری پروژه های دیگر ایفای نقش کنند. نقشی که خودبه خود در سمت گیری نتایج پروژه برنامه ریزی فناوری اطلاعات موثر است. ●● نتیجه گیری چالشهایی که برای پروژه های برنامه ریزی فناوری اطلاعات ذکر شد، تنها بخشی از مشکلاتـــی است که مجریان پروژه های برنامه ریزی فناوری اطلاعات در سازمانهای کشور ما با آنها روبرو هستند. رفع ریشه ای برخی از این مشکلات به زمان و فرهنگ سازی طولانی در محیطهای سازمانی و لایه های مدیریتی این سازمانها نیاز دارد، و یقیناً از توان یک مشاور به تنهایی خارج است. اما برخی از توصیه های عمومی را می توان به منظور کاهش مخاطرات ناشی از این عوامل، یا حداقل کاهش اثرات آنها به کار بست، که در اینجا به طور خلاصه به آنها اشاره می شود: ۱ - بر روی مشارکت کارکنان سرمایه گذاری کنید. تا می توانید، و از هر راه ممکن مشارکت مدیران و کارکنان کلیدی سازمان را در فرایند برنامه ریزی جلب کنید. نخستین گام برای جلب این مشارکت، اطلاع رسانی درمورد اهداف، دامنه، روش و الزامات اجرای پروژه است. اما این اطلاع رسانی، اگر صرفاً به برگزاری یک جلسه افتتاحیه محدود شود کافی نیست. باید مطمئن شوید که همه مدیران و کارکنان کلیدی و تاثیرگذار سازمان، از آنچه شما می خواهید انجام دهید، و از تاثیر آن بر آینده کاری خود آگاه شده اند. برخی از مشاوران نسبت به افشای رموز و فوت و فن کاری خود در محیط کارفرما مقاومت می کنند. با چنین روحیه ای مطلقاً نمی توان به جلب مشارکت کارکنان امیدوار بود. همچنین نباید در ارزیابی فاصله علمی و فنی خود با کارشناسان کارفرما اغراق کنید یا آن را به نمایش بگذارید. در جلب مشارکت کارکنان دو موضوع شایسته توجه بیشتری است: نخست نقش کلیدی مدیران میانی، که اغلب در میانه مدیران ارشد و کـــارکنان سطح پایین از آنها غفلت می شود، و دوم اهمیت مکانیسم های جبران مشارکت در پروژه. واقعیت این است که هزینه مشارکت کارکنان در پروژه باید از ابتدا توسط کارفرما برآورد و پیش بینی شده باشد، اما حتی درصورتی که بودجه مشخصی برای این کار درنظر گرفته نشده باشد، مجری موظف است که این هزینه ها را جزء هزینه های انجام پروژه محاسبه کرده و مکانیسم سالمی برای پرداخت آن طراحی کند. ۲ - به ماهیت چرخه ای فرایند برنامه ریزی توجه کنید. برخلاف الگوهای سنتی برنامه ریزی (به عنوان مثال IE)، چــــارچوبهای جدیدتر برنــامه ریزی فناوری اطلاعات بر ماهیت چرخه ای و تکرارشونده برنامه ریزی تاکید دارند. گذشته از آنکه زمان پیش بینی شده برای انجام پروژه چه فرصتی برای تکرار مراحل فــراهم کند، باید توجه داشت که اصرار بر جمع آوری همه اطلاعات لازم یا تکمیل همه اجـــــزای یک مدل در یک مرحله پروژه، گاهی ممکن است اثرات تاخیری بر کل پروژه داشته باشد، درحالی که می توان بسیاری از نواقص مراحل پیشین را در مراحل بعدی جبران کرد. ۳ - زمان لازم برای اظهارنظر کارفرما پیش بینی کنید. ضروری است که زمانهای لازم برای بررسی و صحه گذاری فرآورده های پروژه ها توسط نمایندگان کارفرما، به طور مشخص در برنامه زمانی پروژه پیش بینی شده باشد. برآورد این زمان باید باتوجه به عوامل مختلفی از قبیل فرهنگ و بلوغ سازمانی، سابقه برنامه ریزی در سازمان، سطح تخصص نمایندگان کارفرما، و... صورت گیرد. بویژه باید از این ساده انگاری که فهم و بررسی فراورده ها، به همان سرعتی که توسط ما صورت می گیرد، توسط نمایندگان کارفرما نیز می تواند انجام شود، پرهیز کرد. ۴ - محدوده و اهداف پروژه را از پیش روشن سازید. تا آنجا که می توانید درک مشترکی بین خود و عوامل کارفرما، از دامنه و اهداف پروژه ایجاد کنید. مطمئن شوید که مدیریت و کارکنان درگیر در پروژه، موضوع و هدف پروژه را با مفاهیم مرتبطی مانند سیستم جامع، MIS ، ERP، و... خلط نمی کنند. ۵ - دانش برنامه ریزی فناوری اطلاعات را به محیط کارفرما منتقل کنید. ممکن است این انتقال دانش فنی در کوتاه مدت به زیان شما به نظر برسد. اما مطمئن باشید بدون انتقال فرهنگ و دیدگاه برنامه ریزی فناوری اطلاعات به سازمان، هیچگاه ارزیابی درستی از اهمیت و ارزش کار شما صورت نخواهدگرفت.

دستورالعمل تهیه و نگارش پروپوزال

دستورالعمل تهیه و نگارش پروپوزال

● مقدمه وضرورت : هدف کلی هر پروپوزال ایجاد شناخت ویا ترغیب خواننده آن به انجام کاری است. این خواننده می تواند یک مشتری بالقوه باشد که در نظر داریم تا نسبت به خدمات ومحصول ما آشنائی یافته ویا به ارتباط ،حمایت ویا مشارکت با شرکت ما ترغیب گردد، و یا چنانچه می خواهیم کارفرمایی را به سرمایه گذاری دراجرای یک پروژه تشویق وترغیب نمائیم. درهر پروپوزال یک طرح ویا راهکار برای برآورده ساختن یک نیاز پیشنهاد می گردد که دریافت کننده آن، پیشنهادات ارائه شده را با توجه به نوع طرح و ساختارنوشتاری و مستندات قوی ومستدل پروپوزال مزبور میزان پاسخگوئی به سوالات زیر را در پروپوزال مد نظر گرفته و مورد ارزیابی قرارخواهد داد: ـ پیشنهاد ما چیست؟ ـ برای انجام آن چگونه طرحریزی کرده ایم؟ ـ چه زمانی را برای انجام آن برنامه ریزی کرده ایم؟ ـ چقدر هزینه برای انجام این طرح لازم است؟ ـ چگونه وبه چه میزان در تحقق اهداف و انتظارات سازمان متبوع نقش خواهد داشت؟ در نگارش پروپزال سطح دانش مخاطبین و نیز موقعیت آنان بایستی در نظر گرفته شود. اگر مخاطب پروپوزال دارای رشته علمی دیگری بوده ویا دانش و تخصص کافی نسبت به موضوع ارائه شده ندارد، ضروریست تا در ابتدای پروپوزال یک مقدمه اجرایی به زبان ساده ، عمومی و گویا آورده شود. برای نگارش یک پروپوزال استاندارد کاملاً تعریف شده ای وجود ندارد، لیکن قالبهای متعددی موجود است و برخی از سازمانها، بخصوص سازمانهای سرمایه گذار و اعطا کننده کمکهای اعتباری و مالی، فرمت های از پیش تعیین شده ای را با توجه به نوع کار و یا مختصات خدمات قابل ارائه خود در نظر گرفته اند که با توجه به مشترکات عمده ای که در کلیه آنها مشهود است می توان یک قالب کلی را با محتویات زیر در نظر گرفته و پیشنهاد نمود: ● قالب کلی تهیه و نگارش یک پروپوزال ۱) مقدمه: ▪ معرفی پروپوزال اگر پروپوزال در پاسخ به یک “درخواست پروپوزال“ (RFP) ارسال می گردد، مقدمه ای برای آن فراهم شده و در آن شماره، تاریخ، شماره تماس با مشتری یا کارفرما و جزئیات دیگر مورد نیازآورده شود. در غیر اینصورت، دلیل ارسال پروپوزال، دریافت کننده آن (با نام) و چگونگی پاسخ مورد انتظارتان را بطور خلاصه و در ابتدا ذکر گردد. ▪ معرفی سازمان ارسال کنده پروپوزال سازمان ارسال کننده را به روشنی معرفی کرده و بر ارزش نقش آن برای کارفرما یا مشتری تاکید کنید. ▪ سوابق کاری تجارب و سوایق کاری سازمان یا شرکت خود را بطور خلاصه ذکر کنید. ۲) محصولات ارائه شده: ▪ طراحی ومعماری معماری و طراحی مورد نظر جهت محصولات یا خدمات ارائه شده را شرح دهید. ▪ اجزاء وپیکربندی نحوهٔ پیکربندی واجزاء محصولات یا خدمات خود را بیان کنید. ▪ جنبه های خاص و مزایا اصلی ترین جنبه های محصولات پیشنهادی و مزایای مربوط به آنها را شرح دهید. ▪ مشخصات عملکرد و سایر مشخصات محصولات پیشنهادی را شرح داده و یا در ضمیمه پروپوزال بیاورید. ۳) خدمات ارائه شده: ▪ بکارگیری نحوه نصب و بکارگیری را شرح دهید. ▪ یکپارچه سازی نحوه یکپارچه سازی با محیط موجود را شرح دهید. ▪ نگهداری و پشتیبانی نگهداری و پشتیبانی فراهم شده برای مشتری را بیان کنید. ▪ روش تحویل روش تحویل خدمات و رویه های مربوطه را بیان کنید. ▪ کاهش ریسک تعریف واقع بینانه ای از ریسک های قابل پیش بینی درپروژه و نحوه کاهش آنها را ارائه دهید. ▪ تضمین کیفیت انچه را که برای تضمین کیفیت براساس استانداردهای حرفه ای مورد نیازبوده و انجام خواهید داد، بیان نمائید. ۴) تجارب و سوابق کاری مرتبط: ▪ خلاصه ای از پروژه های انجام شده توصیف پروژه های مشابهی که قبلاً توسط شرکت انجام شده است. ▪ مراجع و شواهد شواهد و نقطه نظرات مشتریان قبلی خود را ذکر کنید. ۵) هزینه و قیمت گذاری: ▪ روش تعیین قیمت قیمت مورد نظر چگونه محاسبه شده است؟ ▪ قیمت گذاری قیمت محصولات و خدمات خود را بیان کنید. ▪ نحوه پرداخت نحوه پرداخت قیمت محصولات یا خدمات خود را بیان کنید. ۶) جذب سرمایه گذاری واعتبارات: چنانچه در پروژه مورد نظر مواردی از قبیل جذب سرمابه گذاری اشخاص ثالث ویا امکان اخذ وام واعتبارات از نهادهای پولی و اعتباری داخلی ویا خارجی پیش بینی شده، مطلوب است تا راهکارهای اداری وقانونی آنها ونیزنحوه و مدت زمان قابل پیش بینی برای دستیابی به این منابع ذکر گردد. ۷) موارد قانونی: هرگونه موارد پیگیری و یا ضرورتهای قانونی قراردادها وتعهدات مربوطه را بطور مشخص و با ذکر مبانی و مراجع قانونی هریک بیان کنید. ـ توضیح: سرفصل های ذکر شد در قالب یک طرح کلی و به منظور نظامند کردن نحوه ارائه پروپوزال تهیه وتدوین گردیده وجایگاه پیشنهادی دارد که به اقتضای نوع کار وخدمات مورد نظر،در صورت نیاز قابل تغییرخواهد بود.

مهندسی و معماری سیستم‌ها

مهندسی و معماری سیستم‌ها

در ایجاد سیستم‌هایی که نمونه‌هایی از آنها موجود است، مهندسی سیستم‌ها به کار گرفته می‌شود. پیچیدگی این گونه سیستم‌ها معمولاً کم است. اما وقتی موضوع ایجاد یک سیستم جدید یا سیستم‌های پیچیده که دارای کنترل‌پذیری کم هستند، مطرح می‌شود مهندسی سیستم‌ها پاسخگو نخواهد بود و معماری سیستم‌ها استفاده می‌شود. این مقاله به معرفی معماری سیستم‌ها، مقایسه معماری سیستم‌ها با مهندسی سیستم‌ها، و متدولوژی معماری سیستم‌ها می‌پردازد. ۱) مراحل ایجاد سیستم‌ها هر پروژه‌ای، چه ساخت یک کلبه باشد چه یک هواپیما، با ظهور یا حضور کاربر بالقوه، یک احساس نیاز و یک مجموعه از منابع شامل منابع انسانی و فیزیکی آغاز می‌شود. با بررسی تاریخچه پروژه‌ها، می‌بینیم که بیشتر پروژه‌ها به عنوان تطبیق تکاملی و تدریجی ساختار‌های موجود انجام می‌شوند. به عنوان مثال ساختار یک کشتی سالهاست که طراحی شده است. این ساختار بر پایه اصولی شکل گرفته که کمتر تغییر یافته است. آنچه تغییر می‌کند و تکامل می‌یابد تواناییهای آن ساختار از ابعاد مختلف است؛ مواد اولیه استفاده شده، قابلیتهای فنی، ظاهر و غیره. به عنوان مثال دیگر می‌توان به یک سیستم اطلاعات مدیریت اشاره کرد. اصول چنین سیستم اطلاعاتی چندین سال است که پایه‌ریزی شده است و بیشتر تلاش‌های صورت پذیرفته در جهت پیاده‌سازی، اجرا و تکمیل آن بوده است. در چنین پروژه‌هایی تنها اقتباس ساده‌ای از ساختارهایی می‌شود که مقصود و مفهوم آنها کاملاً روشن و بدیهی است. مراحلی که در ایجاد چنین سیستم‌هایی طی می‌شود در شکل ۱ آمده است (خط‌های وصل کننده به عمد بدون جهتند، یعنی این فرایند رفت و برگشتی است): اولین مشکلی که در چنین فرایند سرراستی اتفاق می‌افتد هنگامی است که یک نوع جدید از ساختار در راستای مفاهیم ساختار موجود مورد نیاز باشد که اصول و فناوری‌های جدیدی را طلب کند. اینجاست که به یک نوع فعالیت مهندسی نیاز است (شکل ۲). هر چه ساختار پیچیده‌تر می‌شود جریان پروژه نیز پیچیده‌تر می‌شود. معمولاً جریان پروژه‌های سیستم را در قالب «مدل آبشاری۱» به صورت زیر نمایش می‌دهند(شکل ۳): در چنین فرایندی گروه‌های متفاوتی انجام وظیفه می‌کنند و مهندسین سیستم عهده‌دار تطبیق عناصر ساختار در جاهایی هستند که «فصل مشترک‌ها۲» نامیده می‌شوند. ۲) پیچیدگی در سیستم‌ها واژه «پیچیدگی۳» از ابعاد گوناگون قابل بررسی است. از دیدگاه کمی و ریاضی، بهترین راه شناخت پیچیدگی آن است که آن را به مثابه یک مفهوم آماری در نظر بگیریم؛ یعنی مفهوم پیچیدگی، برحسب احتمال قرار گرفتن یک سیستم در یک حالت خاص و در یک زمان معین، به بهترین وجه قابل تشریح است. در حالی که از دیدگاه غیرکمی، پیچیدگی را کیفیت یا خاصیتی برای سیستم تلقی می‌کنند که در اثر تلفیق پنج عامل (رضائیان ۱۳۷۶، ۱۰۰-۱۰۲) زیر به وجود می‌آید: ۱) تعداد عناصر تشکیل دهنده سیستم ۲) میزان تعامل عناصر مختلف سیستم ۳) نحوه تعامل عناصر مختلف سیستم ۴) ویژگیهای هر یک از عناصر سیستم ۵) درجه نظام یافتگی ذاتی سیستم بنابراین اکتفا به برخی از شاخصهای مذکور برای تشخیص میزان پیچیدگی، گمراه کننده است. در واقع، برای به دست آوردن یک شاخص معنی‌دارتر، باید علاوه بر «تعداد عناصر» و «میزان تعاملهای میان آنها‍»، «نحوه تعامل»، «ویژگیهای هر یک از عناصر‍» و «درجه نظام یافتگی سیستم» نیز مورد ملاحظه قرار گیرند. به این ترتیب، تحلیلگر می‌تواند با استفاده از مجموعه این پنج شاخص، به مجموعه حالتهای ممکن قابل تصور برای سیستم دست یابد. برای مثال هنگام تعیین حیطه نظارت یک سرپرست، اگر کار خیلی تکراری باشد و اعضای گروه نیز خوب آموزش دیده باشند، با فرض اینکه هیچ تلاش عمدی برای به زحمت انداختن سرپرست انجام نشود، و نسبت بالایی از تعاملهای بالقوه به تعامل بالفعل تبدیل نشود، سیستم موردنظر، سیستمی ساده تلقی می‌شود. البته مجموعه قوانین و رویه‌های موجود نیز ممکن است موجب کاهش قابل ملاحظه تعاملهای مذکور شود. بنابراین، پیچیدگی یک مفهوم نسبی است که در اثر تعامل مجموعه عوامل پنج‌گانه مذکور معین می‌شود (نه فقط برخی از آنها، نظیر «تعداد عناصر‍» و «میزان تعامل»). برای مثال، سرپرستی که دو متخصص انرژی (که یکی ذغال سنگ را به مثابه امیدوارکننده‌ترین منبع انرژی آینده در نظر می‌گیرد و دیگری بر مزایای انرژی هسته‌ای تأکید دارد؛ یعنی وجود دیدگاه‌های متفاوت) زیر نظر وی کار می‌کنند، در مقایسه با کسی که حدود بیست مهندس نفت را سرپرستی می‌کند، با سیستمی بمراتب پیچیده‌تر مواجه است. در واقع دو عامل اول به پیچیدگی «ساختاری» و سه عامل آخر به پیچیدگی «رفتاری» سیستم اشاره دارند. آنچه که در این جا مدنظر ماست بیشتر پیچیدگی رفتاری است. در پیچیدگی ساختاری تعداد عناصر سیستم خیلی زیاد بوده و میزان تعامل بین آنها بسیار زیاد یا حتی بی‌شمار است. در پیچیدگی رفتاری روابط علت و معلول کاملاً روشن نیستند و نتایج کوتاه مدت و بلند مدت خیلی متفاوتند. اقدامات اعمال شده بر روی بخش‌های مختلف سیستم نتایج متفاوتی دارند و ممکن است دخالت‌های حساب شده و روشن، نتایج غیر قابل پیش‌بینی و غیر منتظره داشته باشند. رفتار کلی سیستم به سختی قابل پیش‌بینی است. رفتار کلی سیستم در کل قابل مشاهده نبوده و اندازه‌گیری آن مخرب یا غیر قابل انجام است. به سختی می‌توان پیچیدگی رفتاری را بر اساس قوانین حاصل از نظریات بیان نمود چرا که داده کافی و پایا وجود ندارد (ساسمن ۲۰۰۰). برای مثال، قوانین و مقررات مدون حاکم بر نحوه تعامل عناصر سیستم و عوامل تعیین کننده ویژگیهای آن عناصر، بر میزان پیچیدگی سیستم اثر می‌گذارند. برخی برای سنجش میزان پیچیدگی یک سیستم از دو عامل یا معیار «تعداد عناصر تشکیل دهنده سیستم» و «میزان تعامل عناصر مختلف سیستم» استفاده می‌کنند که ممکن در برخی موارد سطحی و گمراه کننده باشد. اگر کسی بررسی خود را به این دو بعد محدود کند، به مسیری هدایت می‌شود که ممکن است موتور ماشین سواری را در شمار سیستم‌های بسیار پیچیده قرار دهد. زیرا موتور ماشین از تعداد قطعات زیادی تشکیل شده و به همین میزان نیز میان اجزای آن تعامل وجود دارد. همچنین براساس این دو شاخص پیچیدگی، تعامل میان دو نفر انسان (یک سیستم اجتماعی)، در شمار سیستمهای بسیار ساده قرار می‌گیرد زیرا این سیستم فقط دو عنصر دارد و میان آنها فقط دو رابطه تعاملی قابل تصور است. در صورتی که اگر فرد مذکور، در تحلیل خود به نقش سه عامل دیگر مؤثر بر پیچیدگی (یعنی «نحوه تعامل عناصر مختلف سیستم»، «ویژگیهای هر یک از عناصر» و «درجه نظام یافتگی ذاتی سیستم») نیز توجه کند، به نتیجه دیگری خواهد رسید. در مورد موتور ماشین، تحلیلگر مشاهده خواهد کرد که میزان تعامل موجود میان قطعات آن، از قوانین و توالی معینی تبعیت می‌کنند و ویژگیهای عناصر آن از پیش تعیین شده‌اند. بدین ترتیب با استفاده از این پنج شاخص پیچیدگی، تحلیلگر متوجه می‌شود که موتور ماشین در واقع یک سیستم بسیار ساده است در حالی که سیستم «تعامل میان دو انسان» که به ظاهر ساده به نظر می‌رسید، در واقع سیستم بسیار پیچیده‌ای است زیرا ویژگیهای هیچ یک از عناصر آن، از پیش قابل تعیین نیستند. از آنجا که احتمال شرطی بودن رفتار آنها، علی‌رغم وجود برخی قوانین ثابت در مکالمه و تعامل، بسیار کم است، نتیجه نهایی تعامل یا گفتگو قابل پیش‌بینی نیست زیرا عناصر این سیستم در رعایت یا عدم رعایت آداب معاشرت، آزادی عمل دارند و درجه قابلیت پیش‌بینی حالت نهایی برخورد آنها، بسیار پایین است. بنابراین، تحلیلگر متوجه می‌شود که این سیستم دو نفره، در واقع یک سیستم بسیار پیچیده است. ۳) پیچیدگی و کنترل‌پذیری (رضائیان ۱۳۷۶، ۸۰-۸۳) در صورتی که ویژگی «میزان پیچیدگی» را مبنای طبقه‌بندی سیستمها فرض کنیم، مجموعه‌ای مشتمل بر سیستمهای ساده، سیستمهای پیچیده، و سیستمهای بسیار پیچیده قابل تشخیص خواهد بود. سیستم ساده، سیستمی است که تعداد اجزای تشکیل دهنده آن کم بوده و روابط محدودی میان آنها برقرار باشد در حالی که سیستم پیچیده، سیستمی است که دارای اجزای بسیار زیاد و به هم وابسته‌ای باشد و سیستم بسیار پیچیده نیز سیستمی است که شناسایی و تشریح دقیق اجزاء و ویژگی‌های آن، امکانپذیر نباشد. ویژگی دوم (قابلیت پیش‌بینی) با ماهیت سیستم از حیث «میزان قطعی بودن یا احتمالی بودن»، سر و کار دارد. در این مورد، دو وضعیت قابل تصور است: در وضعیت اول، اجزای سیستم به گونه‌ای کاملاً قابل پیش‌بینی با یکدیگر تعامل دارند در حالی که در وضعیت دیگر، رفتار سیستم قابل پیش‌بینی نیست، ولی ممکن است آنچه اتفاق می‌افتد، قابل پیش‌بینی باشد. رفتار سیستمهای قطعی قابل پیش‌بینی است و سازمانها در شمار مصادیق آنها قرار نمی‌گیرند (برخلاف سیستمهای باز که شامل سازمانها نیز می‌شوند). از این رو، بندرت جلب توجه می‌کنند. مجموعه سیستمهای قطعی، سیستمهایی نظیر قرقره، ماشین تحریر، ماشینهای اداری، پردازش قطعات بر روی خط تولید، پردازش خودکار چک در بانک، و غیره را در بر می‌گیرد که در همه آنها خروجی سیستم از طریق نظارت بر ورودیهای سیستم، کنترل می‌شود. پس از سیستمهای قطعی ساده، سیستمهای قطعی پیچیده مطرح می‌شوند که فقط از حیث «درجه پیچیدگی» با هم تفاوت دارند؛ برای مثال، کامپیوترها که بسیار پیچیده‌تر از «سیستمهای قطعی ساده» هستند، به طور کاملاً قابل پیش‌بینی کار می‌کنند. وجوه تمایز این دسته‌ها، نسبی و نامعین است. برای مثال، کامپیوترها به منزله سیستمهای قطعی پیچیده مطرح شدند در حالی که ممکن است از نظر یک متخصص، فاقد پیچیدگی باشند. همچنین بسیاری از افراد، موتور یک خودرو را سیستمی پیچیده به شمار می‌آورند در حالی که همین سیستم، از نظر «نیروهای فنی» یک سیستم قطعی ساده محسوب می‌شود. در همه مثالهای فوق، ماهیت سیستم «یک حالته» است یعنی رفتار آن به وسیله ترتیب ساختاری عناصر تشکیل دهنده‌اش معین می‌شود زیرا اگر ترتیب عناصر یک «سیستم قطعی» صحیح باشد، طبق الگویی که برایش تعیین شده است، عمل خواهد کرد. اگر تعداد حالتهای قابل تصور برای نتایج عملکرد یک سیستم، بیشتر از یک باشد، ماهیت سیستم «احتمالی» است. مجموعه مصادیق سیستمهای احتمالی، از ساده‌ترین موارد ممکن (مانند پرتاب سکه که فقط دو حالت محتمل دارد) تا پیچیده‌ترین سیستمهای اجتماعی و سازمانها را (که حالتهای محتمل بسیاری برای آنها قابل تصور است) در بر می‌گیرد. مثالهایی نظیر سیستم کنترل کیفیت و تناوب توقف دستگاهها، برای سیستمهای احتمالی ساده مطرح می‌شوند. در فرایندهای تولید دستی، با توجه به تفاوتهای فردی کارکنان، ممکن است کیفیت محصولات تولیدی متفاوت باشد به همین دلیل، برای تضمین حداقل کیفیت مورد نظر، از فنون کنترل کیفیت آماری استفاده می‌شود. همچنین با توجه به میزان فرسودگی قطعات و تناوب استفاده از یک ماشین، باید آن را در فواصل زمانی معینی تعمیر کرد. در چنین مواردی نیز توصیه می‌شود که برای کنترل، از روشهای آماری استفاده شود. با افزایش پیچیدگی یک سیستم احتمالی و افزوده شدن بر تعداد حالتهای ممکن برای آن، پیش‌بینی نتایج عملکرد و کنترل رفتار آن سیستم، دشوارتر خواهد شد. در واقع، کنترل ورودیهای یک سیستم قطعی ممکن است به پیش‌بینی خروجیهای آن بینجامد در حالی که کنترل ورودیهای یک سیستم احتمالی فقط می‌تواند به پیش‌بینی دامنه نوسانات خروجیها منجر شود. سیستمهایی نظیر انسان، سازمانهای بزرگ، و سیستمهای اقتصادی و اجتماعی، نمونه‌هایی از سیستمهای احتمالی بسیار پیچیده هستند. این‌گونه سیستمها، حالتهای رفتاری و علمکردی متغیری دارند. برای مثال، یک سازمان بزرگ که خود از خرده سیستمهای زیادی تشکیل شده است، با سیستمهای بیرونی متعددی مانند دولت، رقبا، اتحادیه‌ها، تأمین کنندگان مواد اولیه، و بانکها سر و کار دارد. گاهی تعامل واحدهای داخلی و اجزای تشکیل دهنده سازمان با خرده سیستمهای محیطی، آنقدر با ظرافت و پویایی صورت می‌گیرد که تعریف تفصیلی سیستم را غیرممکن می‌سازد. سیستمهای احتمالی ساده با روشهای آماری کنترل می‌شوند. در حالی که سیستمهای احتمالی پیچده را باید با روشهای پیچیده پژوهش در عملیات کنترل کرد. البته کارآیی روشهای پژوهش در عملیات نیز محدود است به طوری که برای کنترل «سیستمهای احتمالی بسیار پیچیده» (که به طور دقیق قابل تعریف نیستند) کفایت ندارند زیرا این گونه سیستمها، جزئیاتی غیرقابل تعریف دارند و نمی‌توان آنها را با «روش سنتی تجزیه و تحلیل» بررسی کرد. در محیطهای کاری بندرت با سیتمهای قطعی مواجه می‌شویم زیرا بیشتر سیستمها، هم از حیث ساختاری و هم از حیث رفتاری، سیستمهایی احتمالی به شمار می‌آیند. در واقع هر سیستمی که علمکرد آن احتمالاً توأم با درصدی از خطاست، سیستمی احتمالی محسوب می‌شود. بررسی اینگونه سیستمها و روشهای کنترل آنها، معمولاً به صورت مجرد و انتزاعی انجام می‌گیرد. با وجود این، نتایج حاصل از این بررسیها، در سیستمهای واقعی نیز قابل استفاده هستند.۴) پیچیدگی در سیستم‌های اجتماعی سیستم‌های اجتماعی، سیستم‌های بسیار پیچیده‌ای از جنبه ساختاری و رفتاری هستند. انسان به همراه نقش‌های خود، اصلی‌ترین جزء این گونه سیستم‌هاست. هر سیستم اجتماعی شامل تعداد قابل ملاحظه‌ای از افراد، گروه و واحدهای سازمانی است که از جنبه‌های مختلفی با هم دیگر تعامل دارند. فرهنگ، ارزش، اعتقادات، مسائل سیاسی، اقتصادی، اجتماعی، و حرفه‌ای چیزهایی است که بر نحوه تعامل بین آنها تأثیر می‌گذارد. اثرات ناشی از این عوامل و نحوه تعاملات حاصل به سختی قابل بررسی است. عناصر سیستم‌های اجتماعی از پویایی زیادی برخوردارند. سیستم‌های اجتماعی کمتر نظم یافته هستند و به مرور زمان تغییر می‌کنند. اهداف سیستم‌های اجتماعی در طول زمان دستخوش تغییر می‌شوند. به عنوان یک سیستم باز، محیط سیستم‌های اجتماعی تأثیر زیاد بر آن می‌گذارد و تشخیص این تأثیر دشوار است. اطلاعات در مورد شرایط سیستم کم یا غیرقابل دستیابی است. مسائل سیستم‌های اجتماعی چند بعدی، مهم و وابسته به یکدیگر هستند. شرایط فوق عموماً در سیستم‌های اجتماعی وجود دارند اما میزان پیچیدگی در بین سیستم‌های اجتماعی متفاوت است. به عنوان مثال، پیچیدگی در یک سازمان بوروکراتیک کمتر از پیچیدگی یک سازمان نوآورانه است و پیچدگی یک جامعه خیلی بیشتر از پیچیدگی یک سازمان معمولی است. آنچه که در این‌جا مد نظر ماست سیستم‌های اجتماعی بسیار پیچیده هستند که کاهش پیچیدگی آنها دشوار یا غیر ممکن است. ۵) ایجاد سیستم‌های پیچیده آنچه در مورد مراحل ایجاد سیستم در بخش ۱ گفته شد مراحل عمومی همه سیستم‌ها بود. اما در سیستم‌های پیچیده این مراحل به تنهایی نمی‌توانند پاسخگوی ما باشند. در سیستم‌های پیچیده ممکن است نیازها و مسائل به خوبی تعریف نشده باشند. سفارش دهنده سیستم تصویر و آگاهی کامل از آنچه که مطلوب اوست ندارد. نیازهای وی ممکن است با هم سازگار نباشند. ساختار سیستم مانند سیستم‌های معمول تعریف شده نیست. مفاهیم و مبانی سیستم موجود نیستند یا مدون نشده‌اند. روشهای کمی و استفاده ازروشهای تحلیلی نمی‌تواند همه ابعاد سیستم را مورد بررسی قرار دهد چرا که خیلی از عناصر، ویژگیهای آنها و تعامل آنها با دیگر عناصر دارای مبانی روشن، تعریف شده و کمی نیستند. مهندسی سیستم نمی‌تواند به صورت کامل مفاهیم و مبانی سیستم را تعریف و تدوین نماید. خروجی‌های سیستم به سادگی قابل پیش‌بینی نیستند. عوامل اجتماعی، سیاسی، اقتصادی و فناورانه زیادی بر سیستم تأثیر می‌گذارند. شرایط فوق باعث می‌شوند در کنار توسعه مهندسی سیستم‌ها، حوزه معماری سیستم‌ها نیز شکل گرفته و توسعه یابد که ریشه در مقایسه مهندسی ساختمان و معماری ساختمان و رابطه بین آنها دارد. مهندس ساختمان با استفاده از اصول مهندسی سعی در ارائه طرحی دارد که دارای ویژگیهای فنی و کاربری مورد نیاز بوده و نکات مهندسی در آن رعایت شده باشد. اما معمار ساختمان سعی در ارائه ساختاری دارد که تا حد ممکن منطبق بر نیاز مشتری باشد و عوامل اقلیمی، فرهنگی، زیباشناختی، همخوانی با محیط و غیره در آن رعایت شده باشند. بخشی از کار معمار ساختمان هنری و ذهنی است که از تجربه، شناخت و بینش حاصل شده است و جنبه کمی و مهندسی ندارد. ۶) معماری سیستم‌ها معماری در پاسخ به مسائل بسیار پیچیده‌ای ظاهر می‌شود که نمی‌توانند با استفاده از قواعد و رویه‌های از پیش وضع شده حل شوند. تعریف کلاسیک معماری عبارتست از «طرح‌ریزی و ساخت ساختارها». اگر واژه «ساختار» در سطح وسیع‌تری شامل آرایش‌ها و ترکیب‌ها، چارچوب‌ها و شبکه‌ها و سیستم‌ها فرض شود آنگاه معماری سیستم‌ها، طرح‌ریزی و ساخت سیستم‌هاست. معماری سیستم‌ها ترکیبی از اصول و مفاهیم سیستم‌ها و معماری است. به بیان دیگر معماری سیستم‌ها، نظریه سیستم‌ها و مهندسی سیستم‌ها را با نظریه، رسم و رسوم و حرفه معماری ترکیب می‌کند. هسته معماری در مفهوم‌سازی۴ سیستم است. در زیر مقایسه‌ای بین واژگان معماری و مهندسی شده است: ساختار۵ (یا معماری۶ ) ماشین۷ معماری۸ مهندسی۹ معمار۱۰ مهندس۱۱ اساس معماری، ساختاربندی ۱۲ است. ساختاربندی یعنی تبدیل شکل۱۳ به کارکرد۱۴ ، ایجاد نظم و ترتیب در هرج و مرج یا تبدیل ایده‌های ناقص شکل گرفته یک مشتری به یک مدل مفهومی عملی. ایجاد تعادل بین نیازها، هماهنگ کردن فصل مشترک‌ها و بین افراط و تفریط حد واسط را گرفتن، فنون کلیدی ساختاربندی هستند. ۷) معماری سیستم‌ها در مقابل مهندسی سیستم‌ها یک بعد از مقایسه معماری و مهندسی سیستم‌ها، بررسی جایگاه آنها در مراحل ایجاد سیستم‌هاست. در شکل ۴ مدل آبشاری ترسیم شده از مراحل ایجاد سیستم در بخش ۱، توسعه داده شده و جایگاه معماری سیستم‌ها در آن مشخص شده است. جایگاه معماری چه در شکل زیر و چه در عمل، به جای اینکه به طور مستقیم در جریان ایجاد سیستم قرار گیرد در یک طرف آن قرار داشته و موازی با آن است. ارتباط بین مشتری و معماری باید خیلی قوی باشد به گونه‌ای که اغلب معمار نماینده مشتری است حتی اگر از جهت قراردادی به واسطه سازنده یا شخص ثالثی استخدام شده باشد. همانگونه که ملاحظه می‌شود در سیستم‌های پیچیده اجتماعی عوامل متعدد بیرونی وجود دارند که بر فرایند ایجاد سیستم‌ها تأثیر می‌گذارند. عوامل اجتماعی و سیاسی، پایایی و عناصر جهان واقعی به جریان اصلی ایجاد سیستم‌ها وصل شده‌اند. در این شکل هر چه ضخامت خط بیشتر باشد نشان دهنده ارتباط بیشتر و قوی‌تر است. معماری معمولاً با تولید یک توصیف ذهنی یا نوشتاری مجرد (یک مدل) از سیستم و محیطش آغاز می‌شود. گامها و شاید سالهای زیادی بین این تجرد و ارزیابی نهایی وجود دارد. دقیقاً قبل از اینکه ارزیابی کامل شود، سیستم با جهان واقعی روبرو می‌شود. عدم آگاهی از این که جهان واقعی می‌تواند کاملاً متفاوت از مدل مفهومی معمار از جهان باشد خیلی از ساختارهای پیش از این عقلایی را با مشکل مواجه ساخته است. فرضیات تست خواهند شد و شاید ناقص شناخته شوند. نظریه‌ها، ایده‌ها و طرح‌ها تست خواهند شد. جهانی که سیستم در آن به وجود خواهد آمد احتمالاً در هنگام ساخت سیستم تغییر خواهد کرد. کار یک معمار سیستم این است که ساختاری در شکل یک سیستم از جهان بدساخت یافته و ذاتاً نامحدود از نیازهای بشری، فناوری، اقتصاد، سیاست، مهندسی و امور صنعتی تولید نماید. معمار سیستم باید اصول مهندسی که هر ساختار بر آن بنا می‌شود را بداند. در این راه تجربه و قدرت تشخیص ضروری است و معمار باید بینش حاصل از تجارب قبلی را کسب نماید. مسئله معمار این است که پیچیدگی را به درجه‌ای قابل کنترل کاهش دهد، خصوصاً تا جایی که بتوان آن را با فنون قدرتمند تحلیل مهندسی بررسی نمود. تنها باید کارکردهای ضروری را مد نظر قرار داد. به‌ منظور داشتن جوابهایی در حدود عملی، باید محدودیتهایی را بکار بست. بنابراین معمار یک «مهندسی عمومی» نیست بلکه متخصص در کاهش پیچیدگی، عدم قطعیت و ابهام به مفاهیم عملی است. از جهت نظری سیستم‌ها دارای مرز مشخصی نیستند یا به عبارت دیگر مرز ندارند. اما در عمل در مطالعه سیستم‌ها مرزی برای سیستم تعریف می‌کنند. این کار برای سیستم‌های پیچیده خیلی مشکل‌تر بوده و حتی ممکن است نشدنی باشد. یکی از تفاوتهای معماری با مهندسی و روش علمی در این نقطه اتفاق می‌افتد. در مهندسی مرز تعریف شده خوبی برای سیستم یا مسئله سیستم تعریف می‌کنند و سپس یک راه حل محدود شده و مشخص۱۵ ارائه می‌کنند. اما در معماری از آنجایی که با سیستم‌های پیچیده و بدون مرز روبرو هستیم، معمار به جای راه‌ حل، ساختاری خلق می‌کند که جواب رضایت‌بخشی برای مسئله تولید خواهد کرد. این ساختار، ساختاری باز۱۶ خواهد بود که می‌تواند خود را با رخدادها و شرایط متغیر تطبیق دهد. معماری به تعیین ساختار بهتر کمک می‌کند، یعنی کمک می‌کند که اولویت‌های نسبی، عملکرد قابل پذیرش، هزینه و زمان‌بندی، به حساب آوردن عواملی مانند ریسک فناوری، اندازه بازار برآورد شده، حرکت‌های رقابتی احتمالی، روندهای اقتصادی، نیازمندی‌های نظارتی سیاسی، سازمان پروژه و قابلیت‌های مربوط (قابلیت دسترسی، قابلیت عملیاتی، قابلیت ساخت، قابلیت بقاء و غیره) مد نظر قرار گیرند و در پایان پروژه، معماری، تکمیل و عملیات رضایت‌بخش سیستم را تأیید می‌کند. مهندسی تمایل به تمرکز بر فصل‌ مشترک‌های زیر سیستم‌های تعریف شده، تحلیل و اجرای مشخصات دارد. معماری تمایل به تمرکز بر مفاهیم، خلق، مشخصات سطح بالا، فصل مشترک‌های فنی و غیر فنی و موفقیت در مأموریت دارد. تعداد مهندسین بیشتر است.تعداد معماران کمتر است زیرا ساختارها محصول یک ذهن تنها یا یک تیم کوچک هستتند تا یکپارچگی ساختار درست شده حفظ شود. با وجود این تفاوتها، معماری و مهندسی دو سر طیفی از کارهای سیستمی هستند. معماری و مهندسی نقش‌هایی هستند که توسط مشخصه‌هایشان از یکدیگر متمایز می‌شوند. مهندسین اغلب نقش‌هایی را در طول طیف اتخاذ می‌کنند. از آنجایی که موفقیت بستگی به هر دو، یعنی ساختار دست یافتنی و پیاده‌سازی موفقیت‌آمیز آن، دارد ضرورتاً معمار و مهندس مسئول موفقیت یکدیگر هستند. در معماری باید ساختارها، روانشناسی، هنر و زیبایی‌شناسی در کنار هم گرد بیایند. همه اینها نیز باید با محیط فیزیکی و اجتماعی و سیستم مورد مطالعه سازگار باشند. بنابراین معماری هم علم است و هم هنر. شق علمی آن مبتنی ‌بر تحلیل، واقعیت بنیاد، منطقی، و استنتاجی است. شق هنری آن مبتنی بر خلق و تولید، شهودی، نقادانه و استقرایی است. هر دو شق برای تکمیل معماری یک سیستم پیچیده و مدرن ضروری است. ۸) متدولوژی‌های فرایند معماری مهمترین متدولوژی‌ها در فرایند معماری عبارتند از: ۱) تجویزی۱۷ (مبتنی بر راه‌ حل؛ مانند: دستورعمل‌های ساخت و استانداردهای شبکه) ۲) عقلایی۱۸ (مبتنی بر روش حل؛ مانند: تحلیل و مهندسی سیستم‌ها) ۳) مشارکتی۱۹ (مبتنی بر ذینفع؛ مانند: مهندسی همزمان و طوفان مغزی) ۴) هیوریستیک۲۰ (درس‌های فراگرفته؛ مانند: ساده کنید. ساده کنید. ساده کنید.) دو متدولوژی اول بیشتر دارای محتوای علمی هستند و دو متدولوژی آخر بیشتر محتوای هنری دارند. متدولوژی تجویزی مبتنی بر راه‌ حل است؛ این روش ساختاری را تجویز می‌کند به این شکل که «ساختار باید اینگونه باشد‍». مانند دستنامه‌ها، دستورعمل‌های ساختمان‌سازی، و بیانیه‌های معتبر. از آنها پیروی کنید و بنابر تعریف، نتیجه موفقیت‌آمیز خواهد بود. محدودیتهای روش تجویزی (مانند پاسخ به تغییرات عمده در نیازها، اولویت‌ها یا شرایط) منجر به روش عقلایی شده است یعنی اصول علمی و ریاضی باید در رسیدن به یک جواب برای مسئله دنبال شوند. این روش مبتنی بر روش حل و قواعد است. هر دو روشهای تجویزی و عقلایی تحلیلی، استنتاجی، مبتنی بر تجربه، به راحتی قابل تأیید، خوب شناخته شده و در سطح وسیعی در علم و صنعت تجربه شده‌اند. در مقایسه با متدولوژی‌های مبتنی بر علم، هنر یا حرفه معماری (مانند حرفه پزشکی، حقوق و بازرگانی) غیر تحلیلی، استقرایی، به سختی قابل تأیید، کمتر شناخته شده و حداقل تا سالهای اخیر به‌ ندرت در علم یا صنعت به‌صورت رسمی تدریس شده‌اند. هنر یا حرفه معماری فرایندی از بینش‌ها، دید، شهود و الهام، آراء تشخیص و تمیز و حتی سلیقه و ذوق است. معماری کلید خلق انواع واقعاً نو از سیستم‌ها برای کاربردهای نو و اغلب بی‌سابقه است. متدولوژی مشارکتی واقف بر پیچیدگی به‌ وجود آمده توسط ذینفعان متعدد است. هدف این روش اتفاق نظر است. در خیلی از موارد تنها باید مشتری، معمار و پیمانکار اتفاق‌ نظر داشته باشند اما وقتی که سیستم‌ها پیچیده‌تر می‌شوند مشارکت‌کنندگان جدید و متفاوتی باید توافق داشته باشند. مهندسی همزمان۲۱ برای کمک به دستیابی به اتفاق‌نظر بین مشارکت‌کنندگان توسعه داده شده است. بیشترین ارزش آن و بیشترین استفاده آن برای سیستم‌هایی است که در آنها همکاری گسترده برای پذیرش و موفقیت ضروری است. برای مثال، سیستم‌هایی که مستقیماً روی بقا افراد یا مؤسسات تأثیر می‌گذارند. ضعف‌های شناخته شده این روش عبارتند از: طرح نامعقول اجرای روش توسط کمیته، طوفان مغزی انحرافی، اذهان بسته تفکر گروهی و افراد بدون قدرت تصمیم‌گیری اما با حق خارج از کنترل برای انتقاد کردن. متدولوژی هیوریستیک‌ها مبتنی بر «شعور۲۲» است یعنی مبتنی بر چیزی که در یک موقعیت و شرایط مفروض، ملموس و محسوس است. شعور مربوط به یک شرایط و اوضاع و احوال، از تجربه عمومی بدست می‌آیند که در ساده‌ترین و خلاصه‌ترین شکل ممکن بیان شده‌اند. این بیانیه‌ها هیوریستیک نامیده می‌شوند و از اهمیت خاصی در معماری برخوردارند زیرا راهنماییهایی در فراز و نشیب مسائل سیستمی دشوار و خطرناک ارائه می‌کنند. به‌عنوان مثال «ساده کنید»، یکی از مهمترین هیوریستیک‌هاست و منظور آن ساده‌سازی سیستم با استفاده از مدلسازی و حذف موارد غیرضروری است. ماهیت معماری کلاسیک در حین حرکت پروژه از یک مرحله به مرحله دیگر تغییر می‌کند. در مراحل اولیه پروژه، معماری، ساختاربندی یک مخلوط ساخت نیافته از رویاها، امیدها، نیازها و امکانات فنی است. در این مراحل چیزی که بیشتر از همه نیاز است یک خلق یا تولید الهام گرفته از فناوری‌های عملی است. در این‌جا هنر معماری نیاز است. سپس، معماری، هماهنگ‌سازی زیر سیستم‌ها و علایق است و در این مقطع، زمان متدولوژی عقلایی و تجویزی فرا می‌رسد.