Прокачай свою IT / Архитектура нового поколения

Привет VC! Меня зовут Иван Маслов, и я – роботизатор RPA. В IT отрасли мне довелось столкнуться с дикой кучей проблем. Если эти проблемы тебя не убивают, то точно делают сильнее. И знаете, что я хочу вам сказать? Что нерешаемых проблем, действительно, нет! Есть только плюсы и минусы каждого решения. В этой статье я расскажу о технологии, которая поможет решить любую IT проблему. Если у Вас мысли об IT связаны с «долго», «дорого» и «неофигенно», то запрыгивайте сюда - будет интересно.

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

Посмотрите на существующие классические методики проектирования IT ландшафта. Обнаружили, что они все требуют декомпозиции на IT операции? Их девиз: «Сначала выявить IT функции, а только потом объединить эти IT функций в бизнес-процессы». В этих методиках первостепенным является именно IT слой, а не бизнес-слой.

А что, если совсем отказаться от лишнего (чик-чик, упростить) и первостепенным принять именно бизнес-слой? У такого подхода даже аббревиатура имеется: BPA.

Business process automation - автоматизация бизнес-процессов.

Другими словами: Проектирование IT архитектуры в разрезе бизнес-функций, направленных на достижения конечной цели (бизнес-результат). Более того, данное проектирование должно происходить с минимально возможным количеством затрачиваемых ресурсов (мечта бизнес-заказчика).

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Вопрос: Почему это стало возможно только сейчас?

Ответ: Это связано с появлением технологии RPA!

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

RPA – Robotic Process Automation

Именно эта технология нам полностью развязывает руки. Если раньше мы были вынуждены тратить многочисленные ресурсы на 100500 интеграций между IT системами, то с помощью RPA мы можем решить проблему роботом, который вместо человека «залезет» в существующую IT систему. И для этого не потребуется делать никаких доработок в самой IT системе.

В итоге эта технология позволяет нам решить проблему, и «малой кровью», и с высоким уровнем качества (ведь технология RPA ничем не хуже любой другой технологии IT – это факт, спорить бессмысленно 😊 )

Данная технология позволяет:

Благодаря RPA удалось сблизить 2 совершенно противоположных мира: мир IT разработчиков и мир бизнес-заказчиков. Проектируя IT архитектуру от целевых функций, разработчики имеют самую главную возможность – это разговаривать с бизнес-заказчиком. В результате чего они начинают говорить на одном языке. Почему? Потому что вынуждены исходить из одной и той же цели.

Про OpenSource инструмент RPA (адаптирован под BPA) подробнее можно почитать здесь

Про RPA всё понятно. А теперь рассмотрим проблематику на примере.

Представим, что мы играем роль корпоративного архитектора. Руководство компании ставит конкретную цель по сокращению времени отработки заявок в 10 раз.

При анализе выясняется, что длительное время обработки связано с тем, что после формирования задания в 1-й IT системе, сотрудник должен выполнить ручную проверку в другой IT системе (валидация), после чего поставить соответствующую отметку об успешном окончании проверки.

Это одна из самых типовых историй, которая имеет место практически во всех компаниях в разных бизнес-процессах.

По классическим правилам проектирования IT ландшафта мы можем предложить реализацию интеграции между двумя IT системами (далее В1). Или предложить переход в концептуально новую архитектуру, например, микросервисную (далее В2).

Да, В2 займет существенно больше времени. Переписывать то, что уже работает, да еще и с нуля… За то реализация в целевом поле. А В1 выглядит быстрее. Но он тоже не идеален. А почему?

Дело все в том, что для реализации В1 потребуются команды разработки обеих IT систем. Этим командам нужно будет сопоставить приоритеты выполнения задачи, а еще обеспечить высокое качество коммуникации. В противном случае рискуем получить «то, не знаю что» по принципу «так, не знаю как».

Вернемся к BPA, и вспомним про главное правило.

Идея простая:

3 главных конструктивных вопроса:

Для удобства будем использовать термины:

Примечание: Такие наименования были выбраны в связи с тем, что классические методы предлагают решать задачу «по инструкции», а альтернативные методы предлагают «расширить границы дозволенного»

Рассмотрим подходы на примере автоматизации 3-х бизнес-процессов

Подход революционный

Итак, в случае классического подхода потребуется привлечь команды затрагиваемых IT систем, и поставить на них задачи как по доработке функциональности, так и по интеграции с другими IT системами.

Сформируем список задач в группировке по командам IT систем:

команда IT системы 1:

команда IT системы 2:

команда IT системы 3:

Итого: будет задействовано 3 команды, на которые будет поставлено 14 задач.

Все доработки будут выполняться в соответствии с требованиями отказоустойчивости, управления, информационной безопасности, разработки и информирования

Ниже представлена графическая интерпретация революционного подхода, взаимосвязь между потребностью, доработками и бизнес-эффектом.

Подход эволюционный

В рамках эволюционного подхода не потребуется привлекать команды IT систем. Для всех операций потребуется только одна команда: команда BPA. Это полностью отвечает той концепции, которая была описана в статье выше про альтернативный подход.

Сформируем список задач:

КОМАНДА BPA

Итого: будет задействована 1 команда, на которые будет поставлено 3 задачи.

Все доработки также будут выполняться в соответствии с требованиями отказоустойчивости, управления, информационной безопасности, разработки и информирования

Ниже представлена графическая интерпретация эволюционного подхода, взаимосвязь между потребностью, доработками и бизнес-эффектом.

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

Другими словами: альтернативный подход хорош не из-за того, что там программисты лучше (первоклассные программисты имеются в любой отрасли, ровно, как и некомпетентные программисты). Основное преимущество заключается в том, что проблема рассматривается под совершенно другим углом, который является еще и гораздо понятнее для бизнес-заказчика.

Мы рассмотрели BPA методы автоматизации бизнес-процессов в сравнении с классическими.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Вопрос: значит ли это, что эти методы будут всегда лучше классических?

Ответ: нет, не значит!

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Для каждой задачи важен контекст, в котором эта задача живет – BPA не панацея. У каждого метода всегда имеются свои плюсы и минусы!

Если в компании существует «зоопарк» систем, и бизнес-процессы там выполняются давно, то BPA (с высокой долей вероятности) окажется очень полезным и эффективным.

Если речь идет о стартапе, то, по-видимому, и применять эволюционные средства будет не на чем – там еще нет никаких IT систем.