معماری سازمانی و استقرار ERP چه تفاوتی دارند و چگونه یکدیگر را کامل می‌کنند؟
ناشر: شرکت توسعه آتراویژن فردا
معماری سازمانی تصویر هدف و نقشهٔ تغییر کل سازمان را می‌سازد؛ استقرار ERP یک برنامهٔ اجرایی برای تحقق بخشی از آن تصویر در حوزهٔ فرایند، داده و سامانه‌هاست.
یک اشتباه رایج در تعریف دامنه
گاهی انتخاب و استقرار ERP معادل معماری سازمانی در نظر گرفته می‌شود. ERP می‌تواند بخش بزرگی از فرایندها و داده‌های مشترک را پوشش دهد، اما معماری سازمانی دامنهٔ وسیع‌تری دارد: راهبرد، قابلیت‌های کسب‌وکار، سازمان، اطلاعات، مجموعه سامانه‌ها، فناوری و نقشهٔ گذار.
از سوی دیگر، معماری سازمانی اگر به برنامه‌های اجرایی متصل نشود، ممکن است در حد مدل و سند باقی بماند. استقرار ERP یکی از مهم‌ترین ابزارهای تحقق معماری هدف است، به‌ویژه در فرایندهایی که نیازمند داده و کنترل مشترک‌اند.
تفاوت در پرسش، خروجی و افق زمانی
معماری سازمانی می‌پرسد سازمان برای تحقق راهبرد به چه قابلیت‌ها، اطلاعات و سامانه‌هایی نیاز دارد و چگونه باید از وضع موجود به وضع هدف برسد. استقرار ERP می‌پرسد دامنهٔ منتخب چگونه تحلیل، پیکربندی، یکپارچه، آزمون و به بهره‌برداری منتقل شود.
خروجی معماری می‌تواند اصول، نقشهٔ قابلیت‌ها، معماری داده و برنامهٔ گذار باشد. خروجی استقرار شامل فرایند مصوب، تنظیمات، توسعه‌های لازم، دادهٔ منتقل‌شده، اتصال‌ها، آموزش و پذیرش عملیاتی است. افق معماری معمولاً چندبرنامه‌ای و بلندمدت‌تر است.
| موضوع | معماری سازمانی | استقرار ERP |
|---|---|---|
| دامنه | کل سازمان یا چند حوزهٔ معماری | دامنهٔ قراردادی فرایندها و شرکت‌ها |
| هدف | هم‌راستایی راهبرد و تغییر | راه‌اندازی راهکار قابل بهره‌برداری |
| خروجی | اصول، معماری هدف و نقشهٔ گذار | پیکربندی، داده، اتصال، آموزش و پذیرش |
| حاکمیت | معماری و سبد تغییرات | مدیریت پروژه، کیفیت، ریسک و تغییر |
| زمان | پیوسته و چندمرحله‌ای | چرخهٔ مشخص پروژه و بهبود پس از راه‌اندازی |
معماری کسب‌وکار؛ ورودی مهم برای ERP
نقشهٔ قابلیت‌ها و جریان‌های ارزش کمک می‌کند اولویت استقرار از ساختار واحدها فراتر رود. ممکن است چند واحد در یک جریان سفارش تا وصول نقش داشته باشند؛ نگاه معماری ارتباط آن‌ها را نشان می‌دهد و مانع بهینه‌سازی جزیره‌ای می‌شود.
در پروژه ERP این ورودی به دامنهٔ فرایند، مالکیت، شاخص و موج‌های استقرار تبدیل می‌شود. همهٔ قابلیت‌ها الزاماً داخل ERP قرار نمی‌گیرند؛ برخی در سامانه تخصصی باقی می‌مانند و از طریق اتصال کنترل‌شده با ERP همکاری می‌کنند.
معماری داده و مرز سامانه‌ها
معماری داده تعیین می‌کند کدام سامانه مرجع مشتری، تأمین‌کننده، کالا، دارایی یا ساختار سازمانی است و اطلاعات چگونه به اشتراک گذاشته می‌شوند. پروژه ERP این تصمیم‌ها را در ساختار داده، مهاجرت، کنترل کیفیت و رابط‌ها عملیاتی می‌کند.
اگر مرز سامانه‌ها روشن نباشد، داده در چند محل نگهداری و مسئولیت اصلاح مبهم می‌شود. هدف یکپارچگی حذف همهٔ سامانه‌های تخصصی نیست؛ هدف آن است که هر سامانه نقش مشخص داشته باشد و نسخهٔ معتبر داده قابل تشخیص باشد.
معماری فناوری و الزامات غیرعملکردی
ظرفیت، دسترس‌پذیری، امنیت، بازیابی، محیط‌ها و استانداردهای اتصال بخشی از معماری فناوری‌اند. پروژه ERP باید این اصول را به طراحی محیط عملیاتی، کنترل دسترسی، پشتیبان‌گیری، پایش و آزمون کارایی تبدیل کند.
تصمیم‌های فنی پروژه نباید فقط بر تحویل کوتاه‌مدت متمرکز باشند. اثر آن‌ها بر نگهداری، ارتقا، توسعه شرکت‌های جدید و اتصال آینده باید سنجیده شود. معماری سازمانی معیار مشترکی برای ارزیابی این تصمیم‌ها فراهم می‌کند.
مدل همکاری پیشنهادی
پیش از شروع، اصول و محدودیت‌های معماری مرتبط با دامنه استخراج می‌شوند. در تحلیل، شکاف میان قابلیت هدف و راهکار بررسی می‌شود. در طراحی، تصمیم‌های داده و اتصال ثبت می‌شوند و در طول اجرا، تغییرهای مهم از نظر انطباق با معماری و ارزش کسب‌وکار ارزیابی می‌شوند.
پس از راه‌اندازی، واقعیت اجرایی معماری را غنی می‌کند. نقشهٔ سامانه‌ها، جریان داده و برنامهٔ گذار باید با وضعیت جدید به‌روزرسانی شوند. رابطهٔ درست یک‌طرفه نیست: معماری به ERP جهت می‌دهد و تجربهٔ ERP نیز معماری سازمان را واقعی‌تر می‌کند.
منابع و مبنای مقاله
مرجع معماری: استاندارد TOGAF از The Open Group. مرجع استقرار: چارچوب تحلیل، طراحی، پیکربندی، انتقال و تثبیت آتراویژن.
مقاله برای روشن‌کردن مرز دو رویکرد نوشته شده است و ادعای انطباق رسمی پروژه یا محصول با TOGAF ندارد.