(Импорто)Замещение бизнес-решений. Analyze This.

Какое-то время прошло. Теперь можно оценить пресловутую проблему импортозамещения бизнес-приложений, в ретроспективе, так сказать. Давайте посмотрим какие ситуации возникли и что с ними делать. Мы не будем здесь обсуждать идеологические вопросы, вроде того, у кого покупать патриотично, а у кого - не очень. Посмотрим только на прагматические аспекты.

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

Если поставщик отказывает вам в сотрудничестве, то модель SaaS "погибает" моментально - то есть вы не только одномоментно теряете доступ к своей инфраструктурной системе учета и управления, но и, скорее всего, утратите данные (а вот ваш вендор останется с ними).

В случае с инсталлируемым софтом ситуация по-мягче: вендор может лишь заблокировать предоставление вам сервисного обслуживания и обновления программного обеспечения. То есть, вы продолжаете работать и настойчиво искать ответ на вопрос "что делать дальше".

Переберем подходы к проблеме.

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

Следующий шаг - вспомнить все бизнес-решения, которые мы сейчас применяем (применяли до недавнего времени). Почему это важно? Потому, что мы в состоянии стресса создали хороший такой F-list. Он позволяет получить некоторую пользу от несчастья - унифицировать подходы к реализации управления.

Очередной ход - сгруппировать функции из F-list'а в соответствии с возможностью использовать единую систему для их имплементации.

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

Теперь мы можем оценить то, что у нас уже есть, что необходимо приобрести (разработать, найти в open-source-хабах)

Про выбор поставщиков. Мы обожглись и многое знаем о надежности оных. Они могут декларировать в своих проспектиках все, что угодно. Теперь мы хладнокровно интересуемся не их доброй волей, а возможностями. Если они могут без объяснения причин дернуть рубильник - мы знаем, что они так и сделают. Если они могут отказать в обслуживании, не сомневайтесь - придет время - откажут.

Исходя из сказанного, приоритеты такие:
- Есть open-source решение - лучше использовать его.
- Локально устанавливаемое приложение надежнее, чем SaaS. То есть, если вы выбрали решение по SaaS-модели, то сразу побеспокойтесь о том, что вы будете делать, когда вендор закроется сам или закроет вам доступ к своему решению.
- Система, покрывающая сразу значительную часть функционала, предпочтительнее чем несколько разнородных решений. Этот момент может показаться спорным, поскольку мы рискуем за один миг лишиться сразу большого числа функций, но я напомню о проблеме домино - несколько модулей так или иначе приходится "сшивать" и обрушение одного может вызвать цепную реакцию.

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