مدیریت کیفیت نرم افزار

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

مدیریت کیفیت نرم‌افزار پروسه نظام‌مندی است که تضمین می‌دهد نرم‌افزاری که ما از آن استفاده می‌کنیم از کیفیت مطلوبی برخوردار است. در مدیریت کیفیت نرم افزار ما فقط با درک کامل از نظم و انضباط می توانیم بطور موثری عمل کنیم.

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

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

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

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

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

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

مفاهیم کیفیت

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

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

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

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

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

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

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

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

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

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

معرفی ITIL ، ®CMMI® و COBIT®

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

برخی از این رهنمودها تحت نظارت دولت و دانشگاه‌های تحقیقاتی بزرگ و سازمان‌های حرفه‌ای برجسته توسعه یافته‌اند. کتابخانه زیرساخت فناوری اطلاعات (ITIL) که توسط انگلستان و از طریق کانال‌های رسمی انتشار و پشتیبانی می‌شود و اهداف کنترلی برای فناوری اطلاعاتCOBIT) ) توسط انجمن کنترل و بازرسی آی اس (ISACA) حمایت می‌شود. همچنین یک مدل بلوغ قابلیت یکپارچه (CMMI) وجود دارد که طی بیست سال توسط مؤسسه مهندسی نرم‌افزار در کارنگی‌ملون ایجاد شده است. ITIL ، ®CMMI® و COBIT® در صنعت فناوری اطلاعات در سطح جهان تأثیر عمیقی دارند و به عنوان یک چارچوب مشخص برای بخشهای وسیعی از فعالیت‌های فناوری اطلاعات در حال سرویس‌دهی هستند. این چارچوب‌ها اغلب به عنوان معیارهای دقیقی برای اعطای قراردادها و ارزیابی بلوغ، ریسک و کارایی مورد استفاده قرار می‌گیرند. در این زمینه، اکوسیستم‌های آموزشی مختلفی به وجود آمده‌ و کتاب‌ها، همایش‌ها و تحقیقات متعددی پیرامون آنها ایجاد شده است. تمام این موارد جهت تعریف و تثبیت اصطلاحات IT و هدایت آن به سمت یک توصیف مشترک از فعالیت‌ها و اصول فناوری اطلاعات ایجاد شده است. IT همواره تحت نظارت و بررسی دایمی است. صنعت با انتقاد از توانایی IT در ارائه خدمات و مدیریت آنها مواجه بوده است. بنابراین مناسب است به فرضیات و پیامدهای این چارچوبها توجه جدی شود.

مدیریت فرآیند کسب و کار

فرهنگ و ادبیات گسترده و مرتبط با مدیریت فرآیند کسب و کار از جمله نحوه شناسایی و ایجاد و مستندات رسمی و بهبود فرآیندهای تجاری وجود دارد. این ادبیات کاملاً با دغدغه‌های گسترده‌ای از مدیریت عمومی کسب و کار، مدیریت عملکرد و سازمان به عنوان سیستم مطابقت دارد. بین تکنیک های BPM و بهبود مداوم مانند Lean و Six Sigma هم‌پوشانی قابل توجهی وجود دارد. با این حال ، این مقاله موضوع باریک‌تر تعریف «فرآیند» را برای اهداف عملیاتی، به ویژه در ایجاد چارچوب‌های صنعت IT ، مفید خواهد کرد.
BPM می‌تواند در مدیریت IT کاربرد داشته باشد.ITIL® ، COBIT® و CMMI® همگی از اصطلاح «فرآیند» به طور گسترده استفاده نموده و معمولاً تحت عنوان چارچوب‌های «فرآیند» اطلاق می‌شوند. بنابراین، آنها خود را برای بررسی از منظر BPM قرار می‌دهند.

تعریف BPM از فرآیند

در این مقاله ما از تعریف بسیار دقیق و منطقی Sharp و McDermott برای فرآیند استفاده می‌کنیم:
«یک فرایند تجاری مجموعه‌ای از فعالیت‌های مرتبط است که در پاسخ به یک رویداد محرک آغاز می‌شود و یک نتیجه خاص و گسسته‌ای را برای مشتری و سایر ذینفعان فرآیند ارئه می‌دهد».

تاریخچه BPM با یک تمایز اصلی مشخص می‌شود: تمایز بین عملکرد و فرآیند. مایکل همر نویسنده مشهور در این رابطه می‌گوید: «مهندسی مجدد مستلزم نگاه به فرآیندهای اساسی تجارت از منظر بین‌عملکردی است».

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

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

1. شروع رهن
2. اخذ مشتری
3. تکمیل سفارش

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

1. استخدام تا بازنشستگی
2. تامین تا پرداخت‌
3. تحویل تا نقدکردن

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

سوء تعبیر از اصطلاح فرآیند در چارچوب‌های IT

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

ITIL(Information Technology Infrastructure Library)

ITIL® برخی از واضح‌ترین نمونه‌های سردرگرمی عملکرد/فرآیند را ارایه می‌دهد. علیرغم این واقعیت که ادعا می‌کند رویکرد مبتنی بر فرآیند دارد و در این زمینه به راملر استناد می‌کند. همچنین آن اظهار می دارد که دلیل وجود فرآیند ارایه یک نتیجه خاص است. این نتیجه باید بصورت جداگانه قابل شناسایی و قابل شمارش باشد. متأسفانه، ITIL® به وضوح اصول چارچوب خاص خود را دنبال نمیکند. (شاید قابل توجه باشد که اصطلاحاتی همچون BPM و مدیریت فرآیند تجارت در هیچ کجای ITIL® ظاهر نشده است.)
زیر مجموعه ای از فرایندهای شناخته شده ITIL® ممکن است شامل موارد زیر باشد:

1. مدیریت حوادث
2. مدیریت ظرفیت
3. مدیریت تغییر
4. مدیریت مشکل
5. مدیریت دسترس‌پذیری
6. پیکربندی خدمات و مدیریت دارایی

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

1. حل حادثه
2. پیاده‌سازی تغییرات
3. تصیح مشکلات

بطور مشابه نمودار کردن آن‌ها به عنوان جریان های فرآیندی بین عملکردی باید بصورت مستقیم باشد چراکه باید این فرآیندها را اندازه‌گیری و کنترل کرد. با این حال، کارها با «فرایندهایی» همچون ظرفیت، دسترس‌پذیری و مدیریت پیکربندی/دارایی بسیار مشکل‌تر می‌شوند. ظرفیت چیست؟ امروز چه ظرفیت‌هایی را انجام داده‌ایم؟ آیا یک ظرفیت ایجاد شده است؟ آیا ظرفیتی تنظیم شده است؟ آیا ظرفیتی کاهش پیدا کرده است؟ آخرین دسترس‌پذیری چه زمانی به پایان رسیده است؟ چه کسی سود برده است؟ ما می‌توانیم دارایی‌ها را حساب کنیم اما تنظیمات پیکربندی را چطور؟ بدیهی است که این سؤالات بی‌ربط نیستند، اما گاها اتفاق می‌افتد که عملکردها با فرآیندها اشتباه گرفته شوند. ITIL® مجموعه محدودی از «توابع» را فقط در حجم عملیات سرویس تعریف می‌کند.

1. میز خدمات
2. عملکرد مدیریت فنی
3. عملکرد عملیات IT
4. عملکرد مدیریت برنامه کاربردی

ITIL® 25 فرایند IT و 4 عملکرد IT دارد که دقیقا عکس راهنمایی‌های BPM است که بیان می‌دارد فرآیندهای واقعی، ارزش افزوده و سازمانی نسبتاً کمتر از عملکرد آنهاست.

COBIT

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

1. جهت گیری فناوری را تعیین کنید
2. میز خدمات و حوادث را مدیریت کنید
3. از خدمات مستمر اطمینان حاصل کنید
4. تغییرات را مدیریت کنید
5. بهره‌برداری و بکارگیری را فعال کنید
6. کیفیت را مدیریت کنید

به‌ هرحال این فرآیندها اغلب واضح یا شمارش پذیر نیستند. طبق بیان Sharp و McDermott، نام‌گذاری با افعال اقدامی باید باشد و نه با افعال احساسی. در فناوری اطلاعات واقعی، بسیاری از فرآیندهای COBIT® بنظر می‌رسد بیشتر شبیه به عملکردهای IT در حالت پایدار هستند مانند یک سازمان برنامه‌ریزی پیوستگی کار (برای اطمینان از خدمات مداوم). خواننده در این مقطع ممکن است نقد را ناعادلانه تصور کند به این دلیل که یک حوزه عملکردی مانند برنامه‌ریزی پیوسته کار ممکن است دارای فرآیندهای واضح و قابل شمارش و کوچکتر باشد.
با این حال این اغلب در مورد سیلوهای کارکردی صادق است و منجر به بروز مشکلات افزایش فرایندهای فناوری اطلاعات، ابهام ارزش و تقاضای کنترل نشده می‌گردد که در بخش «پیامدهای سردرگرمی فرآیند» بدان پرداخته خواهد شد. مجددا لازم است ما به یک نقطه مشخصی در قابلیت دید فرایند برسیم: آیا کاربر نهایی ارزش خود را از برنامه‌ریزی ادامه کار کسب می‌کند یا اینکه بهتر است این موضوع به عنوان یک مولفه یا ویژگی کیفی یک مفهوم ارزش اساسی‌تر مانند ارایه یک خدمت برنامه کاربردی یا زیرساختی دیده شود؟

CMMI

ما CMMI® را در آخر بحث می‌کنیم چراکه به نوعی فرا فرآیند و مجموعه‌ای از معیارهای کیفی است که می‌تواند به طور عمومی در هر فرآیندی اعمال شود. با این تعریف، CMMI معیار شمارش‌پذیری BPM را به عنوان یک معیار کیفی لحاظ نکرده است. این مشاهدات در بخش اهداف و تجارب عمومیCMMI® می‌باشد که بطور کلی برای هر فرآیند مشخص خواستار تعریف و نحوه اجرای آن است اما از اصطلاحات قابل شمارش یا قابل حساب یا هر مترادف معادل آن استفاده نمی‌کند. ممکن است این نکته خوبی بنظر برسد ولی CMMI® را با اختلاف از تعاریف پذیرفته شده BPM قرار می‌دهد و در را برای سردرگمی فرآیند/عملکرد باز می‌کند. «نواحی فرآیند» این چارچوب، شباهت‌های زیادی با ITIL® و COBIT® دارد:

1. مدیریت عملکرد سازمانی
2. آموزش سازمانی
3. مدیریت پیکربندی
4. اندازه‌گیری و تجزیه و تحلیل
5. مدیریت توافق نامه تأمین کننده

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

1. تصدیق
2. صحه‌گذاری

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

در آخر جالب است که در کل، چهار حوزه فرآیند، کلمه پروژه را ذکر کرده‌اند:

1. مدیریت یکپارچه پروژه
2. نظارت و کنترل پروژه
3. برنامه‌ریزی پروژه
4. مدیریت پروژه کمی

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