سیستم چیست؟ آموزش سیستم

آموزش مفهوم سیستم و کاربرد آن در زندگی روزمره و کسب و کار


تحلیل و طراحی سیستم چیست؟

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

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

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

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

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

عمل به وظایف مدیریتی به نوبه خود، مستلزم “تصمیم‌گیری” است و شالوده تصمیم‌گیری نیز، “اطلاعات” یا همان Information می‌باشد. یعنی مدیران برای اتخاذ تصمیم‌های صحیح اعم از تصمیم‌های طرح‌ریزی/برنامه‌ریزی تا تصمیم‌های کنترلی، نیازمند اطلاعات می‌باشند و این اصل در تمام سازمان‌ها برقرار است. مدیران برای کسب اطمینان از اثربخشی (انجام کارهای درست) و کارایی (انجام درست کارها) در سیستم خود، نیازمند ساز و کاری هستند تا اطلاعات مناسب و کافی را به‌موقع در اختیار ایشان قرار دهد. با این توصیف، هر سیستم سازمانی از منظر علم تجزیه و تحلیل سیستم‌ها، به دو سیستم فرعی زیر تقسیم خواهد شد:

الف. سیستم عملیات: که شامل برنامه‌ها، فرآیندها و فعالیت‌های اصلی و فرعی است و منجر به ایجاد خروجی سیستم می‌شود.

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

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

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

مثال در کسب و کار ایرانی

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

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

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

روش‌شناسی‌های تجزیه و تحلیل سیستم: نقشه‌راهی برای ساختن آینده‌ای کارآمد

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

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

۱. چرخه حیات توسعه سیستم یا SDLC – System Development Life Cycle: رویکرد کلاسیک

SDLC را می‌توان به عنوان قدیمی‌ترین و شاید شناخته‌شده‌ترین رویکرد در توسعه سیستم‌ها دانست. این روش‌شناسی، فرآیند توسعه را به فازهای مجزا و متوالی تقسیم می‌کند که هر فاز، باید قبل از شروع فاز بعدی تکمیل شود. فازهای اصلی SDLC عبارتند از:

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

تحلیل یا Analysis: در این مرحله، تحلیل‌گر سیستم با کاربران و مدیران تعامل می‌کند تا الزامات سیستم جدید را به دقت جمع‌آوری و مستند کند. در مثال شرکت تولیدی، این فاز شامل مصاحبه با مدیرعامل، تیم مالی و واحد تدارکات می‌شد تا دقیقاً مشخص شود چرا فرآیند تأیید رسید انبار مجدداً به مدیرعامل ارسال می‌شود. تحلیل‌گر در این مرحله به دنبال “چگونگی” و “چرایی” مسائل است.

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

پیاده‌سازی یا Implementation: کدنویسی، نصب و راه‌اندازی سخت‌افزار و نرم‌افزار در این مرحله انجام می‌شود.

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

استقرار یا Deployment: سیستم در محیط واقعی سازمان مستقر شده و کاربران نهایی شروع به استفاده از آن می‌کنند.

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

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

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

۲. رویکرد چابک یا Agile Methodologies: انعطاف‌پذیری در دنیای متغیر

در نقطه مقابل SDLC، رویکردهای چابک قرار دارند که بر انعطاف‌پذیری، همکاری مستمر با مشتری (کاربر) و تحویل تدریجی نرم‌افزار تأکید دارند. این روش‌ها به ویژه برای پروژه‌هایی که الزامات آنها ممکن است در طول زمان تغییر کند، بسیار مناسب هستند. Scrum و Kanban دو فریم‌ورک محبوب در این دسته هستند.
Scrum: در Scrum، کار در “اسپرینت‌های” کوتاه (معمولاً ۲ تا ۴ هفته) انجام می‌شود. در هر اسپرینت، تیم یک بخش کوچک اما قابل استفاده از سیستم را توسعه داده و به کاربران ارائه می‌دهد تا بازخورد دریافت کند. این رویکرد مداوم بازخورد (Feedback Loop) به بهبود مستمر کمک می‌کند.
برای مثال (درک بهتر اسکرام)، فرض کنید یک شرکت توسعه اپلیکیشن موبایل برای مدیریت سفارشات آنلاین، از Scrum استفاده می‌کند. در اسپرینت اول، قابلیت جستجوی محصول و افزودن به سبد خرید را توسعه می‌دهند. پس از تست و دریافت بازخورد از کاربران، در اسپرینت دوم به سراغ قابلیت پرداخت آنلاین می‌روند. این رویکرد باعث می‌شود محصول نهایی کاملاً بر اساس نیازهای واقعی کاربران شکل بگیرد.
Kanban: کانبان بیشتر یک سیستم بصری برای مدیریت جریان کار است. وظایف در یک برد (Board) با ستون‌های مختلف (مثلاً “در انتظار”، “در حال انجام”، “تکمیل شده”) نمایش داده می‌شوند. این روش به تیم کمک می‌کند تا گلوگاه‌ها را شناسایی کرده و جریان کار را بهینه سازد.
مثلاً تیم پشتیبانی IT یک سازمان بزرگ از Kanban برای مدیریت تیکت‌های پشتیبانی استفاده می‌کند. هر تیکت یک کارت در برد Kanban است و با تغییر وضعیت آن (مثلاً از “جدید” به “در حال بررسی” یا “حل شده”)، مدیران و کاربران می‌توانند وضعیت لحظه‌ای را مشاهده کنند.
مزایا: سرعت بالا در تحویل، انعطاف‌پذیری در برابر تغییرات، همکاری نزدیک با مشتری و رضایت بیشتر کاربر.
معایب: نیاز به تیم‌های خودگردان و متعهد، و در برخی موارد، کمتر بودن مستندسازی رسمی.

۳. تحلیل ساختار یافته یا Structured Analysis: تمرکز بر فرآیندها و داده‌ها

این روش‌شناسی بر جداسازی فرآیندها و داده‌ها در سیستم تأکید دارد. ابزارهای اصلی آن عبارتند از:
نمودارهای جریان داده (DFD – Data Flow Diagrams): این نمودارها، جریان اطلاعات را در یک سیستم نشان می‌دهند؛ یعنی داده‌ها از کجا می‌آیند، چگونه پردازش می‌شوند و به کجا می‌روند. این ابزار برای تحلیل‌گر سیستم در درک چگونگی ورود، پردازش و خروج اطلاعات بسیار مفید است.
فرهنگ (مرجع) داده (Data Dictionary): شامل تعاریف دقیق تمام داده‌های مورد استفاده در سیستم است.
نمودارهای موجودیت-رابطه (ERD – Entity-Relationship Diagrams): این نمودارها روابط بین موجودیت‌های داده‌ای (مانند مشتری، سفارش، محصول) را نشان می‌دهند.
برای مثال، در سیستم مالی شرکت تولیدی ، یک DFD می‌تواند نشان دهد که درخواست خرید (داده) چگونه از واحد درخواست‌کننده به واحد تدارکات و سپس به مدیرعامل (پردازش) می‌رود و در نهایت منجر به خرید و ثبت رسید انبار می‌شود. ERD نیز می‌تواند نشان دهنده ارتباط بین موجودیت‌های “درخواست خرید”، “پیش‌فاکتور”، “کالا” و “رسید انبار” باشد.
مزایا: درک واضح از فرآیندها و داده‌ها، مناسب برای سیستم‌های پیچیده که جریان اطلاعات در آنها حیاتی است.
معایب: ممکن است برای سیستم‌های شیءگرا کمتر کارآمد باشد و تمرکز کمتری بر رفتار سیستم دارد.

۴. تحلیل شیء گرا یا Object-Oriented Analysis – OOA: نگاه جامع سیستمی

بر خلاف تحلیل ساختاریافته که فرآیندها و داده‌ها را جدا می‌بیند، تحلیل شیءگرا سیستم را به عنوان مجموعه‌ای از “اشیاء” در نظر می‌گیرد که هم داده‌ها (ویژگی‌ها) و هم رفتارها (متدها) را در خود encapsulate (کپسوله‌سازی) کرده‌اند. زبان مدل‌سازی یکپارچه (UML – Unified Modeling Language) ابزار اصلی در این روش‌شناسی است و شامل نمودارهای مختلفی مانند نمودار کلاس، نمودار توالی و نمودار مورد کاربرد (Use Case Diagram) می‌شود.
برای مثال، در یک سیستم مدیریت کتابخانه، به جای فکر کردن به فرآیندهای “امانت دادن کتاب” و “برگرداندن کتاب” به صورت جداگانه، یک “شیء کتاب” داریم که می‌تواند متدهایی مانند امانت_گرفتن() و برگرداندن() را داشته باشد. همچنین یک “شیء کاربر” می‌تواند متد جستجوی_کتاب() را اجرا کند. این رویکرد به ایجاد سیستم‌های قابل توسعه و نگهداری کمک می‌کند.
مزایا: مدل‌سازی نزدیک‌تر به دنیای واقعی، قابلیت استفاده مجدد از کد (reusability) و مناسب برای سیستم‌های پیچیده با تعاملات زیاد.
معایب: پیچیدگی اولیه در یادگیری مفاهیم شیءگرا و ممکن است برای پروژه‌های بسیار کوچک بیش از حد باشد.
هیچ روش‌شناسی واحدی برای تمام پروژه‌ها و سازمان‌ها ایده‌آل نیست. انتخاب روش مناسب بستگی به عوامل متعددی دارد، از جمله:
اندازه و پیچیدگی پروژه: پروژه‌های بزرگ و پیچیده ممکن است از ساختار SDLC بهره ببرند، در حالی که پروژه‌های کوچکتر و با الزامات نامشخص‌تر، به سمت رویکردهای چابک سوق پیدا می‌کنند.
میزان تغییرپذیری الزامات: اگر الزامات پروژه به احتمال زیاد تغییر می‌کنند، رویکردهای چابک مناسب‌ترند.
فرهنگ سازمانی: برخی سازمان‌ها به ساختار و مستندسازی بالا تمایل دارند، در حالی که برخی دیگر انعطاف‌پذیری و همکاری نزدیک را ترجیح می‌دهند.
تجربه تیم: آشنایی و تجربه تیم تحلیل و توسعه با یک روش‌شناسی خاص نیز مؤثر است.
در نهایت، یک تحلیل‌گر سیستم حرفه‌ای و با فهم سیستمی ، باید بتواند با ابزارهای گوناگون “روش سیستمی” کار کند و با تشخیص نیازها و شرایط خاص هر سازمان، بهترین روش‌شناسی را برای دستیابی به اهداف پروژه انتخاب و پیاده‌سازی کند. این مهارت در انتخاب و تلفیق رویکردها است که تفاوت یک تحلیل‌گر معمولی با یک متخصص برجسته را رقم می‌زند.

اعضای تیم تحلیل و طراحی سیستم

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

الف. کاربران، ب. مدیران، ج. تحلیل‌گران، د. طراحان و هـ. برنامه‌نویس‌ها.

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

کاربران سیستم

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

الف. چنانچه معمول است، همیشه حق با مشتری است هر چقدر پرتوقع، نامطبوع یا غیرمنطقی به نظر برسد؛

ب. مشتری فردی است که نهایتاً برای سیستم پول پرداخت می‌کند و این حق را داراست که در صورت نارضایتی از محصول، از پرداخت پول خودداری کند.

مدیران

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

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

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

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

نکات پایانی درس پنجم

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

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

الف. از افراد درون سازمان برای سپردن مسئولیت بهینه‌سازی کمک نگیرید؛

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

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

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

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

بدون دیدگاه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *