سوال ابدی در مورد اینکه آیا نرم افزار خود را بخرید یا بسازید (جیمز موناگان)

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

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

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

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

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

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

آنها حتی مجبور نیستند برای آشکار شدن سود، اشخاص مرتبط مشترک داشته باشند. صنایع مشابه، مشتریان مشتری مشابه، چه می‌شود اگر فروشندگان/تامین‌کنندگان مشتری شما نیز خودشان مشتری باشند؟ این ما را به نحوه پردازش اطلاعات می رساند
و چرا این روزها سازمان‌ها هنگام بررسی نرم‌افزار باید به کل سازمان نگاه کنند. اگر مشکلی را به صورت مجزا مشاهده کنید و با آن برخورد کنید، بودجه تعیین کنید و RFP برای هر مؤلفه CRM، Fincrime، Client Outreach صادر کنید، در نهایت به نتیجه خواهید رسید.
با صرف منابع بیشتر در تلاش برای ادغام همه چیز با هم نسبت به هر پس انداز احتمالی که در ابتدا انتظار می رفت. اکنون آن را برای هر منطقه یا خط کسب و کاری که ممکن است بودجه و نظارت جداگانه داشته باشد اعمال کنید و در نهایت با 8 نسخه مواجه خواهید شد.
از همان نرم‌افزاری که به دلیل سفارشی‌سازی سنگین در هر منطقه، نیاز به ادغام با خود دارد و هر گونه صرفه‌جویی در مقیاس را که می‌توانستند به دست آورند، از بین می‌برد.

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

این همه از نقطه نظر تجاری خوب و خوب است. کار مشخص است و آنچه باید انجام شود. اما زمانی که می‌خواهیم تصمیم بگیریم که آیا باید نرم‌افزار را خودمان بخریم یا بسازیم، این موضوع چگونه به همه چیز کمک می‌کند؟ خب بیایید فرض کنیم چندین منبع وجود دارد
داده ها در چندین سیستم انتظار می رود هر سیستم مدرنی مبتنی بر API باشد و قابلیت کد/بدون کد پایینی داشته باشد. یک فرض معقول برای نرم افزار سریعتر و انعطاف پذیر. همه چیز این روزها باید به عنوان یک ریز سرویس در نظر گرفته شود تا از آن اجتناب شود
یکپارچه نرم افزار سبک قدیمی. نرم افزار باید نصب و استفاده شود، زیرا بهترین نرم افزار موجود و اثبات شده در آینده برای تطبیق با تغییرات در صورت نیاز است. بسیاری از پیشنهادها ریشه دوانده و تنها به این دلیل نگهداری می شوند که بسیار دشوار و وقت گیر هستند
جایگزین کردن بیشتر این به این دلیل است که قوانین سخت کدگذاری شده اند، احتمالاً با خود داده ها در هم تنیده شده اند، داده ها نه تنها یکپارچه می شوند، بلکه چندین بار برای هر نرم افزار جداگانه در زنجیره اطلاعات تکرار می شوند و اگر سعی کنید یک قطعه را جایگزین کنید،
کل سیستم ممکن است خراب شود بیش از حد از فرآیند فکر قدیمی، اگر شکسته نشد، آن را اصلاح نکنید. چیزی که واقعاً مورد نیاز است این است که همه آن قطعات جزء ریزسرویس باشند، داده‌های مورد نیاز را جمع‌آوری کنند، قوانین خودکار یا ورودی‌ها/بازبینی‌های کاربر را اعمال کنند و
انتقال آن به میکروسرویس بعدی. داده ها نباید در بیش از یک مکان ذخیره شوند. ممکن است فدرال شود اما خارج از پشتیبان‌گیری تکرار نشود. سیستم‌های CRM، Onboarding، KYC، Client Outreach و غیره شما فقط باید به داده‌هایی که نیاز دارند دسترسی داشته باشند و نه
خود مخازن داده باشند مگر اینکه شما یکی را انتخاب کرده باشید. تکرار همان داده ها در چندین مکان و قوانین حاکم بر آن یک تمرین بیهوده است زیرا هر سیستم اضافی اضافه شده پیچیدگی های موجود را چند برابر می کند.

این ما را به بررسی نهایی می رساند. چه یک منبع از حقیقت/نسخه طلایی داشته باشید یا چندین رکورد و سیستم اضافی و رقیب که می تواند آنها را به روز کند، همچنان خود را در لایه دیگری از الزامات بر اساس خط
تجارت، حوزه قضایی، انواع مشتری و محصولات/خدمات. با یک فرد رفتار متفاوتی نسبت به یک شرکت یا اعتماد می شود و از نظر نیازها و تناسب، با مصرف کننده/خرده فروشی، تجارت یا خطوط تجاری شرکت متفاوت است. در ابتدایی ترین مثال ها اگر
ما 10 نوع مشتری داریم (فردی – مجرد، متاهل، و غیره، شرکت خصوصی، شرکت دولتی، اعتماد، خیریه و غیره) و شما ممکن است در 10 منطقه فعالیت داشته باشید، و ممکن است 10 نوع محصول/خدمات ارائه دهید، ما در حال حاضر در به طور بالقوه بیش از 1000 قانون که می تواند
اعمال می شود. آیا تعیین قوانین برای یک منطقه، برای یک خط کسب و کار، برای نوع مشتری و محصولات یا خدمات بسیار آسان تر نخواهد بود و به جای آن به سیستم اجازه داده شود که الزامات را حل کند؟ حذف موارد تکراری و استفاده مجدد از نقاط داده قبلی
ارائه شده است. این مزیت انتزاعی فرآیند و قوانین شما از لایه داده شماست. 

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