خانه / نقش و اهمیت معماری سازمانی: هزینه نبود نقشه قابلیت‌ها و شروع ۳۰ روزه

نقش و اهمیت معماری سازمانی: هزینه نبود نقشه قابلیت‌ها و شروع ۳۰ روزه

در بیشتر سازمان‌ها یک سؤال ساده بپرسید: «سفارش مشتری را با کدام سیستم‌ها مدیریت می‌کنیم و مالک این فرایند کیست؟» بعد ببینید چه می‌شود. سه نفر سه جواب متفاوت می‌دهند، یک نفر فایل اکسل قدیمی را باز می‌کند و جلسه با «از واحد فناوری اطلاعات بپرسیم» تمام می‌شود. همین مکث، روشن‌ترین نشانه این است که سازمان به معماری سازمانی نیاز دارد.

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

معماری سازمانی (Enterprise Architecture) همان رشته‌ای است که جلوی این پراکندگی را می‌گیرد. گارتنر آن را روشی برای هدایت واکنش سازمان به تغییرات تعریف می‌کند؛ روشی که مسیر اجرای تغییر را به سمت چشم‌انداز و نتایج مطلوب کسب‌وکار تحلیل می‌کند. استاندارد TOGAF از The Open Group، که پرکاربردترین چارچوب معماری سازمانی است، روش‌ها و زبان مشترک این کار را فراهم می‌کند. این مقاله را عملی نگه می‌دارم: معماری سازمانی واقعاً چه کاری برای سازمان انجام می‌دهد، نبودنش به زبان عدد چقدر هزینه دارد و چطور می‌شود بدون یک برنامه بزرگ، در ۳۰ روز شروع کرد.

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

معماری سازمانی در عمل چه می‌کند؟

کلاسورهای قطور را یک لحظه کنار بگذارید. در کار روزمره، معماری سازمانی خوب به چهار سؤالی جواب می‌دهد که مدیران مدام می‌پرسند:

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

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

مثال عددی: هزینه سیستم‌های هم‌پوشان

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

قلم هزینه فرض (نمونه) سالانه
لایسنس و پشتیبانی تکراری ۶ قابلیت که ۲ تا ۳ ابزار هم‌پوشان دارند × ۲۵٬۰۰۰ هزینه اضافه برای هرکدام ۱۵۰٬۰۰۰
تطبیق دستی داده بین سیستم‌ها ۱۲ نفر × ۴ ساعت در هفته × ۴۶ هفته ≈ ۲٬۲۰۸ ساعت × ۱۵ در ساعت ≈ ۳۳٬۱۰۰
نگهداری اتصال‌های نقطه‌به‌نقطه ۴۰ اتصال × ۱٬۵۰۰ برای هرکدام ۶۰٬۰۰۰
جمع هزینه هم‌پوشانی ≈ ۲۴۳٬۱۰۰

حالا فرض کنید نقشه قابلیت‌ها نشان دهد که با یکپارچه‌کردن ابزارهای هم‌پوشان، نیمی از این هزینه حذف می‌شود و هزینه یک‌باره مهاجرت ۱۵۰٬۰۰۰ است. صرفه‌جویی سالانه حدود ۱۲۱٬۶۰۰ است، پس دوره بازگشت سرمایه ۱۵۰٬۰۰۰ ÷ ۱۲۱٬۶۰۰ ≈ ۱٫۲ سال می‌شود. بعد از آن، این صرفه‌جویی هر سال تکرار می‌شود.

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

قالب یک‌صفحه‌ای نقشه قابلیت‌ها

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

قابلیت (سطح ۱) مالک سیستم‌های اصلی سلامت اهمیت راهبردی
راهبرد و برنامه‌ریزی چه کسی تصمیم می‌گیرد کدام ابزارها سبز / زرد / قرمز زیاد / متوسط / کم
توسعه محصول
فروش و مدیریت مشتری
خرید و تأمین‌کنندگان
برنامه‌ریزی و اجرای تولید
مدیریت کیفیت
لجستیک و انبارداری
نگهداری و تعمیرات
مالی و بهای تمام‌شده
منابع انسانی
داده و فناوری اطلاعات

نکته اصلی در دو ستون آخر است. وقتی قابلیتی از نظر سلامت قرمز و از نظر اهمیت زیاد است، سرمایه‌گذاری بعدی باید همان‌جا باشد. وقتی جلوی یک قابلیت در ستون «سیستم‌های اصلی» سه سیستم نوشته شده، همان‌جا نامزد یکپارچه‌سازی است.

۳۰ روز اول معماری سازمانی، قدم‌به‌قدم

  • هفته ۱ – یک حامی، یک سؤال. یک حامی ارشد پیدا کنید و روی یک سؤال کسب‌وکار که معماری سازمانی باید اول به آن جواب دهد توافق کنید؛ مثلاً «کجا داریم دو بار هزینه می‌دهیم؟» یا «پروژه جدید ERP واقعاً به چه چیزهایی دست می‌زند؟»
  • هفته ۲ – فهرست نرم‌افزارها. همه نرم‌افزارهای کسب‌وکار را فهرست کنید: نام، مالک، کاربران، هزینه سالانه و داده اصلی‌ای که نگه می‌دارد. معمولاً ۸۰٪ این اطلاعات از قبل نزد واحد مالی و فناوری اطلاعات هست.
  • هفته ۳ – نقشه قابلیت‌ها را بکشید و سیستم‌ها را به آن وصل کنید. از قالب بالا استفاده کنید و هر نرم‌افزار را زیر قابلیت‌هایی که پشتیبانی می‌کند بگذارید. هم‌پوشانی‌ها و خلأها خودشان پیدا می‌شوند.
  • هفته ۴ – نقشه حرارتی و سه تصمیم. هر قابلیت را بر اساس سلامت و اهمیت رنگ کنید، یک صفحه به مدیریت ارائه دهید و با سه تصمیم مشخص از جلسه بیرون بیایید: یک مورد برای یکپارچه‌سازی، یک خلأ برای رفع و یک پروژه برای بازتعریف دامنه.
یک هشدار. رایج‌ترین شکل شکست معماری سازمانی این است که به یک پروژه مستندسازی تبدیل شود. اگر بعد از ۳۰ روز هیچ تصمیمی تغییر نکرده، یا نقشه بیش از حد جزئی است یا به سؤال اشتباهی گره خورده. اول در سطح ۱ و ۲ بمانید و بگذارید تصمیم‌ها جزئیات را بیرون بکشند، نه برعکس.

دستاورد

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

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

چک‌لیست این ماه

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

نقشه قابلیت‌های سازمان خودتان را می‌خواهید؟

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

تماس با من بخوانید: هوش مصنوعی در معماری سازمانی


منابع

  • The Open Group. The TOGAF Standard؛ چارچوب باز معماری سازمانی، شامل قابلیت‌های کسب‌وکار و برنامه‌ریزی مبتنی بر قابلیت.
  • Gartner. Enterprise Architecture (EA)؛ تعریف: رشته‌ای برای هدایت فعالانه و جامع واکنش سازمان به نیروهای برهم‌زننده، به سمت چشم‌انداز و نتایج مطلوب کسب‌وکار.

👁 Views: 1