فهرست مطالب
- نکات کلیدی
- سیستم سازی کسب و کار چیست؟
- چرا کسبوکارها به سیستم سازی نیاز پیدا میکنند؟
- آیا سیستم سازی فقط برای شرکتهای بزرگ است؟
- سیستم سازی از کجا شروع میشود؟
- تفاوت سیستم سازی با مستندسازی چیست؟
- تفاوت سیستم سازی با خرید نرم افزار چیست؟
- چه زمانی باید سیستم سازی را جدیتر کنیم؟
- سیستم سازی سازمانی چه ارتباطی با BPM دارد؟
- آیا سیستم سازی باعث حذف نیروهای انسانی میشود؟
- یک اشتباه رایج: سیستم سازی قبل از عارضه یابی
- سیستم سازی موفق چه خروجیهایی دارد؟
- از کجا بفهمیم سیستم سازی در سازمان ما درست طراحی شده است؟
- سوالات متداول
وقتی مدیر یک شرکت برای چند روز از مجموعه دور میشود، آیا کارها با همان کیفیت جلو میروند؟ اگر یک نیروی کلیدی استعفا بدهد، دانش و روش انجام کار همراه او از سازمان خارج میشود؟ اگر برای یک تصمیم ساده، چند نفر باید منتظر تأیید یک نفر باشند، احتمالاً مسئله فقط کمبود نیروی انسانی نیست؛ بخشی از مشکل به «سیستم» برمیگردد.
سیستم سازی کسب و کار یعنی کاری کنیم که انجام درست کارها فقط به حافظه، تجربه، سلیقه یا حضور چند نفر وابسته نباشد. برای رسیدن به این نقطه باید فرآیندها، نقشها، مسئولیتها، قواعد تصمیمگیری، اطلاعات، شاخصها و در صورت نیاز فناوری در کنار هم طراحی شوند.
نکته مهم این است که سیستم سازی با «نرمافزار خریدن» یا «چند دستورالعمل نوشتن» یکی نیست. نرمافزار میتواند بخشی از یک سیستم باشد، اما اگر فرآیند از ابتدا درست فهمیده نشده باشد، دیجیتالی کردن همان آشفتگی قبلی فقط آشفتگی را سریعتر میکند.
نکات کلیدی
- سیستم سازی کسب و کار یعنی طراحی یک روش قابل تکرار برای انجام کارها؛ روشی که وابستگی غیرضروری سازمان به افراد را کمتر و امکان مدیریت و بهبود را بیشتر کند.
- سیستم سازی از فرآیند شروع میشود، نه از نرمافزار. ابتدا باید بدانیم کار اکنون چگونه انجام میشود، کجا متوقف میشود و چه نتیجهای باید تولید کند.
- هدف سیستم سازی حذف انسان نیست. هدف این است که انسان درگیر کارهای تکراری، تصمیمهای بدون قاعده و جستوجوی اطلاعات نشود و روی کارهایی تمرکز کند که به قضاوت و تخصص نیاز دارند.
- یک سیستم خوب باید قابل اندازهگیری و قابل بهبود باشد. اگر ندانیم چه کسی مسئول فرآیند است و عملکرد آن را با چه شاخصی میسنجیم، سیستم روی کاغذ باقی میماند.
- ERP، BPMS و اتوماسیون ابزار هستند، نه خود سیستم سازی. انتخاب فناوری باید بعد از شناخت مسئله، فرآیند و معماری مطلوب انجام شود.
سیستم سازی کسب و کار چیست؟
اگر بخواهیم خیلی ساده بگوییم، سیستم سازی یعنی تبدیل «روش انجام کار در ذهن افراد» به «روش انجام کار در ساختار سازمان».
در یک کسبوکار فردمحور، ممکن است پاسخ بسیاری از سؤالها این باشد:
«فلانی میداند.»
فلانی میداند مشتری را چگونه پیگیری کند.
فلانی میداند قیمت را از کجا بگیرد.
فلانی میداند چه زمانی مدیر باید در جریان قرار بگیرد.
فلانی میداند اگر مشتری اعتراض کرد چه کند.
فلانی میداند سفارش را به چه کسی تحویل بدهد.
تا زمانی که این افراد هستند، سازمان ظاهراً مشکلی ندارد. مشکل زمانی آشکار میشود که حجم کار بالا برود، شعبه جدید ایجاد شود، مدیر بخواهد رشد کند یا یکی از افراد کلیدی از سازمان خارج شود.
در سیستمسازی، سؤال از «چه کسی بلد است؟» به سمت «این کار در سازمان چگونه باید انجام شود؟» تغییر میکند.
این تغییر، یک تفاوت مدیریتی بسیار مهم است.
سیستم سازی چه چیزی را استاندارد میکند؟
سیستم سازی میتواند بخشهای مختلفی از کار سازمان را دربر بگیرد، از جمله:
- مراحل انجام یک فرآیند
- ورودی و خروجی هر فرآیند
- مسئول هر فعالیت
- سطح دسترسی و اختیار افراد
- قواعد تصمیمگیری
- نحوه ثبت و گردش اطلاعات
- نقاط کنترل و تأیید
- شاخصهای اندازهگیری
- ارتباط بین واحدها
- نحوه رسیدگی به استثناها
- روش آموزش نیروهای جدید
- ابزارهای نرمافزاری مورد نیاز
بنابراین سیستم سازی یک «سند» نیست؛ مجموعهای از اجزای بههمپیوسته است که باید در عمل کار کنند.
چرا کسبوکارها به سیستم سازی نیاز پیدا میکنند؟
بسیاری از شرکتها در سالهای اول فعالیت، بدون سیستم رسمی هم رشد میکنند. مدیر همهچیز را میداند، تیم کوچک است و ارتباطات مستقیم است.
اما با بزرگتر شدن سازمان، همان روش قبلی معمولاً جواب نمیدهد.
برای مثال، وقتی یک شرکت از ۵ نفر به ۳۰ نفر میرسد، تعداد ارتباطات، تصمیمها، تحویلها، مشتریان و استثناها بیشتر میشود. اگر روش انجام کارها همچنان فقط در ذهن مدیر و چند نیروی قدیمی باشد، مدیر بهتدریج به گلوگاه سازمان تبدیل میشود.
اینجا یکی از مهمترین نشانههای نیاز به سیستم سازی دیده میشود:
هرچه سازمان بزرگتر میشود، مدیر بهجای اینکه از سازمان فاصله بگیرد و روی تصمیمهای مهمتر تمرکز کند، بیشتر درگیر عملیات روزمره میشود.
وابستگی به افراد
وابستگی به نیروی انسانی به خودی خود مشکل نیست؛ هر سازمانی به افراد متخصص نیاز دارد.
مشکل از جایی شروع میشود که یک نفر تبدیل به تنها نقطه دسترسی به دانش یا تنها مسیر انجام یک کار شود.
| وضعیت | حالت فردمحور | حالت سیستممحور |
|---|---|---|
| دانش | در ذهن افراد | مستند و قابل انتقال |
| اجرای کار | وابسته به شخص | وابسته به فرآیند |
| آموزش نیروی جدید | استاد-شاگردی و سلیقهای | مسیر آموزشی مشخص |
| تصمیمگیری | بر اساس فرد | بر اساس قواعد و سطح اختیار |
| کنترل | بعد از بروز مشکل | در نقاط مشخص فرآیند |
| اطلاعات | پراکنده | ساختاریافته و قابل دسترسی |
| بهبود | واکنشی | مستمر و مبتنی بر داده |
این جدول به معنی حذف تجربه افراد نیست. هدف این است که تجربه افراد به دارایی سازمان تبدیل شود، نه اینکه فقط تا زمانی ارزشمند باشد که آن فرد در شرکت حضور دارد.
آیا سیستم سازی فقط برای شرکتهای بزرگ است؟
خیر.
اتفاقاً یکی از خطاهای رایج این است که سیستم سازی را پروژهای مخصوص سازمانهای بسیار بزرگ تصور کنیم.
یک کسبوکار کوچک هم ممکن است به سیستم نیاز داشته باشد؛ فقط اندازه و پیچیدگی سیستم متفاوت است.
برای یک تیم ۵ نفره شاید یک فرآیند ساده فروش، الگوی پیگیری مشتری، مسئولیتهای مشخص و داشبورد پایه کافی باشد.
برای یک سازمان چندصدنفره، موضوع میتواند شامل معماری فرآیند، مالکیت فرآیند، سطوح دسترسی، گردش کار، یکپارچگی سیستمها، شاخصهای عملکرد و حاکمیت داده باشد.
پس سؤال درست این نیست که «آیا شرکت ما آنقدر بزرگ شده که سیستمسازی لازم داشته باشد؟»
سؤال بهتر این است:
«کدام بخش از کسبوکار ما به اندازهای مهم یا پیچیده شده که دیگر نباید با روشهای شفاهی و فردی مدیریت شود؟»
سیستم سازی از کجا شروع میشود؟
سیستم سازی موفق معمولاً با خرید ابزار شروع نمیشود.
اول باید مسئله را بفهمیم.
در رویکردهای حرفهای مدیریت فرآیند نیز تأکید بر نگاه انتهابهانتها، مدیریت فرآیند و بهبود مستمر است؛ APQC در منابع منتشرشده در سال 2026 بر مدیریت فرآیند، تفکر فرآیندی، نگاشت فرآیندهای End-to-End و اتصال به نتایج کسبوکار تأکید کرده است.
برای یک پروژه سیستم سازی، میتوان این مسیر را — همان مسیری که در مشاوره کسبوکار با کارفرماها طی میکنیم — به ۹ گام عملی تقسیم کرد:
۱. شناخت DNA کسبوکار
قبل از طراحی سیستم باید بدانیم سازمان واقعاً چگونه کار میکند.
صنعت، مدل درآمدی، ساختار تصمیمگیری، مشتریان، فرهنگ سازمانی، محدودیتهای منابع و مزیت رقابتی همه روی طراحی سیستم اثر میگذارند.
به همین دلیل نسخه یکسان برای همه شرکتها معمولاً نتیجه خوبی نمیدهد.
۲. عارضهیابی
در این مرحله باید به جای حدس زدن، مسئلههای واقعی سازمان شناسایی شوند، نه چیزی که در جلسات مدیریتی حدس زده میشود.
مثلاً:
- چرا سفارشها دیر تحویل میشوند؟
- چرا مشتریان پیگیری نمیشوند؟
- چرا مدیر باید همه چیز را تأیید کند؟
- چرا خطاهای مشابه مرتب تکرار میشوند؟
- چرا اطلاعات بین واحدها گم میشود؟
- چرا یک نیروی جدید چند ماه طول میکشد تا به بهرهوری برسد؟
عارضهیابی کمک میکند سیستم را برای حل «مسئله واقعی» طراحی کنیم، نه برای یک تصویر فرضی از سازمان.
۳. شناخت وضع موجود
قبل از اینکه بگوییم فرآیند چگونه باید باشد، باید بدانیم الان چگونه انجام میشود.
این مرحله معمولاً با گفتوگو با افراد، مشاهده عملیات، بررسی فرمها و فایلها، بررسی سیستمهای موجود و ترسیم جریان واقعی کار انجام میشود.
نکته مهم اینجاست:
فرآیندی که در جلسه مدیران تعریف میشود الزاماً همان فرآیندی نیست که در کف سازمان اتفاق میافتد.
گاهی فرآیند رسمی یک صفحه است، اما فرآیند واقعی شامل چند تماس، فایل Excel، پیامرسان، تأیید شفاهی و رفتوبرگشت بین واحدهاست.
همین فاصله، یکی از جاهایی است که گلوگاهها پنهان میشوند.
۴. شناسایی گلوگاهها
همه فرآیندها ارزش یکسانی برای بهبود ندارند.
باید مشخص شود کدام نقاط بیشترین اثر را بر درآمد، هزینه، سرعت، کیفیت، تجربه مشتری، ریسک و ظرفیت رشد دارند.
در این مرحله ممکن است مشخص شود مشکل اصلی سازمان کمبود نیرو نیست؛ بلکه یک تأیید اضافی، نبود مالک فرآیند، اطلاعات ناقص یا دوبارهکاری بین دو واحد است.
۵. طراحی وضعیت مطلوب
بعد از شناخت وضع موجود، فرآیند مطلوب طراحی میشود.
در این مرحله مشخص میکنیم:
- چه فعالیتهایی باید باقی بمانند؟
- چه فعالیتهایی باید حذف شوند؟
- چه فعالیتهایی باید ادغام شوند؟
- چه تصمیمهایی باید واگذار شوند؟
- چه اطلاعاتی باید در چه نقطهای ثبت شوند؟
- مسئول هر مرحله چه کسی است؟
- خروجی قابل قبول چیست؟
- اگر شرایط عادی نبود، مسیر جایگزین چیست؟
این همان نقطهای است که سیستم سازی از «مرتب کردن کارها» به طراحی معماری عملیاتی سازمان نزدیک میشود.
۶. استانداردسازی و مستندسازی
حالا روش مطلوب باید قابل انتقال باشد.
مستند خوب باید به اندازهای باشد که فرد مناسب بداند:
- چه کاری؟
- توسط چه کسی؟
- در چه زمانی؟
- با چه ورودی؟
- با چه استانداردی؟
- با چه خروجی؟
- در چه شرایطی؟
- و با چه شاخصی؟
مستندسازی فرآیند در منابع تخصصی نیز حول عناصری مانند نقشها، فعالیتها، خروجیها و وابستگیها شکل میگیرد.
۷. انتخاب فناوری
حالا میتوانیم درباره نرمافزار تصمیم بگیریم.
بسته به مسئله، ممکن است ابزارهایی مانند ERP، BPMS، CRM، اتوماسیون اداری، Workflow، ابزارهای تحلیل داده یا RPA مناسب باشند.
اما نکته مهم این است:
هر مسئلهای ERP نمیخواهد و هر فرآیندی هم الزاماً به BPMS نیاز ندارد.
اول فرآیند و نیاز سازمان مشخص میشود؛ بعد فناوری انتخاب میشود.
۸. استقرار و آموزش
سیستمی که فقط در فایل طراحی شده باشد، هنوز سیستم سازمان نیست.
باید مسئولیتها منتقل شوند، افراد آموزش ببینند، ابزارها تنظیم شوند، فرآیند در عمل اجرا شود، خطاهای اولیه ثبت شوند و اصلاحات انجام شود.
تغییر واقعی معمولاً در همین مرحله اتفاق میافتد.
۹. اندازهگیری و بهبود مستمر
سیستم سازی نقطه پایان ندارد.
وقتی فرآیند اجرا شد باید ببینیم آیا واقعاً نتیجه مورد انتظار را ایجاد کرده است یا نه.
برای مثال:
- زمان انجام فرآیند چقدر شده؟
- چند درصد کارها برگشت میخورند؟
- چند مورد نیاز به اصلاح دارند؟
- چند مرحله بدون ارزش افزوده حذف شده؟
- مشتری چقدر سریع پاسخ میگیرد؟
- کدام مرحله بیشترین تأخیر را دارد؟
مدیریت فرآیند حرفهای نیز به همین دلیل صرفاً مستندسازی نیست؛ طراحی، مدیریت، اندازهگیری و بهبود مستمر بخشی از چرخه آن است.
تفاوت سیستم سازی با مستندسازی چیست؟
این دو مفهوم به هم مرتبطاند، اما یکی نیستند.
مستندسازی میگوید:
«روش انجام کار چیست؟»
سیستم سازی سؤال بزرگتری میپرسد:
«چگونه کاری کنیم این روش در سازمان قابل اجرا، قابل کنترل، قابل اندازهگیری و قابل بهبود باشد؟»
ممکن است شرکتی صدها صفحه دستورالعمل داشته باشد اما همچنان سیستمسازی نشده باشد.
چرا؟
چون شاید:
- فرآیندها با هم ارتباط نداشته باشند.
- مسئولیتها مبهم باشند.
- سیستم اندازهگیری وجود نداشته باشد.
- افراد دستورالعملها را اجرا نکنند.
- ابزارها با فرآیند هماهنگ نباشند.
- استثناها تعریف نشده باشند.
- مالک فرآیند مشخص نباشد.
پس «مستند زیاد» الزاماً به معنی «سازمان سیستممند» نیست.
تفاوت سیستم سازی با خرید نرم افزار چیست؟
این یکی از مهمترین سوءبرداشتهاست.
فرض کنید واحد فروش شما اطلاعات مشتری را در Excel ثبت میکند، بخشی از پیگیریها در پیامرسان انجام میشود و بخشی از اطلاعات در ذهن فروشنده است.
اگر یک CRM خریداری کنید ولی فرآیند فروش، مراحل پیگیری، مسئولیتها، تعریف سرنخ، شرایط انتقال مشتری و شاخصهای فروش مشخص نباشد، فقط اطلاعات پراکنده را وارد یک نرمافزار جدید کردهاید.
نرمافزار زمانی ارزش واقعی ایجاد میکند که بخشی از یک طراحی سازمانی باشد.
در BPM نیز ابزار و فناوری تنها یکی از اجزای یک رویکرد گستردهتر برای مدیریت و بهبود فرآیندهاست؛ IBM در راهنمای طراحی BPM نیز BPM را یک رویکرد مدیریتی برای مدیریت و بهبود فرآیندها، نه صرفاً یک محصول یا فناوری، توضیح میدهد.
چه زمانی باید سیستم سازی را جدیتر کنیم؟
هیچ عدد جادویی برای اندازه شرکت وجود ندارد، اما بعضی نشانهها مهماند.
اگر چند مورد از شرایط زیر را دارید، ارزش دارد سیستمسازی را جدی بررسی کنید:
- مدیر در بیشتر تصمیمهای روزمره درگیر است.
- کارها با روشهای متفاوت توسط افراد مختلف انجام میشوند.
- با خروج یک نیروی کلیدی، بخشی از کار سازمان مختل میشود.
- خطاهای مشابه مرتب تکرار میشوند.
- اطلاعات در فایلها، پیامها و نرمافزارهای مختلف پراکنده است.
- واحدها برای گرفتن اطلاعات از یکدیگر زیاد رفتوبرگشت دارند.
- آموزش نیروی جدید زمان زیادی میگیرد.
- معلوم نیست مالک واقعی بعضی فرآیندها چه کسی است.
- مدیر نمیتواند دقیقاً بگوید گلوگاه سازمان کجاست.
- رشد فروش باعث افزایش متناسب بینظمی عملیاتی شده است.
داشتن یکی از این نشانهها الزاماً به معنی نیاز فوری به یک پروژه بزرگ سیستمسازی نیست؛ اما تکرار و شدت آنها میتواند نشانهای برای عارضهیابی عمیقتر باشد.
سیستم سازی سازمانی چه ارتباطی با BPM دارد؟
سیستم سازی کسب و کار و BPM یکی نیستند، اما بخش زیادی از یکدیگر را پوشش میدهند.
BPM یا Business Process Management یک رویکرد مدیریتی برای طراحی، مدیریت، اندازهگیری و بهبود فرآیندهای سازمان است. APQC نیز BPM را روشی برای طراحی، مدیریت و بهبود نحوه انجام کار در سازمان میداند و تأکید میکند که این موضوع باید به استراتژی و نتایج کسبوکار متصل باشد.
به زبان ساده:
- سیستم سازی نگاه وسیعتری به قابلتکرار و قابلمدیریت کردن کسبوکار دارد.
- BPM تمرکز بیشتری بر فرآیندها و چرخه بهبود آنها دارد.
- BPMS میتواند برای اجرای دیجیتال و مدیریت برخی فرآیندها استفاده شود.
- ERP معمولاً بخشهای گستردهای از عملیات سازمان را در یک سیستم یکپارچه مدیریت میکند.
این مرزبندیها در پروژههای واقعی ممکن است با توجه به معماری سازمان و محصول نرمافزاری متفاوت باشند؛ بنابراین نباید صرفاً بر اساس نام فناوری تصمیم گرفت.
آیا سیستم سازی باعث حذف نیروهای انسانی میشود؟
هدف سیستم سازی حذف انسان نیست.
در یک طراحی درست، نقش انسان باید دقیقتر شود.
کارهایی که میتوانند با قواعد مشخص، گردش کار یا فناوری انجام شوند، نباید دائماً زمان افراد متخصص را مصرف کنند.
در مقابل، انسان باید بیشتر روی مواردی مانند حل مسئله، مذاکره، تصمیمگیری، ارتباط با مشتری، تحلیل، خلاقیت و مدیریت استثناها تمرکز کند.
بنابراین سؤال مناسبتر این است:
«کدام کارها باید توسط انسان انجام شوند و کدام کارها را میتوان با فرآیند و فناوری قابلکنترلتر کرد؟»
یک اشتباه رایج: سیستم سازی قبل از عارضه یابی
یکی از اشتباهات رایج این است که سازمان ابتدا تصمیم میگیرد «سیستم بیاورد» و بعد دنبال مسئله میگردد.
مثلاً:
«CRM بخریم.»
«ERP پیاده کنیم.»
«BPMS نصب کنیم.»
«اتوماسیون راه بیندازیم.»
اما هنوز مشخص نیست مشکل اصلی چیست.
در یک پروژه حرفهای، ابتدا باید مشخص شود:
مسئله چیست؟
بعد:
ریشه مسئله کجاست؟
بعد:
فرآیند مطلوب چیست؟
و در نهایت:
چه فناوریای باید از این فرآیند پشتیبانی کند؟
این ترتیب ساده، جلوی بسیاری از تصمیمهای تکنولوژیک اشتباه را میگیرد.
سیستم سازی موفق چه خروجیهایی دارد؟
| حوزه | خروجی احتمالی |
|---|---|
| عارضهیابی | فهرست مشکلات، ریشهها و اولویتها |
| فرآیند | نقشه فرآیند و وضعیت موجود |
| معماری | طراحی وضعیت مطلوب و ارتباط فرآیندها |
| مسئولیت | نقشها، مسئولیتها و سطوح اختیار |
| مستندسازی | دستورالعملها و استانداردهای اجرایی |
| داده | تعریف اطلاعات، ورودیها و خروجیها |
| فناوری | نیازمندیهای ERP/BPMS/CRM/Automation |
| اجرا | فرآیندهای پیادهشده و آموزش افراد |
| کنترل | شاخصها، داشبوردها و نقاط کنترل |
| بهبود | برنامه اصلاح و توسعه مستمر |
به همین دلیل نمیتوان برای همه سازمانها یک «پکیج ثابت سیستم سازی» تعریف کرد.
سیستم خوب باید با مسئله و DNA همان سازمان تناسب داشته باشد.
از کجا بفهمیم سیستم سازی در سازمان ما درست طراحی شده است؟
یک سؤال ساده بپرسید:
«اگر فردا یکی از نیروهای کلیدی ما نباشد، آیا سازمان میداند کار او چگونه باید ادامه پیدا کند؟»
بعد سؤال را سختتر کنید:
«اگر حجم سفارشها ۲ برابر شود، آیا فرآیند ما همچنان قابل کنترل است؟»
و بعد:
«آیا مدیر میتواند با چند شاخص مشخص بفهمد کدام قسمت فرآیند مشکل دارد؟»
اگر پاسخ این سؤالها مبهم است، احتمالاً هنوز بخشی از سیستم سازمان به افراد، حافظه یا واکنشهای لحظهای وابسته است.
سیستم سازی موفق قرار نیست سازمان را خشک و غیرقابل انعطاف کند. هدف این است که کارهای تکرارشونده قابل کنترل شوند تا سازمان برای تغییر و رشد ظرفیت بیشتری داشته باشد.
سوالات متداول
سیستم سازی کسب و کار چیست؟
سیستم سازی کسب و کار یعنی طراحی فرآیندها، نقشها، مسئولیتها، قواعد، اطلاعات و ابزارهایی که باعث میشوند کارهای مهم سازمان به شکل قابل تکرار، قابل کنترل و قابل بهبود انجام شوند و وابستگی غیرضروری به افراد کاهش پیدا کند.
آیا سیستم سازی فقط برای شرکتهای بزرگ است؟
خیر. کسبوکارهای کوچک نیز میتوانند از سیستم سازی استفاده کنند، اما سطح پیچیدگی آن باید متناسب با اندازه، مدل کسبوکار و مسائل واقعی سازمان باشد. لازم نیست یک شرکت کوچک همان معماری یک سازمان چندصدنفره را اجرا کند.
آیا خرید ERP یا BPMS همان سیستم سازی است؟
خیر. ERP و BPMS ابزارهایی برای پشتیبانی از بخشی از عملیات و فرآیندهای سازمان هستند. سیستم سازی از شناخت مسئله، فرآیند، نقشها و وضعیت مطلوب شروع میشود و سپس مشخص میکند چه فناوریای مناسب است.
سیستم سازی چقدر زمان میبرد؟
زمان پروژه به تعداد فرآیندها، اندازه سازمان، پیچیدگی عملیات، تعداد واحدها، سطح مستندسازی و میزان تغییر موردنیاز بستگی دارد. بنابراین یک زمان ثابت برای همه سازمانها قابل اعلام نیست و باید بعد از شناخت وضع موجود برآورد شود.
آیا سیستم سازی باعث حذف کارکنان میشود؟
هدف سیستم سازی حذف کارکنان نیست. هدف اصلی، کاهش وابستگی به روشهای فردی، استاندارد کردن کارهای تکراری و فراهم کردن شرایطی است که کارکنان زمان بیشتری برای تصمیمگیری، حل مسئله و فعالیتهای ارزشآفرین داشته باشند.
اولین قدم برای سیستم سازی سازمان چیست؟
اولین قدم معمولاً شناخت مسئله و عارضهیابی است. قبل از انتخاب نرمافزار یا طراحی دستورالعمل باید مشخص شود سازمان در کدام فرآیندها مشکل دارد، گلوگاهها کجا هستند و وضعیت مطلوب چه ویژگیهایی باید داشته باشد.
آیا میتوان فقط یک بخش از سازمان را سیستم سازی کرد؟
بله. در بسیاری از پروژهها شروع از یک فرآیند یا واحد با اثرگذاری بالا منطقیتر از تلاش برای تغییر کل سازمان بهصورت همزمان است. انتخاب نقطه شروع باید بر اساس اهمیت، گلوگاه، آمادگی سازمان و ارزش مورد انتظار انجام شود.
جمعبندی
سیستم سازی کسب و کار در سادهترین تعریف یعنی اینکه سازمان برای انجام کارهای مهم خود، فقط به «آدمهای درست» وابسته نباشد؛ بلکه «روش درست انجام کار» نیز طراحی شده باشد.
اما این روش درست فقط یک دستورالعمل نیست. فرآیند، نقش، اختیار، داده، کنترل، شاخص، فناوری و فرهنگ اجرا باید در کنار هم قرار بگیرند.
اگر بخواهیم مسیر را خلاصه کنیم:
شناخت DNA کسبوکار → عارضهیابی → شناخت وضع موجود → شناسایی گلوگاه → طراحی وضعیت مطلوب → استانداردسازی → انتخاب فناوری → استقرار → اندازهگیری و بهبود
و شاید مهمترین نکته این باشد:
قبل از اینکه از خودمان بپرسیم «چه نرمافزاری بخریم؟»، باید بپرسیم «قرار است چه مسئلهای را در سازمان حل کنیم؟»
اگر حس میکنید بخشی از سازمان شما بیش از حد به چند نفر خاص، به تصمیم لحظهای مدیر یا به روشهای شفاهی وابسته است، بهتر است قبل از انتخاب هر نرمافزاری، همان گلوگاه مشخص شود.
برای شروع میتوانید ارزیابی اولیه سیستمسازی سازمان را انجام دهید تا مشخص شود کدام فرآیندها بیشترین نیاز به بازطراحی، استانداردسازی یا اتوماسیون دارند.
من، میلاد بهرامی، در کنار تیم اکسیر تجارت امین سالهاست همین مسیر را برای کسبوکارهای مختلف در شیراز و سراسر ایران طی میکنم. اگر فکر میکنید وقتش رسیده سازمان شما هم از حالت فردمحور به سیستممحور برسد، همین امروز شروع کنید.
آخرین بهروزرسانی: 7 مهر 1405 · بازبینی تخصصی: میلاد بهرامی
مدیرعامل اکسیر تجارت امین و دارای دکتری حرفهای مدیریت راهبردی کسبوکار (DBA)؛ متخصص معماری فرآیند، ERP، BPMS و اتوماسیون.
