Мы развиваем экспертизу по оценке состояния и возможных путей развития для сложных/унаследованных/устаревших систем.
По желанию заказчка готовы и выполнить соотвествующие работы по модернизации или миграции систем.
В первую очередь пользовательских прикладных систем таких как: ERP/CRM/BPMS/Личных Кабинетов/АБС и ДБО/Биллингов/Эл.коммерции.

Типичные причины замены или модернизации систем: рост затрат на обслуживание; необходимость снижения времени и затрат на изменения; существенное улучшение бизнес-процессов; вывод устаревших аппаратных и программных систем из эксплуатации; реагирование на неотложные изменения (например регуляторные или рыночные); отсутствие необходимых поддержки или знаний.

Бег на месте при замене или модернизации устаревших/унаследованных систем.

Многие организации неоднократно предпринимали усилия по устранению устаревших систем. Как правило, такие организации проходят через ряд программ модернизации, рассчитанных на 3-5 лет. Во многих случаях в рамках многолетней программы модернизации определялся и впоследствии реализовывался новый технологический подход.

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

Причиной повторяющихся неудач стали несколько основных факторов.

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

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

Со временем становилось очевидным все большее расхождение между реальными бизнес-требованиями и теми, которые были изначально утверждены на новых проектов. Чем дольше длилась каждая программа, тем острее становился разрыв между планом модернизации/замены и БКО (Бизнес-как-Обычно) и будущими потребностями. Хотя для включения новых требований в программу модернизации/замены и существовали процедуры контроля изменений, но они занимали очень много времени и, например, в силу ранее заключенных контрактов с поставщиками, были чрезмерно дорогостоящими.

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

Для сложных систем, какими и являются устаревшие и унаследованные системы, обязательно применение системного мышления/подхода, основанных на принципах, изложенных, в частности, Демингом, Голдраттом, Седдоном и другими авторами. Эти принципы включают в себя законы Галла и Конвея, принцип 5-95, а также другие концепции и методы. Важно подчеркнуть, что технологии составляют лишь меньшую часть проблемы, связанной с устаревшими системами. Большую роль в достижении успеха играют методологии, организационные структуры и руководство.

DevOps321, ККБ и все все все.

Ниже два коротких видео на 7 и 6 минут, в которых мы предлагаем пример подхода к работе со сложными системами через концепцию DevOps321 и ККБ (кастомизированной кодовой базы). В них мы разбираемся с вопросом, почему простые подходы не срабатывают в работе с сложными системами и почему в практически любом ИТ-ландшафте возникают сложности и нагромождение систем.

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

Если ваша DevOps-группа не обладает экспертизой покрывающей всю ККБ, то рекомендуем начать с разработки контрольных примеров (КП-автотестов), охватывающих все критические пользовательские сценарии работы. Это будет первым шагом к пониманию и контролю над вашей кодовой базой. И в дальнейшем наличие КП-автотестов окупится многократно.

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

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

Мы готовы предложить вам экспресс-оценку текущего состояния вашей ККБ и предоставить конкретные решения/сценарии по ее улучшению всего за 2-3 месяца (включая сроки, стоимость и требуемые ресурсы). Мы предлагаем взаимодействие в форме интервью с вашими сотрудниками и участие в рабочих совещаниях в режиме слушателя. Уверены, что само участие в тест-драйве принесет дополнительную пользу всем сотрудникам и вашей организации в целом.

Мы предоставляем полный проектный сервис по импортозамещению для выбранной системы/технологической компоненты.

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

1. Обследование кодовой базы и организационного процесса:
   Подробное исследование кастомизированной кодовой базы и процессов сопровождения и развития программного обеспечения.
2. Формирование дорожной карты проекта:
   Разработка дорожной карты проекта, включая определение сроков, бюджета и целевой архитектуры.
   Установление реалистичных ожиданий для руководства и стратегий управления рисками проекта.
3. Формирование команды проекта:
   Задействование уже имеющихся сотрудников.
   Донабор необходимых сотрудников для успешной реализации проекта.
4. Выполнение поэтапной миграции системы:
   Использование современных инструментов, включая Selenium, Java, JMeter, Kafka, Debezium, PostgreSQL, MySQL, SuiteCRM, app321 (React, Scala/Java), BPMS (Camunda, bpm321) и q321 (универсальный ERP-подход).
   Применение организационного подхода DevOps321.
5. Вывод из эксплуатации старого решения:
   Завершение использования устаревшей системы.

Итогом данного проекта будет работающая импортозамещенная система и соответствующая группа DevOps для её поддержки.

Возможные переходы включают:

• Siebel, MS Dynamics, SaleForce на SuiteCRM, MySQL/PostgreSQL.
• SAP - SuiteCRM, Camunda, 1С, MySQL/PostgreSQL, q321.
• Oracle, MS SQL - MySQL/PostgreSQL.

Мы готовы рассмотреть миграцию с любой исходной архитектуры на вашу выбранную целевую архитектуру.

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

Дата публикации: 04.09.2023