Вічне питання про те, купувати чи створювати програмне забезпечення (Джеймс Монахен)

Вітаю. У вас є проблема, проект, бюджет і термін виконання. Замість того, щоб кидатися на це тілом, програмне забезпечення є рішенням, але тепер вам потрібно вирішити, створювати чи купувати, ось у чому питання. Або це? Я вже не впевнений, що це однозначне рішення.
Build використовувати для позначення найму домашніх програмістів для кодування будь-якої необхідної системи та купити згадані готові продукти, які можна придбати та запустити. Це мало сенс, коли ми говорили про системи бухгалтерського обліку, торгові системи, CRM, звітність,
Позика, збір, CLM тощо. Зараз ми живемо в середовищі з низьким кодом, де для створення чогось не потрібен досвід програмування. Його можна перетягувати. Поєднайте це з купівлею готових рішень, які в кінцевому підсумку настільки налаштовані, що ви можете
добре побудували це. Отже, що залишає нас приймати рішення будувати чи купувати? Давайте подивимося, що нам насправді потрібно.

Жодна сучасна система більше не може покладатися на одну точку входу. Очікування клієнтів диктують необхідність різноманітних каналів. Особисто, через прямий телефон або кол-центр, електронну пошту, соціальні мережі, SMS, Інтернет, мобільний телефон, планшет – як мобільний, так і рідний
програми, які повинні бути взаємозамінними без втрати вмісту чи контексту. Клієнт, який починає роботу у відділенні/магазині або особисто, але має піти на зустріч, хоче мати можливість продовжити з того місця, де зупинився, коли пізніше того ж дня ввійде онлайн. Або
якщо вони починають онлайн, але розчаровуються і звертаються по допомогу, вони не хочуть починати процес з самого початку. Це також стосується внутрішніх зацікавлених сторін. Інформаційний ланцюг всередині організації має бути таким же гнучким, як і клієнт
Варіанти. 

Отже, що далі для нашого початку введення даних будь-де? Ну, є причина, чому нам потрібні ці дані в першу чергу. Незалежно від того, чи хоче новий клієнт працювати з організацією, існуючий клієнт хоче отримати новий продукт чи послугу, або навіть просто щоденні запити, скарги
або інформаційні запити. Усе це має розпочати визначені, але гнучкі процеси, щоб виконати запит якомога ефективніше та легше. Процес, як правило, визначений, і зазвичай персонал навчається виконувати послідовність завдань, щоб виконати їх із заздалегідь визначеним
дії на основі певних вхідних даних. 

Ні кінцеві клієнти, ні користувачі системи не повинні повторно вводити інформацію, якщо вона вже була десь отримана. Фактично, якщо інформація доступна будь-де всередині організації або зі сторонніх джерел, таких як постачальники даних, кредитні бюро,
постачальники скринінгу тощо. він повинен бути доступним протягом усього процесу для всіх користувачів, яким це потрібно. Процес визначено, але точки дотику мають бути взаємозамінними, а зібрані дані мають бути інтегровані, де це можливо, і структуровані, де це можливо.
Випадаючі меню, пошукові значення, поля дат і контрольовані довільні текстові значення, щоб забезпечити якомога більше якісних даних. Це дозволяє значно більше автоматизувати весь процес і менше обробки винятків.

Тепер, коли дані активно збираються або оновлюються, можна застосувати штучний інтелект. Співробітникам не потрібно знати всі деталі, і навіть нові члени можуть працювати над складнішими справами, оскільки система використовує закодовані правила
логіка для автоматичного прийняття рішень, для вирішення яких персонал раніше мав мати тривалу підготовку та досвід. Більше жодних помилок, а також можливий нагляд і навіть перевірка контролю якості або пряма черга винятків для ручного втручання, якщо це необхідно.

Це все вимагає системного підходу. Стара ідея папки, яка знаходиться в ящику співробітників для портфоліо клієнтів, застаріла і створює непотрібний ризик. Клієнти, які обробляються ізольовано, можуть бути як обмеженими, так і надлишковими
в той самий час. Якщо у корпоративного клієнта є директори, які працюють над кількома іншими клієнтами, чому кожен окремий огляд ігнорує ширшу картину. Чи збираєтеся ви переглядати одного й того самого режисера кілька разів у кожному стосунку чи могли б ви?
зробити це один раз і повторно використовувати цю інформацію в усій організації?

Їм навіть не обов’язково мати спільних пов’язаних сторін, щоб вигода була очевидною. Подібні галузі, схожі клієнти, що робити, якщо постачальники/постачальники ваших клієнтів також є клієнтами? Це підводить нас до того, як вам потрібно обробляти інформацію
і чому сьогодні організаціям потрібно дивитися на все підприємство, розглядаючи програмне забезпечення. Якщо ви розглядаєте проблему ізольовано та розглядаєте її як таку, встановлюючи бюджети та надсилаючи запити пропозицій для кожного компонента CRM, Fincrime, роботи з клієнтами, ви закінчите
витративши більше ресурсів на спроби інтегрувати все разом, ніж будь-яка потенційна економія, на яку спочатку сподівалися. Тепер застосуйте це для кожного регіону чи сфери діяльності, які можуть мати окремі бюджети та нагляд, і ви отримаєте 8 версій
того самого програмного забезпечення, яке потребує інтеграції із самим собою через інтенсивне налаштування для кожної області, усуваючи будь-яку економію масштабу, яку вони могли б досягти.

Папка в шухляді, яку потрібно переглядати щороку або іншим чином, а персонал має бути навчений, що і коли це робити. Весь огляд (або новий адаптаційний/додатковий продукт/послуги тощо) можна розбити на складові частини, які можуть або
не можуть оброблятися іншими людьми/командами. Після цього система може визначити, коли завдання завершено або коли зібрано достатньо даних для надсилання наступній особі для введення. Усі вони структуровані як випадки та підвипадки всередині. Таким чином кожен елемент
справа може мати власний кінцевий термін, шлях ескалації, правонаступника та тих, хто затверджує. Замість одного великого завдання, яке співробітник повинен мати достатньо досвіду, щоб знати, як виконати та до кого звернутися для різних елементів, система тепер призначає роботу
і забезпечує його своєчасне завершення в усій компанії з максимальною автоматизацією завдань, щоб звільнити осіб, які приймають рішення, зосередитися на важливому.

Це все добре і добре з точки зору бізнесу. Робота відома і що треба робити. Але коли ми намагаємося вирішити, купувати чи створювати програмне забезпечення самостійно, як це впливає на речі? Припустімо, що є кілька джерел
даних у кількох системах. Очікується, що будь-яка сучасна система керуватиметься API та матиме низькі можливості коду/без коду. Розумне припущення для швидшого та гнучкого програмного забезпечення. У наш час усе потрібно розглядати як мікросервіс, якого слід уникати
старі моноліти програмного забезпечення. Програмне забезпечення слід встановлювати та використовувати, оскільки воно є найкращим із доступних і готовим до майбутнього, щоб за потреби адаптуватися до змін. Занадто багато пропозицій закріпилися й обслуговуються лише тому, що вони надто складні та забирають багато часу
замінити. Здебільшого це пов’язано з тим, що правила жорстко закодовані, ймовірно, пов’язані з самими даними, дані не лише інтегруються, а й повторюються кілька разів для кожної окремої частини програмного забезпечення в інформаційному ланцюжку, і якщо ви спробуєте замінити одну частину,
вся система може зламатися. Забагато старого процесу мислення, якщо він не зламаний, не виправляйте його. Що справді потрібно, так це щоб усі ці компоненти були мікросервісами, які отримували необхідні дані, застосовували автоматизовані правила або вводи/перегляди користувачів і
передаючи його до наступного мікросервісу. Дані не слід зберігати більш ніж в одному місці. Він може бути об’єднаним, але не реплікованим за межами резервних копій. Ваші системи CRM, Onboarding, KYC, Client Outreach тощо повинні мати доступ лише до необхідних даних, а не
самі бути сховищами даних, якщо ви не вибрали одне з них. Копіювання одних і тих самих даних у кількох місцях і правил, які це регулюють, є марною вправою, оскільки кожна додаткова додана система посилить складність.

Це підводить нас до остаточного розгляду. Незалежно від того, чи є у вас єдине джерело істини/золота копія чи кілька надлишкових і конкуруючих записів і систем, які можуть їх оновлювати, ви все одно опинитеся в іншому рівні вимог на основі лінії
бізнес, юрисдикція, типи клієнтів і продукти/послуги. До особи ставляться інакше, ніж до компанії чи трасту, і залежать від споживчої/роздрібної торгівлі, комерційної чи корпоративної діяльності щодо вимог і придатності. У найелементарніших прикладах if
у нас є 10 типів клієнтів (фізичні особи – неодружені, одружені тощо, приватні компанії, публічні компанії, трасти, благодійні організації тощо), і ви можете працювати в 10 регіонах і можете пропонувати 10 типів продуктів/послуг, ми вже на потенційно 1000+ правил, які можуть
застосовуватися. Хіба не було б набагато простіше визначити правила для регіону, для сфери діяльності, для типу клієнта та продуктів або послуг і дозволити системі вирішувати вимоги замість цього? Видалення дублікатів і повторне використання точок даних, які були раніше
надається. Це перевага абстрагування процесу та правил від рівня даних. 

Тож тепер, коли ми розглядаємо старе питання купівлі чи створення програмного забезпечення, ми знаємо, що нам потрібна багатоканальна оркестровка, автоматизація процесів, де це можливо, гнучка логіка правил, керування справами для нагляду та аудиту, низький рівень коду та API, абстрактна
рівень даних і механізм інтелектуальних правил, який може успадковувати різні рівні логіки. Ринок технологій сповнений інноваторів, які із задоволенням вирішують будь-яку нішеву проблему, про яку можна подумати, але в який момент перестає мати сенс мати «з полиці»
продукти, які потрібно налаштувати та інтегрувати один з одним замість того, щоб створювати їх самостійно. Платформи з низьким кодом можуть дозволити вам мати доступні 80% ваших вимог, і вам потрібно лише налаштувати цю дельту 20%. Найкраще з обох світів є низьким
платформа коду, для якої інші також створили багаторазові компоненти, щоб ви могли отримати готові продукти як прискорювачі для вашого бізнесу, а також мати можливість для вашого персоналу або сертифікованих третіх сторін створювати решту вимог відповідно до вимог
вашій організації. Купувати чи будувати? Насправді має бути і те, і інше.