چگونه سیستم سازی کنیم؟ از عارضه یابی تا استقرار سیستم

اگر چند روز نباشید، چه اتفاقی برای کسب‌وکارتان می‌افتد؟

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

این پرسش‌ها در واقع نقطه شروع سیستم سازی هستند.

پاسخ کوتاه: چگونه سیستم سازی کنیم؟

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

به زبان ساده:

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

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

چرا سیستم سازی معمولاً از جایی که فکر می‌کنیم شروع نمی‌شود؟

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

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

هیچ‌کدام ذاتاً اشتباه نیستند؛ مشکل زمانی ایجاد می‌شود که قبل از فهمیدن مسئله، راه‌حل را انتخاب کنیم.

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

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

سیستم سازی یعنی قبل از اینکه بپرسیم «چه ابزاری بخریم؟»، بپرسیم:

«واقعاً چه چیزی در سازمان ما درست کار نمی‌کند و چرا؟»

مرحله اول: DNA کسب‌وکار را بشناسید

هیچ دو سازمانی دقیقاً شبیه هم نیستند؛ حتی اگر در یک صنعت فعالیت کنند.

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

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

قبل از طراحی سیستم باید بدانید:

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

این شناخت، پایه معماری سیستم سازمان است.

مرحله دوم: عارضه‌یابی کنید؛ نه اینکه فقط علائم را جمع کنید

سیستم سازی بدون عارضه‌یابی می‌تواند سازمان را بسیار منظم‌تر کند؛ اما در مسیر اشتباه.

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

مثلاً:

عارضه: فروش پایین است.

این جمله هنوز برای طراحی سیستم کافی نیست.

ممکن است علت یکی از این موارد باشد:

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

هر کدام از این مشکلات، سیستم متفاوتی می‌طلبد.

یک سؤال کاربردی در عارضه‌یابی

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

«اگر این فرد، این مدیر یا این نیروی خاص فردا در سازمان نباشد، آیا این مشکل همچنان وجود خواهد داشت؟»

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

مرحله سوم: وضع موجود را همان‌طور که واقعاً هست ثبت کنید

یکی از اشتباهات رایج در پروژه‌های سیستم سازی این است که مدیران فرآیند «باید» را توضیح می‌دهند، نه فرآیند «واقعاً انجام‌شده» را.

این دو با هم فرق دارند.

ممکن است در دستورالعمل نوشته شده باشد:

فروش ← تأیید مالی ← ثبت سفارش ← ارسال

اما در عمل اتفاق دیگری بیفتد:

فروش ← تماس با مدیر ← پیام در واتساپ ← تماس با مالی ← اصلاح سفارش ← تماس دوباره با فروش ← ارسال

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

بنابراین در این مرحله باید مشخص شود:

• کار واقعاً از کجا شروع می‌شود؟
• چه کسی آن را انجام می‌دهد؟
• چه اطلاعاتی وارد فرآیند می‌شود؟
• چه تصمیم‌هایی گرفته می‌شود؟
• چه خروجی‌ای تولید می‌شود؟
• کار بین چه واحدهایی جابه‌جا می‌شود؟
• کجا منتظر تأیید می‌ماند؟
• کجا دوباره‌کاری اتفاق می‌افتد؟
• کجا اطلاعات از بین می‌رود؟
• چه استثناهایی باعث می‌شوند فرآیند از مسیر اصلی خارج شود؟

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

مرحله چهارم: گلوگاه‌ها را پیدا کنید

قرار نیست در اولین پروژه سیستم سازی همه مشکلات سازمان را حل کنید.

یکی از نشانه‌های یک پروژه بالغ این است که بتواند تشخیص دهد کدام مشکل باید اول حل شود.

فرض کنید سازمان ۳۰ مشکل دارد. اگر همه را هم‌زمان وارد پروژه کنید، احتمالاً با یک پروژه سنگین، پرهزینه و فرسایشی مواجه می‌شوید.

به جای آن، مشکلات را بر اساس اثرشان بررسی کنید.

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

اصل مهم این است:

سیستم سازی موفق الزاماً از بزرگ‌ترین مشکل شروع نمی‌کند؛ از مشکلی شروع می‌کند که بیشترین اثر را با امکان اجرای واقعی دارد.

مرحله پنجم: وضعیت مطلوب را طراحی کنید

بعد از اینکه فهمیدیم امروز چه اتفاقی می‌افتد، باید تصمیم بگیریم فردا چه اتفاقی باید بیفتد.

در این مرحله سؤال اصلی این نیست که:

«چطور همین فرآیند فعلی را نرم‌افزاری کنیم؟»

سؤال بهتر این است:

«اگر بخواهیم این فرآیند را از نو و بدون محدودیت‌های فعلی طراحی کنیم، بهترین جریان کار چه شکلی خواهد بود؟»

برای هر فرآیند باید بتوانیم حداقل این موارد را مشخص کنیم:

• نقطه شروع
• ورودی‌ها
• فعالیت‌ها
• مسئول هر فعالیت
• تصمیم‌ها و شرایط
• خروجی
• مشتری یا واحد دریافت‌کننده خروجی
• شاخص‌های عملکرد
• استثناها
• سطح دسترسی و تأییدهای ضروری

این مرحله جایی است که معماری فرآیند اهمیت پیدا می‌کند.

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

ممکن است سه واحد یک اطلاعات مشابه را جداگانه ثبت کنند.

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

سیستم سازی قرار نیست فقط کارها را رسمی‌تر کند؛ باید کار را ساده‌تر، قابل کنترل‌تر و قابل تکرارتر کند.

مرحله ششم: فرآیندها و مسئولیت‌ها را استاندارد کنید

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

استانداردسازی می‌تواند شامل این موارد باشد:

استاندارد فعالیت‌ها

برای کارهای تکرارشونده باید مشخص باشد چه کاری، با چه ورودی و چه خروجی‌ای انجام می‌شود.

استاندارد مسئولیت‌ها

باید معلوم باشد چه کسی:

• انجام می‌دهد
• تأیید می‌کند
• تصمیم می‌گیرد
• اطلاعات را دریافت می‌کند
• پاسخ‌گو است

استاندارد اطلاعات

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

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

استاندارد تصمیم‌گیری

هر تصمیمی نباید برای مدیر ارسال شود.

باید مشخص شود:

• چه تصمیمی در سطح کارشناس گرفته می‌شود؟
• چه تصمیمی نیاز به سرپرست دارد؟
• چه تصمیمی باید به مدیر ارشد برسد؟

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

مرحله هفتم: حالا درباره نرم‌افزار تصمیم بگیرید

اینجاست که فناوری وارد داستان می‌شود.

نه قبل از آن.

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

برای همین، انتخاب فناوری باید بر اساس نیاز واقعی انجام شود.

بسته به مسئله، ممکن است سازمان به یکی از این ابزارها یا ترکیبی از آن‌ها نیاز داشته باشد:

• CRM
• ERP
• BPMS
• اتوماسیون اداری
• ابزارهای Workflow
• سیستم‌های گزارش‌گیری و BI
• ابزارهای مدیریت پروژه
• یکپارچه‌سازی بین نرم‌افزارها

بنابراین سؤال درست این نیست که:

«ERP بهتر است یا BPMS؟»

سؤال درست این است:

«کدام بخش از معماری سازمان من نیاز به چه نوع فناوری دارد؟»

گاهی یک ERP مناسب است. گاهی BPMS. گاهی CRM. و گاهی اصلاً مشکل اصلی با نرم‌افزار حل نمی‌شود.

مرحله هشتم: سیستم را مستقر کنید؛ فقط تحویل ندهید

یکی از دلایل شکست پروژه‌های سیستم سازی این است که پروژه در زمان تحویل نرم‌افزار یا مستندات تمام‌شده تلقی می‌شود.

اما از نگاه سازمان، آنجا تازه مرحله مهمی شروع شده است.

افراد باید بدانند:

• چرا این تغییر اتفاق افتاده؟
• چه چیزی در روش کارشان تغییر کرده؟
• مسئولیت جدیدشان چیست؟
• از چه ابزارهایی باید استفاده کنند؟
• اگر با یک استثنا مواجه شدند چه کنند؟
• عملکردشان چگونه سنجیده می‌شود؟

به همین دلیل، استقرار سیستم معمولاً نیازمند ترکیبی از:

آموزش + همراهی + اصلاح فرآیند + رفع مقاومت + پایش

است.

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

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

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

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

باید مشخص شود:

کدام شاخص واقعاً نشان می‌دهد فرآیند خوب کار می‌کند؟

مثلاً در یک فرآیند فروش ممکن است شاخص‌های مهم شامل این موارد باشند:

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

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

اصل مهم این است که شاخص باید به تصمیم مدیریتی وصل باشد.

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

سیستم سازی با مستندسازی چه تفاوتی دارد؟

مستندسازی یکی از اجزای سیستم سازی است، اما خود سیستم سازی نیست.

فرض کنید برای فرآیند استخدام یک دستورالعمل ۳۰ صفحه‌ای نوشته‌اید. اگر هنوز:

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

صرفاً یک سند طولانی‌تر ساخته‌اید، نه یک سیستم بهتر.

مستندات باید از سیستم پشتیبانی کنند، نه اینکه جای سیستم را بگیرند.

سیستم سازی با خرید نرم‌افزار چه تفاوتی دارد؟

خرید نرم‌افزار یعنی یک ابزار تهیه کرده‌اید.

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

ممکن است یک شرکت چند نرم‌افزار داشته باشد و همچنان سیستم نداشته باشد.

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

پس:

نرم‌افزار بخشی از سیستم است؛ نه معادل سیستم.

آیا سیستم سازی فقط برای شرکت‌های بزرگ است؟

خیر. اما شکل اجرای آن با اندازه سازمان تغییر می‌کند.

در کسب‌وکار کوچک

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

• حذف وابستگی به صاحب کسب‌وکار
• استاندارد کردن فروش
• ثبت و پیگیری مشتریان
• تعریف روال مالی
• مشخص کردن مسئولیت‌ها
• ایجاد داشبوردهای ساده مدیریتی

در سازمان متوسط

معمولاً مسائل پیچیده‌تر می‌شوند:

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

در سازمان بزرگ

تمرکز می‌تواند روی معماری فرآیند، حاکمیت، یکپارچگی سیستم‌ها، مدیریت تغییر، ERP، BPMS، داده و بهبود مستمر قرار گیرد.

بنابراین سیستم سازی یک «محصول» نیست که برای سازمان کوچک یا بزرگ نسخه یکسان داشته باشد.

از کجا بفهمیم آماده سیستم سازی هستیم؟

اگر چند مورد از نشانه‌های زیر را می‌بینید، احتمالاً زمان جدی‌تری برای سیستم سازی فرا رسیده است:

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

وجود یکی از این نشانه‌ها به معنی نیاز فوری به یک پروژه بزرگ نیست؛ اما چند نشانه هم‌زمان ارزش بررسی عمیق‌تر دارد.

یک اشتباه مهم: سیستم سازی را با «بزرگ‌تر کردن سازمان» اشتباه نگیرید

گاهی مدیر برای حل بی‌نظمی، نیروی بیشتری استخدام می‌کند.

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

مثلاً اگر تأیید یک سفارش سه روز طول می‌کشد، اضافه کردن یک کارشناس دیگر لزوماً زمان را کم نمی‌کند.

اول باید پرسید:

چرا این تأیید سه روز طول می‌کشد؟

شاید اطلاعات ناقص است.

شاید اختیار در سطح اشتباه قرار دارد.

شاید فرآیند چند بار تکرار می‌شود.

شاید سیستم اطلاعات لازم را در اختیار تصمیم‌گیرنده نمی‌گذارد.

سیستم سازی از همین جنس سؤال‌ها شروع می‌شود.

اگر بخواهیم سیستم سازی را از فردا شروع کنیم، چه کنیم؟

اگر هنوز پروژه سیستم سازی رسمی ندارید، لازم نیست از روز اول یک پروژه چندماهه تعریف کنید.

یک شروع عملی می‌تواند این باشد:

روز اول: یک فرآیند مهم را انتخاب کنید

مثلاً فروش، خرید، استخدام، خدمات مشتری یا صدور سفارش.

روز دوم: فرآیند واقعی را با یکی از کارکنان اجرا کنید

از او بخواهید دقیقاً توضیح دهد آخرین بار این کار را چگونه انجام داده است.

روز سوم: نقاط توقف و دوباره‌کاری را ثبت کنید

دنبال جاهایی بگردید که کار منتظر تأیید، اطلاعات یا تصمیم می‌ماند.

روز چهارم: مسئولیت‌ها را روشن کنید

برای هر مرحله مشخص کنید چه کسی انجام می‌دهد و چه کسی تصمیم می‌گیرد.

روز پنجم: یک نسخه ساده‌تر از فرآیند طراحی کنید

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

روز ششم: شاخص تعریف کنید

فقط یک یا دو شاخص که واقعاً کیفیت فرآیند را نشان می‌دهند انتخاب کنید.

روز هفتم: تصمیم بگیرید چه چیزی باید استاندارد یا خودکار شود

در این مرحله تازه می‌توانید درباره فرم، نرم‌افزار، Workflow، CRM، ERP یا BPMS تصمیم بگیرید.

این تمرین قرار نیست جای یک پروژه حرفه‌ای سیستم سازی را بگیرد؛ اما کمک می‌کند سازمان را از «حرف کلی درباره سیستم سازی» به «دیدن یک فرآیند واقعی» برسانید.

یک مدل ساده برای تشخیص سطح سیستم سازی سازمان

برای ارزیابی اولیه می‌توانید سازمان را در پنج سطح ببینید:

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

آیا سیستم سازی یعنی حذف نقش انسان؟

نه.

اتفاقاً یکی از برداشت‌های اشتباه از سیستم سازی این است که تصور کنیم هدف آن حذف افراد است.

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

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

به بیان دیگر:

سیستم سازی قرار نیست انسان را حذف کند؛ قرار است ظرفیت انسان را از کارهای قابل‌سیستم‌سازی آزاد کند.

از چه زمانی به مشاور سیستم سازی نیاز داریم؟

اگر مسئله محدود به یک فرآیند کوچک باشد، ممکن است تیم داخلی بتواند آن را اصلاح کند.

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

مشاور سیستم سازی قرار نیست صرفاً چند فرم یا نمودار تحویل دهد.

نقش اصلی او این است که:

1. وضعیت موجود را بفهمد.
2. مسئله واقعی را از نشانه‌ها جدا کند.
3. گلوگاه‌ها را شناسایی کند.
4. فرآیند مطلوب را طراحی کند.
5. ارتباط افراد، فرآیندها، اطلاعات و فناوری را مشخص کند.
6. راهکار اجرایی و قابل استقرار پیشنهاد دهد.
7. در مسیر استقرار و بهبود، سازمان را همراهی کند.

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

اگر بخواهیم تمام این مقاله را در یک جمله خلاصه کنیم:

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

مسیر آن هم معمولاً از اینجا عبور می‌کند:

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

و مهم‌تر از همه، این مسیر برای هر سازمان باید متناسب با واقعیت همان سازمان طراحی شود.

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

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

پرسش‌های متداول

سیستم سازی کسب و کار را از کجا شروع کنیم؟

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

آیا برای سیستم سازی حتماً به نرم‌افزار نیاز داریم؟

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

سیستم سازی چقدر زمان می‌برد؟

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

آیا سیستم سازی فقط برای شرکت‌های بزرگ است؟

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

تفاوت سیستم سازی و اتوماسیون چیست؟

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

آیا سیستم سازی باعث کاهش نیروی انسانی می‌شود؟

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

دعوت به اقدام

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

از خودتان بپرسید: اگر فردا یکی از افراد کلیدی سازمان نباشد، کدام فرآیندها متوقف می‌شوند؟

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