تهیهی منشور ساپ

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

جای تصویر/شکل: شکل 3.3- تهیه منشور ساپ – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• تهیهی منشور ساپ: ورودی‌ها
• منشور پروژه: مهمترین سندی که مشخص کنندهی وضعیت و شرایط پروژه می‌باشد، منشور پروژه است که در آن اهداف پروژه، نیازمندیهای کلان پروژه، ریسک‌های کلان، زمانبندی اتفاقات مهم، معرفی مدیر و تیم پروژه و سطح اختیارات آنها که بر اساس این اطلاعات شرایط پروژه سنجیده شده مورد تحلیل قرار خواهد گرفت.
• منشور ساپ سازمانی: در صورتی‌که ساپ پروژه در زیر مجموعه یک ساپ سازمانی انجام ‌گردد، لازم است این مستند به عنوان سیاستگذاری‌های کلی ساپ در سازمان مورد استفاده این فرآیند قرار گیرد. این سند در بخش 4.2.2.1 معرفی شده است.
• دارایی‌های فرآیندی سازمانی: دارایی‌های فرآیندی سازمانی که می‌تواند بر فرآیند تهیهی منشور ساپ تاثیر بگذارد شامل موارد زیر است که البته محدود به این موارد نیست:
• فرآیندهای استاندارد شده در تعیین و نحوهی خدمات فاوا در سازمان
• الگوهای موجود در منشور ساپ
• تجربیات کسب شده در اجرای ساپ در پروژههای قبلی یا در سازمان
• فاکتورهای محیطی سازمان: فاکتورهای محیطی تاثیرگذار بر این فرآیند عبارتند از :
• برنامهی فاوای سازمان
• برنامهی ساپ سازمان
• مستندات زیرساخت فاوای سازمان و پروژه
• مستندات بلوغ سازمان از جمله OPM3، EFQM، CMMI، …
• مستندات ممیزی کیفیت سازمان و پروژههای قبلی
• تهیهی منشور ساپ : ابزار و تکنیک‌ها
• شورای ساپ: یکی از تکنیک‌هایی که میتواند بسیار کارا در مدیریت ساپ پروژهها و سیاستگذاری موثر در این حوزه باشد، تشکیل شورا یا کمیته‌ای با نام شورای ساپ است. این شورا در بخش 2.6.1 شرح داده شده است. پس از تشکیل این شورا و بررسی شرایط پروژه و سازمان و با استفاده از نظر سایر کارشناسانی که میتوانند به صورت موردی مورد استفاده قرار گیرند، سند منشور ساپ توسط مدیر ساپ یا مدیر پروژه ساپ تهیه و در این شورا مورد بررسی و تایید قرار خواهد گرفت. معمولاً این شورا باید در فاز آغازین پروژه شکل بگیرد.
• تهیهی منشور ساپ: خروجی‌ها

منشور ساپ در حقیقت سندی راهبردی در پیشبرد اهداف ساپ است که برای هر پروژه تهیه میگردد. در این سند ضمن بیان و تشریح شرایط پروژه و سازمان، اهداف کلان و استراتژیهای کلان ساپ در پروژه بیان شده و به تایید مسئولین ذیربط در پروژه و سازمان میرسد. بعضی از مواردی که در این مستند قابل بیان است، عبارتند از:

• اهداف و شرایط پروژه و سازمان
• نیازمندیهای کلان پروژه
• زمانبندی کلان پروژه
• ریسک‌های کلان پروژه
• سازمان و مسئولیتهای پروژه
• شرایط زیرساخت پروژه و سازمان
• بیان وضعیت فاوای پروژه و سازمان
• بیان وضعیت فرهنگی فاوا در پروژه و سازمان
• مهمترین اهداف ساپ پروژه
• معرفی مدیر ساپ و ساختار کلی تیم ساپ و مسئولیتها و سطح اختیارات هر یک
• بیان کلان تحلیل ساپ در پروژه
• بیان استراتژی ساپ در پروژه

تهیه برنامه ساپ

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

جای تصویر/شکل: 3.4 – تهیه برنامه ساپ – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

شناسايي ذي‌نفعان پروژه

فرآیند شناسایی تمامی افراد یا سازمان‌های اثرپذیر از پروژه و مستندسازی اطلاعات مرتبط با تمایلات و اثر آنها بر موفقیت پروژه است. این فرآیند همان فرآیند 10-1 پم‌باك می باشد که با خلاصه‌نویسی و اندکی تغییر در اینجا ارائه می گردد. جهت اطلاعات بیشتر میتوانید به بخش مربوط در پم‌باك مراجعه کنید.

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

جای تصویر/شکل: 3.5 – ارتباط بین ذینفعان و پروژه

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

جای تصویر/شکل: 3.6 -شناسایی ذی‌نفعان پروژه – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• شناسایی ذی‌نفعان پروژه: ورودی‌ها
• منشور پروژه : یک سند رسمی است که یک پروژه یا یک فاز از پروژه را تصویب و معرفی کرده و نیازمندیهای اولیه را که انتظارات و نیازهای ذی‌نفعان را تامین مینماید، ثبت میکند. این سند در بخش 4-1 مدیریت یکپارچگی پروژه از راهنمای پم‌باك شرح داده شده است. این سند در این فرآیند در رابطه با بخشهای داخلی و خارجی درگیر در پروژه و تاثیرپذیری آنها اطلاعاتی در اختیار قرار می‌دهد.
• مستندات تامین: اگر پروژه دارای قرارداد باشد، طرفهای قرارداد، ذی‌نفعان کلیدی پروژه خواهند بود. همچنین تامین‌کنندگان نیز باید به عنوان بخشی از فهرست ذی‌نفعان مورد توجه قرار گیرند.
• دارایی‌های فرآیندی سازمانی: این موضوع در فصل اول توضیح داده شده است. این موضوع در این فرآیند میتواند با الگوهای موجود جهت ثبت ذی‌نفعان، درسهای آموخته از پروژههای گذشته و ذی‌نفعان ثبت شده در پروژه‌های قبلی مورد استفاده قرار گیرد.
• فاکتورهای محیطی سازمان: این موضوع در فصل اول توضیح داده شده است. تاثیر این موضوع در این فرآیند، آشنایی با ساختار و فرهنگ سازمان و همچنین استفاده از مقررات و استانداردهای مربوط است.
• شناسایی ذی‌نفعان پروژه: ابزارها و تکنیک‌ها
• تحلیل ذی‌نفعان : یک نوع تکنیک در بررسی کمی و کیفی از ذی‌نفعان است که بر روی علایق، انتظارات و اثر ذی‌نفع تحلیل نموده و ارتباط آنها با اهدافِ پروژه/سازمان را مشخص مینماید. این بررسی با رویکرد افزایش بهره‌وری و همسویی در اهداف پروژه انجام میگردد. جهت اطلاعات بیشتر به بخش 10-1-2 پم‌باك و همچنین استاندارد گسترهی دانش تحلیل کسب‌وکار BABOK مراجعه نمایید.(بخشی از تکنیک‌ها در بخش 3.1.4 اشاره شده است)
• نظر کارشناسان: یکی از روشهای مورد استفاده در تهیهی فهرست ذی‌نفعان استفاده از نظر کارشناسانی است که در این زمینه دارای تجربه و اطلاعات هستند. بعضی از این افراد عبارتند از : مدیران ارشد، ذی‌نفعان کلیدی شناسایی شده، مدیران پروژه‌ها، کارشناسان تخصصی در حوزهی تخصص خودشان، مشاوران .
• شناسایی ذی‌نفعان پروژه: خروجی‌ها
• فهرست ذی‌نفعان: خروجی این فرآیند فهرستی کامل از همه ذی‌نفعان مرتبط با پروژه با مشخصات و برخی اطلاعات ارزیابی آنها است. این فهرست می‌تواند شامل اطلاعات زیر باشد:
• مشخصات شناسایی از جمله: نام، سازمان، سمت در سازمان، سمت در پروژه ، اطلاعات تماس
• اطلاعات ارزیابی: نسبت تاثیر در پروژه، نسبت کلیدی بودن ذی‌نفع، شرح نیازمندیها، خواستهها و تمایلات، مقدار سواد کامپیوتری، نوع علاقه‌مندی به دریافت گزارشات کاغذی یا الکترونیکی ….
• نوع تعامل با ذی‌نفع: با توجه به استراتژیهایی که در پروژه یا سازمان وجود دارد، باید مشخص شود که نوع رفتار اطلاعاتی از دیدگاه سطح دسترسی به اطلاعات و اهمیت اطلاعات با هر گروه از ذی‌نفعان به چه نحوی خواهد بود.

استخراج نیازمندیهای اطلاعاتی

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

اطلاعات مورد نیاز در هر پروژه را می‌توان به دو دستهی کلی تقسیم بندی نمود:

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

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

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

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

نیازمندی چیست؟ طبق تعریف BABOK نیازمندی عبارت است از:

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

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

نیازمندیها را میتوان به بخشهای زیر تقسیمبندی کرد:

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

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

جای تصویر/شکل: 3.7 – شناسایی اطلاعات مورد نیاز ذی‌نفعان – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• استخراج نیازمندی‌های اطلاعاتی: ورودی‌ها
• منشور پروژه: این مستند خروجی فرآیند تهیهی منشور پروژه در بخش 4.1.3 پم‌باك می‌باشد. به منظور درک وضعیت و شرایط پروژه، تحلیل‌گران و مصاحبه‌کنندگان می بایست اطلاعات این مستند را که در بخش 3.1.1 توضیح داده شده است مطالعه نموده و در هنگام مواجهه با ذی‌نفعان، تعامل مناسبی بر اساس اهداف کلان پروژه برقرار نمایند.
• فهرست ذی‌نفعان: این فهرست مبنای بررسی نیازمندیهای اطلاعاتی ذی‌نفعان قرار می گیرد. با توجه به درجه اهمیت هر یک از ذی‌نفعان و با استفاده از تکنیک‌های ارائه شده در این فرآیند نیازمندیهای اطلاعاتی این گروه استخراج خواهد گردید.
• مستند نیازمندیهای پروژه: این مستند که یکی از خروجی‌های فرآیند جمع آوری نیازمندی‌های پروژه در مستند پم‌باك است، در فصل 3.1.3 ارائه و شرح داده شده است. در این مستند فهرستی از نیازمندیهای اصلی و تفصیلی پروژه در جهت تامین اهداف پروژه ارائه گردیده. اگر در پروژه‌ای چنین مستندی وجود نداشته باشد، می‌بایست قبل از انجام این فرآیند این مستند توسط تیم تحلیلگر تولید گردد.
• دارایی‌های فرآیندی سازمانی: داراییهای فرآیندی مورد استفاده در این فرآیند عبارتند از:
• درس های آموخته شده از پروژههای قبلی
• فهرست اطلاعات مورد نیاز پروژههای قبلی
• فاکتورهای محیطی سازمان: موارد استفاده در این فرآیند عبارتند از :
• سیستم اطلاعات پروژهی سازمان
• سیستم‌های اطلاعاتی مورد استفاده در پروژه
• ورودی و خروجیهای نرم افزارهای مدیریت پروژه در سازمان
• استخراج نیازمندی‌های اطلاعاتی: ابزار وتکنیک‌ها
• تکنیک‌های تحلیل کسب‌وکار: در راهنمای BABOK نسخه دو سی‌وچهار (34) تکنیک به منظور تحلیل موفق یک کسبوکار ارائه شده است. فهرست زیر بخشی از این تکنیکها را نشان میدهد:

جای تصویر/شکل: 3.1 – بخشی از تکنیک‌های تحلیل بر اساس BABOK 2

در اینجا به شرح مختصری از برخی از این تکنیک‌ها میپردازیم:

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

شناسایی خروجی های فرآیندهای پروژه

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

جای تصویر/شکل: 3.8- شناسایی خروجی‌های فرآیندهای پروژه – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• شناسایی خروجی‌های فرآیندهای پروژه: ورودی‌ها
• فرآیندهای مدیریت پروژه: فرآیندهای مدیریت پروژه، طبق تعریف پم‌باك ابزار و تکنیک‌هایی جهت استفاده از مهارتها و توانایی‌های تشریح شده در حوزههای دانش را در بر میگیرند. این فرآیندها در نسخه چهارم پم‌باك 42 فرآیند می‌باشند که در قالب 5 گروه فرآیندی تقسیم بندی شده‌اند. این فرآیندها در فصل اول به‌صورت خلاصه توضیح داده شده است. هدف از بررسی این فرآیندها استخراج خروجی‌های فرآیندها در قالب نیازمندیهای اطلاعاتی میباشد. البته ممکن است کلیهی فرآیندهای مدیریت پروژه در یک پروژه مورد استفاده قرار نگیرد و یا نیازمند متناسب سازی باشد. مسئولیت انتخاب یا متناسبسازی فرآیندهای مدیریت پروژه با مدیر و تیم مدیریت پروژه است. تیم ساپ باید مطمئن شود که این فرآیندها برای پروژه مورد نظر متناسب سازی و تایید شده است. ولی انجام عملیات تناسبسازی در مسئولیت تیم ساپ نخواهد بود.
• فرآیندهای مبتنی بر محصول: این فرآیندها، محصول پروژه را مشخص و ایجاد می‌کنند. فرآیندهای مبتنی بر محصول، معمولاً توسط چرخهی عمر پروژه تعریف شده و بر اساس حوزهی کاربرد، متفاوت میباشند. محدودهی پروژه را نمی‌توان بدون درک اساسی از چگونگی ایجاد یک محصول مشخص، تعریف نمود. این گروه از فرآیندها در تعامل نزدیک با فرآیندهای مدیریت پروژه و سایر فرآیندهای سازمان میباشند. توجه به تعاملات فرآیندی در یک پروژه و برقراری توازن بین آنها از وظایف مهم تیم مدیریت پروژه است. تیم ساپ باید مطمئن شود که این توازن بین این فرآیندها برقرار شده است.
• فهرست ذی‌نفعان: این فهرست در بخش 3.1.3 توضیح داده شده است. اطلاع از اینکه ذی‌نفعان کلیدی پروژه چه کسانی هستند در برقراری ارتباط با آنها و تحلیل نیازمندیهای اطلاعاتی در بخش فرآیندهای مدیریت پروژه و محصول الزامی است.
• شناسایی خروجی‌های فرآیندهای پروژه: ابزار و تکنیک‌ها
• تکنیک‌های تحلیل کسب‌وکار: کلیهی مطالب ارائه شده در بخش 3.1.4 در این قسمت نیز مورد استفاده است.
• شناسایی خروجی‌های فرآیندهای پروژه: خروجی‌ها
• فهرست نیازهای اطلاعاتی پروژه و محصول: این فهرست که می‌تواند به صورت یک سند فیزیکی یا الکترونیکی منتشر گردد، فهرستی از اقلام اطلاعاتی مربوط به ورودی‌ها و خروجی‌های فرآیندهای مدیریت پروژه و محصول است. این فهرست، نتیجه بررسی و تحلیل بر روی فرآیندهای پروژه و محصول در طول چرخهی حیات پروژه بوده که منجر به استخراج اقلام اطلاعات مهم پروژه خواهد شد. اجزای این سند می‌تواند شامل موارد زیر باشد که محدود به این موارد نمی‌باشد:
• فهرست نیازمندیهای عملکردی به تفکیک خروجی‌ها و فرآیندها
• فهرست نیازمندیهای غیرعملکردی تحلیلشده به تفکیک خروجی‌ها و فرآیندها
• فهرست اقلام اطلاعاتی مرتبط با نیازمندی ارائه شده و ذی‌نفع درخواست کننده در خروجی فرآیندها
• فرضیات و محدویت‌های شناسایی شده
• ارتباط بین عناصر اطلاعاتی از نظر ارتباط ایجادی یا وابستگی

طراحی محتوی، شکل و نوع خروجی های مورد انتظار

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

جای تصویر/شکل: 3.9- طراحی محتوی، شکل و نوع خروجی‌های مورد انتظار- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

برنامه ریزی تامین و توزیع اطلاعات

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

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

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

جای تصویر/شکل: 3.10- برنامه ریزی تامین و توزیع اطلاعات – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• برنامه‌ریزی تامین و توزیع اطلاعات: ورودی‌ها
• برنامه مدیریت ارتباطات: این مستند خروجی فرآیند برنامه‌ریزی ارتباطات در بخش 10.2.3 پم‌باك است. در این مستند به نیازمندی‌های ارتباطی، علت توزیع اطلاعات، چارچوب‌های زمانی و توالی توزیع اشاره شده است. اگر چنین مدرکی تهیه نشده باشد تیم ساپ باید چنین مدرکی را قبل از انجام این فرآیند تامین نماید.
• فهرست نیازمندیهای اطلاعاتی ذی‌نفعان: فهرست اطلاعات مورد درخواست ذی‌نفعان است که در بخش 3.1.3 توضیح داده شد.
• فهرست خروجی‌های اطلاعاتی پروژه و محصول: فهرست اقلام اطلاعاتی در فرآیندهای مدیریت پروژه و محصول است که نیازمند تامین و توزیع هستند.
• فرآیندهای مدیریت پروژه و محصول: به منظور مشخص نمودن فرد مسئول، نحوهی تامین و توزیع، چارچوب زمانی تامین و توزیع لازم است کلیهی فرآیندهای فعال مدیریت پروژه و محصول مورد استفاده قرار گرفته و از روی آنها نحوهی تامین و توزیع مشخص گردد.
• قرارداد‌ها: از مدارک مهمی است که تعهدات و الزامات ارتباطی، در تعامل با طرفین قرارداد‌ها را مشخص نموده و در این فرآیند استفاده خواهد شد.
• دارایی‌های فرآیندی سازمانی: فرآیندهای استفاده شده در سایر پروژه‌ها و یا واحدهای عملیاتی مرتبط با پروژه، الگوهای سایر پروژهها در این خصوص، از جمله موارد‌ی هستند که در این فرآیند مورد استفاده قرار خواهند گرفت.
• برنامه‌ریزی تامین و توزیع اطلاعات: ابزار و تکنیک‌ها
• شیوه‌های ارتباطات: جلسات فردی و گروهی، کنفرانس‌های ویدیویی و صوتی، چت‌های کامپیوتری و دیگر روشهای از راه دور ارتباطی، می‌توانند در توزیع اطلاعات استفاده شوند.
• روش RAM (ماتریس تخصیص مسئولیت): از این روش به جهت تشریح ارتباط بین مسئولیت‌های تامین و توزیع اطلاعات و اعضای تیم پروژه یا سازمان استفاده می‌شود. در پروژههای بزرگ‌تر، ماتریس تخصیص مسئولیت را می‌توان در سطوح مختلف سازمان پروژه توسعه داد. در این روش جدولی تهیه می‌شود که در ستون اول نوع فعالیت تولید یا توزیع اطلاعات آمده و در ستونهای بعدی مسئولیتهای سازمانی برای انجام این فعالیت مشخص میشود.
• روش RACI : این روش نیز نمونه‌ای از ماتریس تخصیص مسئولیت است، با این تفاوت که از چهار کلمه R)) به عنوان مسئول، ((A به عنوان پاسخگو، (C) برای مشورت کردن و (I) برای آگاهی دادن برای مشخص کردن نوع مسئولیت استفاده می شود. البته این روش را می توان با استفاده از تغییر این کلمات یا اضافه کردن کلمات دیگری توسعه داد. نمونه ای از این جدول به شکل زیر می باشد:
• برنامه‌ریزی تامین و توزیع اطلاعات: خروجی‌ها
• ماتریس تامین و توزیع اطلاعات: ماتریس تامین و توزیع اطلاعات مستندی است که مشخص می‌کند چه اطلاعاتی باید توسط چه کسانی تولید شده و بین چه کسانی توزیع شود. زمانهای تولید و توزیع نیز در این مستند مشخص میگردد. نمونهای از این ماتریس را در جدول زیر ملاحظه میفرمایید. این شکل میتواند با توجه به نیاز هر پروژه، تغییر نماید. میتوان از کلمات مخفف به عنوان نوع مسئولیت یا زمان استفاده نمود.

طبقه بندی اطلاعات و تعریف دسترسی‌ها

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

جای تصویر/شکل: 3.11- طبقه بندی اطلاعات و تعریف دسترسی‌ها- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

انواع دسترسی‌ها: دسترسی‌ها معمولا در یکی از سطوح زیر دستهبندی میگردند که البته محدود به این موارد نیستند:

• ایجاد /تولید : امکان ایجاد این قلم اطلاعاتی (معمولاً در سیستم‌های مکانیزه) را دارد.
• مشاهده / خواندن شخصی : امکان مشاهده اطلاعاتی را که توسط خود فرد ایجاد شده، دارد.
• مشاهده / خواندن سایرین: امکان مشاهدهی اطلاعاتی را که توسط سایرین ایجاد شده، دارد.
• ویرایش شخصی : امکان ویرایش اطلاعاتی را که توسط خود فرد تهیه شده ، پس از ایجاد دارد.
• ویرایش سایرین: امکان ویرایش اطلاعاتی را که توسط دیگران تهیه شده، دارد.
• حذف شخصی: امکان حذف اطلاعاتی را که خود فرد ایجاد کرده، دارد.
• حذف سایرین: امکان حذف اطلاعاتی را که سایرین ایجاد کرده‌اند، دارد.

برنامه ریزی نگهداری اطلاعات

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

جای تصویر/شکل: 3.12- برنامه‌ریزی نگهداری اطلاعات – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

طراحی پیکربندی اطلاعات

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

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

فعالیت‌هایی که در مدیریت پیکربندی انجام میشوند عبارتند از:

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

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

جای تصویر/شکل: 3.13 – طراحی پیکربندی اطلاعات- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

برنامه ریزی استقرار و عملیاتی سازی

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

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

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

جای تصویر/شکل: 3.23- برنامه ریزی استقرار و عملیاتی سازی – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

نصب و تنظیمات اولیهی سیستم‌ها

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

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

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

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

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

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

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

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

جای تصویر/شکل: 3.24- نصب و تنظیمات اولیه سیستم‌ها- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

منطبق سازی ابزاری فرآیندها

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

جای تصویر/شکل: 3.25- منطبق سازی ابزاری فرآیندها- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

آموزش کاربران

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

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

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

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

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

جای تصویر/شکل: 3.26- آموزش کاربران- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

عملیاتی سازی ساپ

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

جای تصویر/شکل: 3.27- عملیاتی سازی ساپ- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

راهبری ساپ

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

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

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

باید در نظر داشت که تامین نیروهای راهبری، آموزش و آمادهسازی آنها برای پاسخ‌گویی به نیاز کاربران کاری زمانبر است و نیاز دارد که راهبران دارای تجربه در امر راهبری باشند. لذا با توجه به اهمیت این موضوع لازم است موضوع تامین و یا جذب نیروهای راهبری از ابتدای پروژه شروع شده تا در زمان لازم این نیروها برای پروژه قابل استفاده باشند.

جای تصویر/شکل: 3.34- راهبری ساپ- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• راهبری ساپ: ورودی‌ها
• منشور ساپ: به منظور آگاهی از سیاستهای ساپ لازم است از این مستند در این فرآیند استفاده گردد.
• برنامهی ساپ: اطلاع از برنامه‌ریزی ساپ در پروژه از نیازمندی‌های این فرآیند است. نکتهی قابل توجه اینکه خروجی برنامهی راهبری ساپ، خود جزو ورودی‌های برنامهی ساپ است. در اینجا منظور از برنامهی ساپ، سایر برنامهها به‌غیر از این برنامه است تا با توجه به آنها برنامهی راهبری تنظیم گردد.
• استانداردهای خدمات فن‌آوری: آگاهی از استانداردهای خدمات‌رسانی، مخصوصاً خدماترسانی فن‌آوری اطلاعات مانند ITIL و یا ISO/IEC 20000 که مربوطه به مدیریت خدمات فاوا است، می‌تواند کمک نماید تا برنامه‌ریزی مناسبی به جهت پاسخ‌گویی به نیاز کاربران ساپ تدوین گردد.
• دارایی‌های فرآیندی سازمانی : استفاده از الگوهای موجود در راهبری ساپ در سایر پروژه‌ها یا راهبری در سطح سازمان از روش‌ها و فرآیندهایی است که برای این فرآیند بسیار قابل استفاده خواهد بود.
• فاکتورهای محیطی سازمان: ساختار سازمانی پروژه، سطح سواد فن‌آوری اطلاعات کاربران پروژه و محل فیزیکی اجرای پروژه از مواردی هستند که بر این فرآیند و نحوهی خدمت‌رسانی راهبری تاثیرگذار خواهند بود.
• راهبری ساپ: ابزارهای و تکنیک‌ها
• شورای ساپ: به دلیل اهمیت موضوع پشتیبانی و راهبری در ساپ لازم است، نیازمندی‌های راهبری از طریق شورای ساپ مورد بررسی و تایید قرار گیرد. این شورا مخصوصاً در خصوص توجه به اهمیت راهبری و تامین نیروی لازم می‌تواند بسیار کارگشا باشد.
• جذب نیرو: یکی از موارد مهم در حوزهی راهبری تامین راهبران باتجربه و مناسب است. راهبران ممکن است در خصوص سیستم‌های خاص شما تجربه ای نداشته باشند، ولی لازم است تا در خصوص مسائل عمومی راهبری، مانند آموزش کاربران، نحوهی برخورد با کاربران و رفع مشکلات سیستم‌ها تجربهی کافی داشته باشند. استفاده از تکنیک‌های مصاحبه و ارزیابی کارکنان در جذب نیرو از روش‌های مورد نیاز این فرآیند است.
• آمادهسازی راهبران: هر قدر که راهبران شما دارای تجربه در امور راهبری یا سیستم‌های خاص باشند، لازم است با شرایط پروژه و سازمان و روال‌های انجام کار آشنا شوند. این امور وقتگیر بوده و لازم است از ابتدای پروژه برای این مسائل تدبیر لازم در برنامهی راهبری اندیشیده شود.
• راهبری ساپ: خروجی‌ها
• برنامهی راهبری ساپ: سندی کاربردی است که مشخص‌کنندهی استراتژی‌های راهبری پروژه، نحوهی خدمت‌رسانی و پشتیبانی راهبری و مشخص کنندهی مسئولیت‌ها و فعالیت‌های راهبران است. این مستند می‌تواند شامل سرفصل‌های زیر باشد:
• استراتژی راهبری
• دامنهی کاربران مشمول راهبری
• تقسیمبندی کاربران از دیدگاه نحوهی خدمتگیری
• تعیین خدمات مورد انتظار راهبری با توجه به گروه‌های مختلف کاربران
• نحوهی برخورد با اشکالات در سیستم و دستورالعمل پیگیری
• نحوهی برخورد با تغییرات در سیستم و دستورالعمل ثبت و ردگیری
• نحوهی ثبت درس‌آموختههای ساپ
• تخصیص راهبران: پس از مشخص کردن تعداد مورد نیاز راهبران و تایید شورای ساپ لازم است، پس از تامین این راهبران این افراد برای انجام امور راهبری تخصیص یابند. در صورت عدم انجام چنین فعالیتی کلیهی عملیات راهبری با مشکل مواجه خواهد شد.

شناسایی، ثبت و رفع اشکالات ساپ

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

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

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

خطاها از دیدگاه نتیجهی خطا نیز در چند دسته قابل دسته بندی اند:

• خطایی که بوجود آمدن آن ادامهی استفاده از سیستم‌ را برای کاربر مربوطه مختل می‌کند.
• خطایی که ایجاد آن ادامهی کار کل سیستم را مختل می‌کند.
• خطایی که بر روی دادههای سیستم‌ خطا ایجاد می‌کند.
• خطایی که بر روی خروجی‌های سیستم خود را نشان می‌دهد.

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

• خطاهای مهلک: خطاهایی که وجود آنها باعث ایجاد مشکلات بسیار خطرناک در اطلاعات پروژه خواهد شد و باید بلافاصله برطرف شود.
• خطاهای مهم: خطاهایی که وجود آنها مهم است و باید در اسرع وقت بر طرف شود.
• خطاهای کم اهمیت: خطاهایی که بر طرف کردن آنها خوب است ولی ضروری نیست.

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

جای تصویر/شکل: 3.35- شناسایی، ثبت و رفع اشکالات ساپ- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

ثبت درسآموخته های ساپ

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

جای تصویر/شکل: 3.36- ثبت درس آموخته های ساپ- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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

رفع باگ و توسعهی سیستم‌ها

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

• خرید یک محصول از یک فروشندهی خارجی
• دادن سفارش به یک توسعه دهندهی خارجی
• ایجاد و توسعه به صورت داخلی

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

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

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

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

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

جای تصویر/شکل: 3.37- رفع باگ و توسعه سیستم‌ها – ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• رفع باگ و توسعهی سیستم‌ها: ورودی‌ها
• قراردادهای تامین‌کنندگان خارجی: به منظور آگاهی از تعهدات تامین‌کنندگان در رفع اشکالات و موارد توسعهای لازم است قراردادهای آنها در این فرآیند مورد مطالعه قرار گرفته و بر آن اساس روال‌های ارجاع و پیگیری اشکالات مورد توافق قرار گیرد.
• درخواست‌های رفع اشکال: یکی از محرک‌های راه‌اندازی این فرآیند، درخواست رفع اشکال است. همانگونه که در فرآیند شناسایی، ثبت و رفع اشکالات اشاره گردید، اشکالاتی به این فرآیند ارجاع داده خواهند شد که خارج از حیطهی راهبری بوده و نیازمند امور توسعهای نرم‌افزار است. این درخواست باید حاوی اطلاعاتی باشد که توسعهگران سیستم بتوانند از روی آن‌ها به اشکال اعلام شده دست پیدا کنند. فرمت این درخواست در فرآیند 3.5.2 مشخص گردیده است.
• درخواست‌های توسعه: هر گونه درخواست تغییر یا نیازمندی‌های جدید، باید در فرمتی مشخص شده که توسط این فرآیند معین خواهد گردید، ثبت شده و طبق روال‌های مشخص شده، پس از بررسی‌های لازم در صورتی‌که درخواست امکان‌پذیر تشخیص داده شد به توسعهدهندگان ارجاع گردد. درخواست توسعه باید شامل تمام اطلاعاتی که توسعهدهندگان برای بررسی و انجام این درخواست نیاز دارند باشد. جزئیات مورد نیاز با توسعهدهندگان توافق خواهد گردید.
• دارایی‌های فرآیندی سازمانی: فرآیندهای سازمان در مدیریت تغییرات نرمافزارها و یا روش‌های موجود در سایر پروژه‌ها می‌تواند در این فرآیند مورد استفاده قرار گیرد.
• فاکتورهای محیطی سازمان: الگوهای موجود سازمان در ثبت اشکالات و درخواست‌های موارد توسعه‌ای، ابزارهای مدیریت پشتیبانی سازمان، ساختار سازمانی پروژه و سازمان از مواردی هستند که به عنوان فاکتورهای محیطی در این فرآیند تاثیرگذار خواهند بود.
• رفع باگ و توسعهی سیستم‌ها: ابزارها و تکنیک‌ها
• جلسات پیگیری اشکالات: برگزاری جلسات ادواری به منظور پیگیری اشکالات اعلامشده و مذاکره در خصوص چگونگی رفع این اشکالات با گروهِ راهبری و توسعهدهندگان، می‌تواند باعث شفافیت و تسریع در رفع مشکلات باشد.
• نظر کارشناسان: به منظور تشخیص صحت درخواستهای اعلام شده از سوی کاربران و همچنین مشخصکردن اولویت و اهمیت درخواست‌ها استفاده از نظر کارشناسان الزامی است.
• کمیتههای فنی و تخصصی: در برخی از موارد که سنجش صحت یک درخواست پیچیده شده یا باعث اختلاف می‌شود تشکیل کمیته‌های فنی و تخصصی و بررسی این موارد در این‌گونه جلسات چارهساز بوده و مورد قبول همگان قرار خواهد گرفت.
• شورای ساپ: در هر جا که پیش‌بینی بروز اختلاف وجود داشته باشد و یا نیاز به حمایت مدیریتی احساس شود، نقش شورای ساپ بسیار مورد استفاده خواهد بود. در مواردی که درخواست‌های تغییر یا نیازمندی‌ها در انواع بررسی‌ها به چالش خورده و یا اینکه در این‌گونه امور اتفاق نظر حاصل نمی‌شود می‌توان از جایگاه شورای ساپ برای نهاییکردن تصمیمات در این خصوص بهره جست.
• ابزارهای مدیریت پشتیبانی: جهت شفافسازی ارتباط بین گروه راهبری و بخش توسعه چه در داخل سازمان و چه در خارج از سازمان می‌توان از ابزارهای مدیریت پشتیبانی جهت ارجاع مشکلات و موارد توسعه‌ای و پیگیری اینگونه امور استفاده نمود.
• رفع باگ و توسعهی سیستم‌ها: خروجی‌ها
• روال‌های هماهنگی با توسعهدهندگان: همانگونه که شرح داده شد لازم است با هر نوع از توسعهدهندگان، چه داخلی و چه خارجی روال‌های ارجاع، پیگیری و دریافت اشکالات و نیازمندی‌های توسعه‌ای توافق شده و بر آن اساس این امور به انجام برسد. این روال‌ها می‌تواند دستی یا مکانیزه باشد.
• فهرست وضعیت درخواست‌های توسعه‌ای: لازم است به منظور ثبت و ردیابی درخواستهای توسعه‌ای، بر اساس روال‌های هماهنگی با توسعهدهندگان فهرستی ایجاد گردد تا همیشه آخرین وضعیت هر درخواست مشخص بوده و قابل پیگیری باشد. این فهرست می‌تواند به صورت دستی یا الکترونیکی بوده و اطلاعات آن به صورت سطری یا تاریخچه‌ای ذخیره گردد. حتی با توجه به وسعت کار و بضاعت مجموعه یک سیستم اطلاعاتی برای آن در نظر گرفته شود.در این فهرست باید موارد زیر به ازای هر درخواست مشخص شده باشد:
• شمارهی درخواست
• شرح درخواست
• تاریخ اعلام درخواست.
• نام درخواستکننده
• نام سیستمی که درخواست به آن مربوط است.
• نوع درخواست
• اولویت درخواست
• فرد دریافتکننده درخواست
• شرح اقدامات انجام شده
• وضعیت درخواست (رفع شده/در حال پیگیری/ارجاع به پیاده ساز/در حال انجام/منتفی شده/خارج از الویت/غیر قابل انجام….)
• تاریخ تغییر آخرین وضعیت
• تاریخ ارسال به توسعهدهنده
• پیش بینی زمان انجام درخواست
• اعلام زمان‌های رفع اشکال و توسعههای درخواستی: پس از ارجاع اشکالات و درخواست‌های توسعه‌ای لازم است در روال‌های هماهنگی توافق شود که توسعهدهندگان موظف به اعلام زمان‌های رفع اشکال یا انجام موارد توسعه‌ای باشند.
• اعلام عدم امکان توسعهی درخواستی: در صورتی‌که انجام درخواست‌های توسعه‌ای امکانپذیر نباشد لازم است این موضوع در قالب مشخصی با ارائه دلایل مربوطه اعلام شده و در فهرست وضعیت درخواست‌های توسعه‌ای ثبت گردد.
• نسخ جدید رفع اشکال شدهی سیستم‌ها: در صورتیکه اشکالات و نیازمندی‌های اعلام شده به توسعهدهندگان به انجام برسد، لازم است به جهت اعمال این تغییرات آخرین نسخه سیستم مربوطه را جهت بهروز رسانی به ساپ ارسال نمایند.

پشتیبانگیری از اطلاعات

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

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

جای تصویر/شکل: 3.38- پشتیبانگیری از اطلاعات- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

• پشتیبانگیری از اطلاعات: ورودی‌ها
• برنامهی نگهداری اطلاعات: همانگونه که در بخش 3.1.9 تشریح گردید، سندی است که با بیان شرایط و وضعیت پروژه از دیدگاه پراکندگی جغرافیایی پروژه، انواع اسناد و اطلاعات پروژه و شرایط ارتباطی با سایر ذی‌نفعان، برنامهی جامعی از نحوهی نگهداری، ذخیرهسازی، پشتیبانی و بازیابی اطلاعات ارائه میدهد. تهیهی برنامهی پشتیبانگیری اطلاعات بر اساس این مستند تهیه خواهد گردید.
• برنامهی پیکربندی اطلاعات: یکی از اسنادی که در شناخت اطلاعات پروژه و نحوهی نگهداری آنها می‌تواند مورد استفاده واقع گردد، برنامه پیکربندی اطلاعات است. این برنامه در بخش 3.1.10 تشریح گردیده است.
• دارایی‌های فرآیندی سازمانی: روال‌های موجود در تهیهی نسخ پشتیبان از اطلاعات فیزیکی و الکترونیکی در سازمان یا سایر پروژه‌های سازمان در این فرآیند قابل استفاده خواهد بود.
• شرایط محیطی سازمان: محل جغرافیایی پروژه، اندازهی پروژه و تعداد کارکنان پروژه، پراکندگی جغرافیایی پروژه، قوانین و مقررات در نحوهی نگهداری اطلاعات، همه از مواردی هستند که بر روی این فرآیند موثر خواهند بود.
• پشتیبانگیری از اطلاعات: ابزارها و تکنیک‌ها
• نظر کارشناسان: استفاده از نظر کارشناسان در شناخت مکان‌های نگهداری اطلاعات، شناخت انواع تهدیدات و دریافت بازخورد روال‌های انجام شده در این فرآیند مورد استفاده است.
• ابزارهای تصویربرداری از اسناد: استفاده از ابزارهای تصویربرداری مانند اسکنرها و … از ابزارهایی است که برای گرفتن نسخهی پشتیبان از اطلاعات فیزیکی مورد استفاده قرار می‌گیرد.
• ابزارهای پشتیبانگیری از اطلاعات: ابزارهای پشتیبانگیری از اطلاعات دارای تنوع زیاد بوده و استفاده از ابزار مناسب از الزامات اصلی ساپ در این فرآیند است.
• پشتیبانگیری از اطلاعات: خروجی‌ها
• برنامهی پشتیبانگیری از اطلاعات: سندی است که در آن با تشریح شرایط پروژه و اطلاعات پروژه، روش‌های اجرایی و عملیاتی تهیهی نسخههای پشتیبان از اطلاعات فیزیکی و الکترونیکی را مشخص نموده، الزامات مربوط به رفع تهدیدات اطلاعات را تعیین میکند.

خاتمهی پروژه

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

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

جای تصویر/شکل: 3.39- خاتمهی پروژه- ورودی‌ها ، ابزار و تکنیک‌ها و خروجی‌ها

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