Вечный вопрос: покупать или создавать свое программное обеспечение (Джеймс Монаган)

Поздравляем. У вас есть проблема, проект, бюджет и дедлайн. Вместо того, чтобы бросаться телами, программное обеспечение является решением, но теперь вам нужно решить, строить или покупать, вот в чем вопрос. Или это? Я уже не уверен, что это однозначное решение.
Слово «сборка» относится к найму штатных программистов для кодирования любой необходимой системы, а «покупка» относится к готовым продуктам, которые можно было купить и запустить. Это имело смысл, когда мы говорили об учетных системах, торговых системах, CRM, отчетности,
Кредитование, коллекции, CLM и т. д. Сейчас мы живем в среде с низким уровнем кода, где для создания чего-либо не требуется опыта программирования. Это можно перетащить. Соедините это с покупкой готовых решений, которые в конечном итоге будут настолько настроены, что вы можете
ну построили. Итак, что же нам остается делать, чтобы принять решение о строительстве или покупке? Давайте посмотрим, что нам на самом деле нужно.

Ни одна современная система больше не может полагаться на единую точку входа. Ожидания клиентов диктуют необходимость различных каналов. Лично, по телефону напрямую или в колл-центре, по электронной почте, в социальных сетях, SMS, в Интернете, на мобильном телефоне, на планшете — как с мобильным, так и с родным интерфейсом
приложения, и все они должны быть взаимозаменяемыми без потери содержимого или контекста. Клиент, который начинает работу в отделении/магазине или лично, но должен уйти на встречу, хочет иметь возможность продолжить с того места, где он остановился, когда он войдет позже в тот же день онлайн. Или
если они начинают онлайн, но разочаровываются и обращаются за помощью, они не хотят начинать процесс с самого начала. Это относится и к внутренним заинтересованным сторонам. Информационная цепочка внутри организации должна быть такой же гибкой, как и клиент, с которым он сталкивается.
настройки. 

Итак, что дальше для нашего начала ввода данных? Ну, в первую очередь, есть причина, по которой нам нужны эти данные. Хочет ли новый клиент работать с организацией, существующий клиент хочет новый продукт или услугу, или даже просто повседневные вопросы, жалобы
или информационные запросы. Все это должно начинаться с определенных, но гибких процессов, чтобы выполнить запрос максимально эффективно и легко. Процесс обычно определен, и обычно персонал обучен выполнять последовательность задач, чтобы выполнить его с заранее определенными
действия на основе определенных входных данных. 

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

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

Все это требует системного подхода. Старая идея о том, что манильская папка хранится в ящике стола сотрудников для портфолио их клиентов, устарела и создает ненужный риск. Клиенты, обрабатываемые изолированно, могут быть как ограничивающими, так и избыточными.
в то же время. Если у корпоративного клиента есть директора, которые работают с несколькими другими клиентами, почему каждый отдельный обзор игнорирует общую картину. Собираетесь ли вы также проверять одного и того же директора несколько раз в каждых отношениях, или вы могли бы
сделать это один раз и повторно использовать эту информацию в организации?

Им даже не нужно иметь общих связанных сторон, чтобы выгода была очевидна. Похожие отрасли, похожие клиенты-клиенты, что, если ваши клиенты-продавцы/поставщики сами являются клиентами? Это подводит нас к тому, как вам нужно обрабатывать информацию
и почему в наши дни организациям необходимо рассматривать все предприятие при выборе программного обеспечения. Если вы рассматриваете проблему изолированно и относитесь к ней как к таковой, устанавливая бюджеты и выпуская RFP для каждого компонента CRM, Fincrime, Client Outreach, вы в конечном итоге
с затратой большего количества ресурсов, пытаясь интегрировать все вместе, чем любая потенциальная экономия, на которую изначально надеялись. Теперь примените это для каждого региона или направления бизнеса, которые могут получить отдельные бюджеты и надзор, и вы получите 8 версий.
одного и того же программного обеспечения, которое необходимо интегрировать само с собой из-за жесткой настройки для каждой области, исключающей любую экономию за счет масштаба, которую они могли бы достичь.

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

Это все хорошо и хорошо с точки зрения бизнеса. Работа известна и что нужно сделать. Но когда мы пытаемся решить, должны ли мы покупать или создавать программное обеспечение самостоятельно, как это влияет на вещи? Ну давайте предположим, что есть несколько источников
данных в нескольких системах. Ожидается, что любая современная система будет управляться API и иметь возможности с малым количеством кода или без кода. Разумное предположение для более быстрого и гибкого программного обеспечения. Все в наши дни нужно рассматривать как своего рода микросервис, чтобы избежать
программные монолиты старого стиля. Программное обеспечение следует устанавливать и использовать, потому что оно лучше всего доступно и рассчитано на будущее, чтобы при необходимости адаптироваться к изменениям. Слишком много предложений укоренились и поддерживаются только потому, что они слишком сложны и требуют много времени.
заменить. В основном это связано с тем, что правила жестко закодированы, вероятно, переплетены с самими данными, данные не только интегрируются, но и реплицируются несколько раз для каждой отдельной части программного обеспечения в информационной цепочке, и если вы попытаетесь заменить одну часть,
вся система может сломаться. Слишком много старого мыслительного процесса, если он не сломан, то не исправлять его. Что действительно необходимо, так это то, чтобы все эти компоненты были микросервисами, получающими необходимые данные, применяющими автоматизированные правила или пользовательский ввод/обзор и
передавая его следующему микросервису. Данные не должны храниться более чем в одном месте. Он может быть объединен, но не реплицирован вне резервных копий. Ваши системы CRM, Onboarding, KYC, Client Outreach и т. д. должны получать доступ только к тем данным, которые им нужны, а не
сами быть репозиториями данных, если вы не выбрали один из них. Репликация одних и тех же данных в нескольких местах и ​​правил, которые управляют этим, является бесполезным занятием, поскольку каждая дополнительная система увеличивает сложность.

Это подводит нас к заключительному рассмотрению. Независимо от того, есть ли у вас единственный источник достоверной информации/Золотая копия или несколько избыточных и конкурирующих записей и систем, которые могут их обновлять, вы все равно окажетесь на другом уровне требований, основанных на линейке требований.
бизнес, юрисдикция, типы клиентов и продукты/услуги. К человеку относятся иначе, чем к компании или доверительному фонду, и он отличается в зависимости от потребительского/розничного, коммерческого или корпоративного направления деятельности по требованиям и пригодности. В самом простом из примеров, если
у нас есть 10 типов клиентов (физические лица - одинокие, женатые и т. д., частная компания, публичная компания, траст, благотворительность и т. д.), и вы можете работать в 10 регионах, и вы можете предлагать 10 видов продуктов / услуг, мы уже на потенциально более 1000 правил, которые могут
применяться. Не было бы намного проще определить правила для региона, направления деятельности, типа клиента, продуктов или услуг и вместо этого позволить системе решать требования? Удаление дубликатов и повторное использование точек данных, которые были ранее
предоставил. Это преимущество абстрагирования вашего процесса и правил от вашего уровня данных. 

Итак, теперь, когда мы рассматриваем старый вопрос о покупке или создании программного обеспечения, мы знаем, что нам нужна многоканальная оркестровка, автоматизация процессов, где это возможно, гибкая логика правил, управление делами для надзора и аудита, низкий уровень кода и управление API, абстрактный
уровень данных и интеллектуальный механизм правил, который может наследовать от различных логических уровней. Рынок технологий полон новаторов, которые с радостью удовлетворяют любую нишевую проблему, о которой только можно подумать, но в какой момент перестает иметь смысл иметь «готовые» продукты?
продукты, которые все должны быть настроены и интегрированы друг с другом, а не создаваться самостоятельно. Платформы с низким кодом могут позволить вам иметь 80% ваших требований, и вам нужно настроить только эти 20%. Лучшее из обоих миров - низкий
кодовую платформу, для которой другие также создали повторно используемые компоненты, поэтому вы можете получить «готовые» продукты в качестве ускорителей для своего бизнеса, а также иметь возможность для вашего персонала или сертифицированных сторонних организаций создавать остальные конкретные требования.
в вашу организацию. Покупать или строить? Это действительно должно быть и то, и другое.