Posts

الزامات ترسیم فرآیندها

مواردی که می بایست در طراحی یک فرآیند مد نظر قرار گیرد به شرح ذیل هستند:
۱٫ هر فرآیند مجموعه ای از نقش ها است (نه نام افراد یا کار آنها). به بیان دیگر، هر یک از افراد در یک بخش سازمانی، واحد یا سازمان، می توانند همزمان چندین نقش مختلف را به عهده داشته باشند.
۲٫ هر یک از نقش های فرآیندی باید در عنوان یک و تنها یک مسیر ، قرار گیرد. به بیان دیگر، هر یک از مسیرها باید دارای عنوانی برابر با یکی از نقش های فرآیندی باشد و مسیرهای دیگر نباید از همان عنوان استفاده نمایند.
۳٫ گرچه این مورد بر اساس استاندارد علائم مدیریت فرآیندهای کسب¬وکار ترویج شده است اما در همه روش¬ها، چنین مشابهتی وجود دارد: هر فرآیند تنها و تنها با یک رویداد آغاز می شود. به بیان دیگر، هر فرآیند تنها یک آغازگر دارد و آن آغازگر تنها به یک فرآیند اختصاص خواهد داشت.
۴٫ در فرآیند نباید سکته وجود داشته باشد یعنی نباید یک جایی از فرآیند به هیچ چیز دیگری متصل نباشد. اصطلاحاً نباید ول باشد.
۵٫ یک فرآیند می تواند چندین حالت پایان داشته باشد که بر اساس شرط های مختلف می بایست مشخص باشد
۶٫ هر یک از حالت های شرط ها، می بایست بر روی کمان های خارج شونده از شرط، درج شده باشند. پس نباید بجای نوشتن بر روی کمان ها، از پردازش ها یا یادداشت ها استفاده نمود.
۷٫ مرسوم است که بجای نگارش مواد آیین نامه ها و شیوه نامه ها، آنها را در قالب یادداشت های کوچکی درج نمود.
۸٫ فرآیندهای خارجی باید حتماً به صورت مشخص و با رعایت اصول خاصی که در استانداردهای مختلف تفاوت ظاهری دارند، در دل فرآیند کنونی مشخص شوند.
۹٫ ترسیم فرآیند یک هنر است پس تحلیلگر و طراح فرآیند باید سطح فعالیت ها را رعایت نماید. پس لازم است تا اگر در حال ترسیم سطح صفر فرآیندها است، کلیه اقدامات کلان را ترسیم نماید و از ترسیم فعالیت های لایه های پایین تر اجتناب نماید تا توازن فعالیت ها و سطح تحلیل آنها به هم نخورد.
۱۰٫ فرآیند باید خوانا باشد یعنی خواننده بتواند در اسرع وقت، با دنیال کردن کمان ها، مسیر فرآیند را دنبال نماید.
۱۱٫ در تمامی استانداردهای تحلیل و طراحی فرآیند، این اصل پذیرفته شده است که فرآیند باید از منتها الیه سمت چپ بالا شروع شود و به ترتیب به یکی از دو سمت پایین و راست حرکت نماید و بجز در مواقع خاص (در شرایط نقطه تصمیمی که منجر به دوباره کاری خواهد شد)، نسبت به برگشت به عقب اقدام ننماید.
۱۲٫ اگر در دل یک فرآیند نیاز به توضیح یک فرآیند دیگر است که منجر به پیچیده تر شدن این فرآیند و ترسیمات آن می شود لازم است تا از مفهوم زیرفرآیند استفاده گردد تا خواننده دچار گیجی نشود.
۱۳٫ هر تصمیم باید حداقل حاوی دو حالت باشد و محتوای متن تصمیم، تا حد ممکن باید سوال مثبت باشد.
۱۴٫ در هیچ یک از فعالیت ها نباید عنوان نقش ذکر شود بلکه باید ماهیت فعالیت، اشاره مختصر شود.
۱۵٫ هر یک از فعالیت ها باید با اسم مصدر شروع شوند و با یک اسم به خاتمه برسند به عنوان مثال: ارسال نامه.
۱۶٫ هر فرآیند باید یک نام مشخص و یکتا داشته باشد که در بالای فرآیند سمت راست، درج شده باشد. ترجیحاً اگر کُد فرآیند مشخص باشد بهتر است. ضمن اینکه اگر نسخه های دیگر و سطوح تحلیل دیگر نیز برای آن وجود دارد باید در نام مشخص گردد تا بازیابی آن به راحتی صورت پذیرد.
۱۷٫ از یک فعالیت، تنها و تنها یک کمان خارج می شود پس هر کمان فقط از یک فعالیت خارج شده است و هر فعالیت تنها یک کمان خروجی دارد.
۱۸٫ در استاندارد علائم مدیریت فرآیندهای کسب¬وکار، رویدادهای میانی تعریف شده اند که در صورتی که فعالیتی دستی صورت نمی گیرد و نیاز به زمان، پردازش سیستمی، پیام و نظایر آن باشد، از آن استفاده می شود.
۱۹٫ یک فرآیند باید به حداقل یک نتیجه مشخص برسد. یعنی در انتهای فرآیند باید نتیجه قابل ارزشگذاری باشد.

نحوه مدلسازی کسب وکار یک سازمان

استفاده از مفاهیم مدلسازی کسب­ وکار برای شرکت­های کوچک و متوسط و حتی برای شرکت­های بزرگ خصوصی در ادبیات به وفور یافت می­شوند اما هنگامی که بحث وارد فضای سازمان­های بزرگ و دولتی می­شود شرایط عوض می­شود. برای شرکت­های دسته اول استفاده از مفاهیم مندرج در کتاب “تولید مدل­های کسب­وکار[۱]” می­تواند کمک شایان توجهی بدان­ها نماید چرا که سبب بررسی یک کسب­وکار از زوایای مختلفی می­شود، شکل ۱: نمودار Business Model Canvas. با این که مدل‌های مرجع این کتاب می­توانند برای سازمان­های دولتی هم مفید باشند اما هنوز استفاده از آنها تردید برای رسیدن به نتایج لازم را پاسخگو نیست.

شکل ۱: نمودار Business Model Canvas

یکی از راههای مدلسازی که برای سازمان­ها پیشنهاد شده است در کتاب معروف “مدلسازی کسب­وکار[۲]” ارائه شده است. در این کتاب از ابتدا با شکستن یک سازمان با واحدهای وظیفه­ای، هر واحد را معادل با یک “جعبه سیاه[۳]” در نظر گرفته است که با نقش­های متعددی در ارتباط بوده و به آنها سرویس ارائه می­نماید (شکل ۲: نمایش سرویس­های درون یک واحد و شکل ۳: نمایش جعبه سیاه یک واحد). سپس با تعیین نقش­های درونی هر واحد سازمانی در درون این جعبه سیاه، به خوبی ارتباط هر نقش با خدمات، ذینفعان و دیگر نقش­های درونی را مشخص ساخته است(شکل ۴: ارتباط سرویس­های درونی و نقش­های خارجی و شکل ۵: تعیین نقش­های درونی یک واحد). در انتها نیز سعی نموده است تا با تجمیع اهداف کسب­وکار و واحد سازمانی، مدل کسب­وکاری مطلوب را انتخاب نماید.

شکل ۲: نمایش سرویس­های درون یک واحد

شکل ۳: نمایش جعبه سیاه یک واحد

شکل ۴: ارتباط سرویس­های درونی و نقش­های خارجی

شکل ۵: تعیین نقش­های درونی یک واحد

از آنجا که راهکار دوم برای نمایش وضعیت سازمان و اهداف کلان هر واحد مناسب است و راهکار اول می­تواند به خوبی پیشران های هر واحد را نمایش دهد، لذا تلفیق هر دو مورد در نمودار زیر به عنوان راهکاری متناسب  پیشنهاد شده است:

[۱] Business Modeling Generation: John Wiley and sons, 2009.

[۲] Business modeling: A practical guide to realizing business value, MK, 2009.

[۳] Black-Box Organizational model

علائم مدیریت فرآیندهای کسب وکار

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

–     دو مسیر خروجی از این دروازه را می‌توان در ادامه فرآیند با کمک همین نشانه به یک نقطه رساند (مثال ۱ ).

دروازه “یا”:–     اگر چند مسیر از این نشانه خارج شوند به این معناست که یک یا چند مسیر ممکن است انجام می­شود.

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

دروازه “و”:اگر از این نشانه، چند مسیر خارج شود به این معناست که کلیه این مسیرها بصورت موازی انجام می‌شوند.

اگر چند مسیر به این دروازه وارد شوند، دروازه هنگامی فعال می‎شود که کلیه مسیرهای وارده، به انجام برسند (مثال ۲).

 

مسیر مشروط: مسیری است که در شرایطی خاص انتخاب می‌شود.
مسیر پیش‌فرض
فرآیند خارجی: منظور فرآیندی است که در این فرآیند ترسیم نشده است و می ­تواند آغازگرهای دیگری نیز داشته باشد.

 

در ادامه، مثال­ های فرضی برای نشان دادن کاربردهای مذکور نشان داده شده است.

  • مثال ۱:

 

  • مثال ۲:

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

نمودار گردش سیستمی

نمودار روند سیستم([۱]SFC):

در این نمودار قصد داریم تا بدنبال یک فرآیند از ابتدا حرکت کنیم- مانند یک کارمند که بین واحدهای مختلف حرکت می کند تا تاییدها،توافق ها،امضاها و سوالات خود را مطرح سازد- و تک تک افراد مرتبط در سیستم را شناسایی می نماییم  و توالی مورد نظر را در آنها نمایش می دهیم.

به عنوان مثال فرض کنید قصد خرید تلویزیون با وام بانکی را دارید،در این صورت نمودار زیر می تواند یک SFC ی مناسب برای این منظور باشد:

در روند بالا فرض شده است که:

  1. شخص فرم درخواست وام را از بانک می گیرد.
  2. آنرا پر می کند و به بانک تحویل می دهد.
  3. بانک فرم های پر شدۀ درخواست وام را دریافت می کند و آنها را در یک پوشه یا پایگاه داده[۲] ذخیره می نماید.
  4. سپس فرد مسئول در بانک آنها را با مشخصات و ضوابط اعطای وام چک می نماید.
  5. پس از این مرحله مشخص می گردد که آیا با وام موافقت شده است یا خیر.
  6. سپس نتیجۀ آن به شخص متقاضی اعلام میگردد.
  7. اگر با وام وی موافقت شده باشد،از وی مدارکی برای صدور وام درخواست می شود.
  8. وی مدارک خود را تحویل می دهد.
  9. بانک پس از دریافت مدارک شخص،به بررسی آنها می پردازد.
  10. سپس وام را آمادۀ پرداخت می نماید.
  11. به همین موازات شخص متقاضی به فروشنده مراجعه می نماید و به انتخاب کالا اقدام می نماید.
  12. فروشنده درخواست وی را ثبت می نماید و منتظر می ماند تا به محض دریافت پول کالا آنها را ارسال نماید.
  13. به محض دریافت پول توسط متقاضی،وی پول را به فروشنده ارسال می نماید.
  14. پول توسط فروشنده دریافت می شود و کالا را برای شخص ارسال می نماید.

 

همانطور که مشخص است در SFC ما یک روند با نقشهای مشخصی داریم.کاری که هر چند وقت یکبار (دورۀ تناوب) تکرار می شود.لذا می توان گفت که:

SFC یک داستان است که در سیستم واقعی

رخ می دهد و تکرارپذیر است.

 

نکات مهم:

برای ترسیم مناسب یک SFC،در نظر گرفتن نکات زیر ضروری است:

  1. داشتن دید فرآیند گرا:

در این نوع دیدگاه،شما باید هر چیز را مانند یک داستان ببینید که از یک جایی (یا با یک حادثه ای) شروع می شود،مسیری را طی می نماید(با نقشهایی) برخورد دارد و به یک جای مشخص ختم می گردد.

  1. پرسشگری:

در طی این کار باید دائماً از خود بپرسید که:

حالا به کجا می رویم؟

اگر این گونه شود چه طور عمل خواهیم کرد؟

آیا فرد دیگری در سازمان نیز هست که بتواند به ما در ارائۀ مطالب کمک نماید؟

آیا شخص دیگری نیز اجازۀ چنین کاری (مثلاً صدور درخواست دسته چک) را دارد؟

و…

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

  1. تفکر سیستمی:

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

 

 

ترسیم SFC:

از آنجا که SFC به شدت نیازمند تجربه و خلاقیت است،لذاگامهای تدوین شده و یکسانی برای همۀ افراد وجود ندارد،اما می توان یک روند مناسب را برای آن به شکل زیر شرح داد:

  1. شناسایی سازمان و آشنایی با چارت سازمانی و انواع قسمتها (وظایف و این که زیر بخش چه بخشهایی هستند)
  2. تفکر و شناخت چند فرآیند اولیه مثلاً در منابع انسانی شما حتماً بحث پرداخت حقوق را خواهید داشت و …
  3. پرسشگری از افراد مرتبط (با شرایط پرسشگری که در بالا مطرح شد) و جمع آوری مستنداتی مثل فرمهای درخواست و غیره تا شما را در شناسایی و کسب دانش بهتر کمک نماید.
  4. ترسیم و تفکر در مورد آنچه افراد تعریف کرده اند به نحوی که شما را قانع سازد که به یک داستان رسیده اید.
  5. شناسایی فرآیندهای دیگر از دل فرآیندهای قبلی
  6. اجرای دوبارۀ مراحل ۳ تا ۵

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

 

 

نماد های بکار رفته:

 

ورودی دستی:

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

 صدور اسناد فیزیکی:

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

 پوشه های دستی:

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

 به معنای پایگاه داده ها(ذخیره آنلاین ):

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

 عملیات دستی:

برای هر گونه کاری که توسط نیروی انسانی صورت می گیرد و نیازمند صرف وقت و انرژی فیزیکی است،بکار می رود.

 عملیات کمکی:

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

 ورود داده های شفاهی و الکترونیکی:

هر نوع ورود و دریافت اطلاعات که غیر فیزیکی است را در بر می گیرد.

 

[۱] System Flow Chart

[۲] Database

معرفی ابزارهای تحلیل IDEF

مقدمه:

ابزارهای تحلیلی خانواده IDEF، از جمله ابزارهایی هستند که در زمان قبل از ایجاد زبان متحد مدلسازی[۱] پا به عرصه وجود گذاشتند. این ابزار توسط یکی از آزمایشگاه­های نیروی هوایی ایالات متحده ایجاد ش   د که قطعاً برای اهداف سیستم­های اطلاعاتی مورد استفاده قرار گرفته است. این خانواده از ابزارها گرچه با نسخه­های IDEF0 و IDEF1 آغاز شدند ما به سرعت به خانواده IDEF (که با اصطلاح IDEFX شناخته می­شوند) تبدیل شدند تا نشان دهند که ابزارهای زیادی در طیف وسیعی از حوزه تحلیل سیستم­ها (چه سیستم­های اطلاعاتی، سازمانی، مفهومی و حتی کسب­وکاری) نیازمند تدوین هستند.

ابتدا به تشریح IDEF0 پرداخته می­شود.

IDEF0 ابزاری برای کل نگری برای تحلیل کارکرد سیستم­ها

اجازه دهید که ابتدا با چند مثال به شما بگویم که چرا نیاز به چنین ابزاری احساس گردید؟. هنگامی که قصد انجام کاری را دارید، می­توانید خیلی ساده آن را شامل ۳ جزء ببینید: ورودی­ها، خروجی­ها و خود آن کار. به سادگی شکل زیر، می­توان این مفاهیم را در یک جریان مستقیم خطی دید:

نمودار ۱: فعالیت به صورت خطی

در چنین دیدگاهی که نظیر آن در ریاضیات با مفهوم تابع (که در آن تعدادی ورودی تبدیل به تعدادی خروجی می­شوند[۲]) دیده می­شود، تعدادی ورودی، با انجام برخی اقدامات به خروجی تبدیل می­شوند. گرچه این نگاه ساده می­تواند مفید باشد اما بسیاری از واقعیت­ها را نمایش نمی­دهد. در جهان هستی بسیاری از اقدامات ما:

  • به سادگی حالت خطی شکل اول نیستند.
  • نیازمند برخی امکانات دیگر هستند.

در زیر نمونه ای از یک فرآیند که بوسیله این ابزار ترسیم شده است،آمده است.در این ابزار هر فرآیند با چهار کمان سر و کار دارد:

۱٫ورودی ها:

هر چیز فیزیکی یا داده ای که سبب شروع فرآیند گردد.گاهی فرآیندهایی را می بینیم که ورودی ندارند(!!) و تنها یک فعالیت دوره ای محسوب می شوند مانند انبارگردانی

۲٫خروجی ها:

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

۳٫کنترل ها:

هر آنچه که سبب بررسی صحت و اعتبارسنجی در فرآیند گردد مانند وجود شناسنامه در هنگام ثبت نام

 

۴٫مکانیزم ها:

هر انچه که ورودی،خروجی و کنترل نباشد اما برای اجرای فرآیند کاملاً ضروری یا تسهیل گر باشند.مانند قوطی باز کن برای گشودن در کنسرو

۴٫۱ مکانیزمهای فراخوان:

سبب فراخوانی یک فرآیند خارجی می گردد که ادامه فرآیند محتاج به انجام و دریافت نتایج از آن است.

 

تذکر:

نماد گوشه سمت چپ پایین نمایانگر کد و سطح اجرا است.

 

 

محققان آزمایشگاه نیروی هوایی ایالات متحده، تصمیم گرفتند که مثالی نظیر مثال زیر را بررسی کنند (البته این یک مثال ساختگی است):

مثال: فرض کنید که لامپ اتاق شما سوخته است و می­خواهید آن را تعویض نمایید (برای آنکه خلاقیت ذهنی ما، مشکلات جدی ایجاد نکند، قد شما ۱٫۶ متر، ارتفاع اتاق، ۲٫۵ متر و تنها یک لامپ به صورت سفت و  در سقف پیچ شده و نور اتاق را تامین می­نماید).  برای این تعویض چه می­کنید؟

پاسخ:

گرچه که بسته به تجربه شما، روش­های مختلفی می­تواند پیشنهاد شود اما ابتدا چند مفهوم را با هم بررسی می­کنیم و سپس روش­های مختلف (دو روش متداول) را به کمک ابزار IDEF0 تحلیل خواهیم نمود.

  • مفهوم ۱: ورودی­ها

شما نیاز به یک لامپ جدید دارید.

  • مفهوم شماره ۲: خروجی مورد نظر شما و خروجی های محتمل دیگر

نورانی شدن اتاق به کمک لامپ تعویض شده (خروجی مورد نظر)

لامپ تعویض شده (خروجی دیگر)

  • مفهوم شماره ۳: ابزارهای کمکی

شما به یک نردبان نیاز دارید تا دست شما به تعویض لامپ برسد.

  • مفهوم شماره ۴: ابزاری برای کنترل

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

  • مفهوم شماره ۵: محتوای کار

تعویض لامپ سوخته با لامپ جدید

به طور کلی IDEF0 پیشنهاد می­نماید که از نمودار سطح صفر زیر بهره ببرید:

 

نمودار ۲: ترسیم فعالیت در IDEF0

زبان مدلسازی IDEF0، به ابزارهای کمکی، مکانیزم و به ابزارهای کنترلی، کنترل می­گوید (حال این ابزارها می توانند فیزیکی بوده یا یک مستند، یک بند از قانون و … باشد). پس از این­که مفاهیم این ابزارها را با هم مرور نمودیم، اجازه دهید دو راه­حل را برای تعویض لامپ در نظر بگیریم:

راه­حل اول: فرض کنید که شما از سالم بودن لامپ اطمینان دارید. پس منطقی است که دو گام زیر را انجام دهید:

گام اول: نصب لامپ جدید به جای لامپ قدیمی

گام دوم: استفاده از کلید برق برای اطمینان از کار کردن سیستم برق (و نه فقط لامپ)

در این حالت، نمودار IDEF0 مرتبط با آن، به شکل زیر خواهد بود:

نمودار ۳: ترسیم جزئیات راه حل اول

 

همانطور که مشخص است، عناصر مکانیزم و کنترل که در نمودار اول روی یک باکس قرار داشتند، در واقعیت متعلق به دو گام مختلف بودند و به علت نیاز به تجمیع، در نمودار اول در یک تصویر به نمایش درآمده بود (بازگردید به مفهوم سطح خلاصه­سازی[۳]). همچنین در نمودار اول، دو خروجی دیده می­شود که در نمودار ۲، علاوه بر آن دو خروجی، یک خروجی واسط دیگر نیز دیده می­شود (لامپ نصب شده که گام اول را به گام دوم مرتبط می­سازد).

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

نمودار ۴: ترسیم جزئیات راه حل دوم

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

شما به عنوان تحلیلگر سیستم، فکر می­کنید که هر کدام از این راه­ها برای چه شرایطی مناسب است؟ کدامیک زمان و هزینه کمتری خواهد داشت؟ کدامیک منجر به افسوس کمتری (!) خواهد شد؟ و ….

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

[۱] Unified Modeling Language (UML)

[۲] (y1,y2,…)=f(x1,x2,…)

[۳] Abstraction

لینک دانلود نمونه پروژه تحلیل سیستم

منبع: http://ghodoosi.com/blog/?cat=38 محمدرضا قدوسی

نویسنده: پویا نخجیرکان

Business Process Reengineering (BPR): Definition, Steps, Examples

Proper execution of Business Process Reengineering can be a game-changer to any business.

If properly handled, it can perform miracles on a failing or stagnating company, increasing the profits and driving growth.

Business process reengineering, however, is not the easiest concept to grasp. It involves enforcing change in an organization – tearing down something people are used to and creating something now.

And that’s not an easy task.

Jump to any section

So, What is Business Process Reengineering?

Business process reengineering is the act of recreating a core business process with the goal of improving product output, quality, or reducing costs.

Typically, it involves the analysis of company workflows, finding processes that are sub-par or inefficient, and figuring out ways to get rid of them or change them.

Business process reengineering became popular in the business world in the 1990s, inspired by an article called Reengineering Work: Don’t Automate, Obliterate which was published in the Harvard Business review by Michael Hammer.

His position was that too many businesses were using new technologies to automatefundamentally ineffective processes, as opposed to creating something different, something that is built on new technologies.

Think, using technology to “upgrade” a horse with lighter horseshoes which make them faster, as opposed to just building a car.

In the decades since, BPR has continued to be used by businesses as an alternative to business process management (automating or reusing existing processes), which has largely superseded it in popularity.

And with the pace of technological change faster than ever before, BPR is a lot more relevant than ever before.

Business Process Reengineering Steps

As we’ve mentioned before, business process reengineering is no easy task.

Unlike business process management or improvementboth of which focus on working with existing processes, BPR means changing the said processes fundamentally.

This can be extremely time-consuming, expensive and risky. Unless you manage to carry out each of the steps successfully, your attempts at change might fail.

Step #1: Identity and Communicating the Need for Change

If you’re a small startup, this can be a piece of cake. You realize that your product has a high user drop-off rate, send off a text to your co-founder, and suggest a direction to pivot.

For a corporation, however, it can be a lot harder. There will always be individuals who are happy with things as they are, both from the side of management and employees. The first might be afraid that it might be a sunk investment, the later for their job security.

So, you’ll need to convince them why making the change is essential for the company. If the company is not doing well, this shouldn’t be too hard.

In some cases, however, the issue is with the company not doing as well as it could be. Meaning, you should do your research. Which processes might not be working? Is your competition doing better than you in some regards? Worse?

Once you have all the information, you’ll need to come up with a very comprehensive plan, involving leaders from different departments. The management will have to play the role of salespeople: conveying the grand vision of change, showing how it’ll affect even the lowest-ranked employee positively.

Risk of Failure: Not Getting Buy-In From The Company

If you fail to do this, however, your business process reengineering efforts might be destined to fail long before they even start.

Business Process Re-Engineering can seriously impact on everyone in the company, and sometimes this can appear to be a negative change for some. Some employees might, for example, think you’ll let them all go if you find a better way to function (which is a real possibility).

In such cases, even if the management is on board, the initiative might fail because the employees aren’t engaged.

Usually, it’s possible to get the employees buy-in by motivating them or showing them different views they weren’t aware of. Sometimes, however, the lack of employee engagement might be because of a bad workplace culture – something that might need to be dealt with before starting any BPR initiatives.

Step #2: Put Together a Team of Experts

As with any other project, business process reengineering needs a team of highly skilled, motivated people who will carry out the needed steps.

In most cases, the team consists of:

  • Senior Manager.When it comes to making a major change, you need the supervision of someone who can call the shots. If a BPR team doesn’t have someone from the senior management, they’ll have to get in touch with them for every minor change.
  • Operational Manager.As a given, you’ll need someone who knows the ins-and-outs of the process – and that’s where the operational manager comes in. They’ve worked with the process(es) and can contribute with their vast knowledge.
  • Reengineering Experts. Finally, you’ll need the right engineers. Reengineering processes might need expertise from a number of different fields, anything from IT to manufacturing. While it usually varies case by case, the right change might be anything – hardware, software, workflows, etc.

Risk of Failure: Not Putting The Right Team Together

There are a lot of different ways to mess this one up.

If the team consists of individuals with a similar viewpoint and agenda, for example, they might not be able to properly diagnose the problems/solutions.

Or, the team might involve too many or too few people. In the first case, the decision making might be slowed down due to conflicting viewpoints. In the later, there might not be enough experts on certain fields to create adequate solutions.

It’s hard to put all that down as a framework, as it depends on the project itself. There is one thing, however, that benefits every BPR team: having a team full of people who are enthusiastic (and yet unbiased), positive and passionate about making a difference.

Step #3: Find the Inefficient Processes and Define Key Performance Indicators (KPI)

Once you have the team ready and about to kick-off the initiative, you’ll need to define the right KPIs. You don’t want to adapt to a new process and THEN realize that you didn’t keep some expenses in mind – the idea of BPR is to optimize, not the other way around.

While KPIs usually vary depending on what process you’re optimizing, the following can be very typical:

  • Manufacturing
    • Cycle Time– The time spent from the beginning to the end of a process
    • Changeover Time– Time needed to switch the line from making one product to the next
    • Defect Rate– Percentage of products manufactured defective
    • Inventory Turnover– How long it takes for the manufacturing line to turn inventory into products
    • Planned VS Emergency Maintenance – The ratio of the times planned maintenance and emergency maintenance happen
  • IT
    • Mean Time to Repair– Average time needed to repair the system / software / app after an emergency
    • Support Ticket Closure rate– Number of support tickets closed by the support team divided by the number opened
    • Application Dev.– The time needed to fully develop a new application from scratch
    • Cycle Time– The time needed to get the network back up after a security breach

Once you have the exact KPIs defined, you’ll need to go after the individual processes. The easiest way to do this is to do business process mapping. While it can be hard to analyze processes as a concept, it’s a lot easier if you have everything written down step by step.

This is where the operational manager comes in handy – they make it marginally easier to define and analyze the processes.

Usually, there are 2 ways to map out processes:

  • Flowcharts– the most basic way to work with processes is through flowcharts. Grab a pen and paper and write down the processes step by step.
  • Workflow Software– if you’re more tech-savvy, using software for process analysis can make everything a lot easier. You can use Tallyfy, for example, to map out your processes, include user responsibilities, etc. Simply using such software might end up optimizing the said processes as it allows for easier collaboration between the employees.

Risk of Failure: Inability to Properly Analyze Processes

Or, to put it more succinctly – impatience. It’s uncommon for someone to try business process reengineering if they profits are soaring and the projections are looking great.

BPR is usually called for when things aren’t going all that well and businesses need drastic changes. So, it can be very tempting to hurry things up and skip through the analysis process and start carrying out the changes.

The thing is, though, the business needs analysis needs to be done properly, not rushed through to get to the more exciting parts.

There are always time and money pressures in the business world, and it’s the responsibility of the senior management to resist the temptation and make sure the proper procedure is carried out. Problem areas need to be identified, key goals need to be set and business objectives need to be defined and this takes time.

Ideally, each stage requires input from groups from around the business to ensure that a full picture is being formed, with feedback and ideas being taken into consideration from a diverse range of sources. The next step is to identify and prioritize the improvements that are needed and those areas and processes that need to be scrapped. Any business that doesn’t take this analysis seriously will be going into those next steps blind and will find that their BPR efforts will fail.

Any business that doesn’t take this analysis seriously will be going into those next steps blind and will find that their BPR efforts will fail.

Step #4: Reengineer the processes and Compare KPIs

Finally, once you’re done with all the analysis and planning, you can start implementing the solutions and changes on a small scale.

Once you get to this point, there’s not much to add – what you have to do now is keep putting your theories into practice and seeing how the KPIs hold up.

If the KPIs show that the new solution works better, you can start slowly scaling the solution, putting it into action within more and more company processes.

If not, you go back to the drawing board and start chalking up new potential solutions.

Business Process Reengineering Examples

The past decade has been very big on change. With new technology being developed at such a breakneck pace, a lot of companies started carrying out business process reengineering initiatives. There are a lot of both

There are a lot of both successful and catastrophic business process reengineering examples in history, one of the most famous being that of Ford.

BPR Examples: Ford Motors

One of the most referenced business process reengineering examples is the case of Ford, an automobile manufacturing company.

In the 1980s, the American automobile industry was in a depression, and in an attempt to cut costs, Ford decided to scrutinize some of their departments in an attempt to find inefficient processes.

One of their findings was that the accounts payable department was not as efficient as it could be: their accounts payable division consisted of 500 people, as opposed to Mazda’s (their partner) 5.

While Mazda was a smaller company, Ford estimated that their department was still 5 times bigger than it should have been.

Accordingly, Ford management set themselves a quantifiable goal: to reduce the number of clerks working in accounts payable by a couple of hundred employees. Then, they launched a business process reengineering initiative to figure out why was the department so overstaffed.

They analyzed the current system, and found out that it worked as follows:

  1. When the purchasing department would write a purchase order, they sent a copy to accounts payable.
  2. Then, the material control would receive the goods, and send a copy of the related document to accounts payable.
  3. At the same time, the vendor would send a receipt for the goods to accounts payable.

Then, the clerk at the accounts payable department would have to match the three orders, and if they matched, he or she would issue the payment. This, of course, took a lot of manpower in the department.

Old Payable Process

So, as is the case with BPR, Ford completely recreated the process digitally.

  1. Purchasing issues an order and inputs it into an online database.
  2. Material control receives the goods and cross-references with the database to make sure it matches an order.
  3. If there’s a match, material control accepts the order on the computer.

New payable process

This way, the need for accounts payable clerks to match the orders was completely eliminated.

 

Refrence: https://tallyfy.com/business-process-reengineering/

Author: Pooya Nakhjirkan