Мифы и реальность перехода с иностранного ПО

Свою статью я назвал «Мифы и реальность перехода с иностранного ПО». Она разбита на две части: практическую – на примере нашего проекта, и более теоретическую.

Как и многие компании, которые работают с внедрением, мы оказались вовлечены в историю с замещением иностранного ПО и «быстрым переходом». В феврале 2024 года к нам пришли клиенты и сказали: «Друзья, у нас сложная ситуация». Это дочернее предприятие иностранной компании, французского холдинга. У них была иностранная система учета по международным стандартам и формирования международной отчетности (JD Edwards), которую нужно было срочно заместить – новый пакет санкций, систему скоро отключают.

Компания занимается операционными проектами – маркетинговыми исследованиями. У них ежегодно реализуется порядка 15 000 проектов, то есть это очень крупный бизнес. При этом переход у них начался еще до обращения к нам: систему операционного управления проектами они уже начали замещать собственными силами. Было разработано ПО, которое находилось в опытно-промышленной эксплуатации.

Какие задачи стояли перед нами:

• Нужно было формировать отчетность по корпоративным стандартам IAS/IFRS.

• Разработать инструменты учета и формирования отчетности по МСФО-15 – это было одно из ключевых требований.

• Обеспечить требования корпоративной учетной политики при ведении учета и формировании отчетности.

• Обеспечить интеграцию со смежным ПО собственной разработки.

• И вишенка на торте – нам сразу сказали: с 20 июня 2024 года их текущую систему отключают. То есть июнь компания уже должна была прожить без исторического программного обеспечения.

Ключевые принципы управления кризисным проектом

С самого начала было понятно, что проект находится в кризисе. Мы заходили в него с осознанием, что будет очень сложно и стандартные инструменты проектного управления здесь неприменимы. Ни Agile, ни классическая модель Waterfall не позволят уложиться в такие сроки.

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

В условиях кризиса и высокого уровня напряжения у заказчика приходится уделять огромное внимание CRM-составляющей: постоянно общаться с клиентом, успокаивать, держать контакт. Говорить: «Друзья, у нас все под контролем, мы успеваем, все сделаем. А если что-то не успеем – доделаем позже».

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

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

Критически важен накопленный опыт команды и наличие наработок по профильной задаче. В нашем случае – это МСФО, которым мы занимаемся более 15 лет, а некоторые коллеги – более 25. Без такого опыта в кризисный проект заходить просто нельзя – шансов на успех не будет.

Нужно быть готовыми к тому, что разработка будет идти параллельно с эксплуатацией. Система уже работает, пользователи ею пользуются, а вы продолжаете ее дорабатывать в режиме «наживую». К этому нужно относиться спокойно.

Нормальных функциональных требований в таких проектах не бывает. Все поступающие требования нужно жестко классифицировать: есть критически необходимые – без них система не работает, и есть требования к функциям, без которых можно временно жить. Все критичное идет в первую очередь, все остальное откладывается. Если отчет можно временно собрать в Excel – пусть будет так.

В таких кризисных проектах не существует этапов. Нет разделения на анализ, разработку, тестирование, внедрение – все происходит одновременно. Весь проект – это один неделимый этап.

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

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

За этим должен внимательно следить руководитель проекта, потому что именно такой подход к работе позволяет «вытаскивать» кризисные проекты.

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

Ход реализации, технические сложности и результаты

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

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

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

У нас не было доступа к исходной системе – ни технического доступа к конфигурации и исходному коду, ни к структуре метаданных системы Oracle. Мы не понимали, что у нее внутри.

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

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

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

Через реверс-инжиниринг, по отчетам и косвенным признакам, мы обнаруживали множество «костылей», которые были внедрены в исходной системе. Их никто не описывал и не фиксировал. Причем это были как технические решения – когда разработчик что-то сделал и никому об этом не рассказал, так и методологические – когда у функциональных заказчиков что-то не получалось, они вводили временные «заглушки», которые становились постоянными.

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

Мы даже не рассчитывали, что найдется человек, который сможет целиком объяснить, как работает система. И такого человека действительно не было. А если бы и появился, верить ему все равно было бы нельзя – любой человек описывает систему только со своей точки зрения.

В качестве технологического стека мы взяли типовое решение «1С:Бухгалтерия КОРП МСФО». В процессе реализации стало понятно, что стандартный функционал типовых решений не всегда применим к конкретной ситуации. Это нормально: типовые решения универсальны, а в конкретных проектах всегда есть индивидуальные требования.

Обычно такие отклонения мы закрываем через изменение методологии: раньше вы работали так, теперь будете работать иначе. Но в этом проекте мы упирались в жесткие корпоративные ограничения: «У нас в корпоративной политике написано, что должно быть именно так». Значит, нужно переделывать систему под требования, а не менять методологический подход.

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

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

В августе 2024 года мы запустили систему в опытно-промышленную эксплуатацию. Часть функциональных блоков начала работать, пользователи начали их использовать, в том числе для подготовки отчетности. Июнь и июль закрывались уже с отражением в системе, но без полноценного функционала – базовые алгоритмы еще не были полностью реализованы, до завершения ОПЭ отчётность коллеги формировали с активным использованием Excel.

Опытно-промышленная эксплуатация завершилась в октябре – начале ноября 2024 года. К этому моменту были реализованы основные функции и ключевые инструменты. Начиная с этого периода отчетность уже формировалась непосредственно в системе, без промежуточных Excel-файлов и ручных расчетов, хотя финальные отчeты в системе реализованы не были и их заполнение осуществляется в Excel до сих пор (все уже привыкли, да и инструментарий уже был подготовлен).

Полноценный запуск в промышленную эксплуатацию состоялся в январе – при подготовке отчетности за 2024 год. Систему торжественно поставили на баланс 31 декабря 2024 года и с нового года начали использовать как основную.

Дальше, до мая, мы занимались доработкой отложенных задач: дополнительного функционала, «бантиков» и всего, что не являлось критичным на этапе запуска.

В итоге проект длился с начала марта 2024 года до конца мая следующего года – от старта до полного завершения всех доработок.

Главные выводы и уроки проекта

Какие выводы мы сделали – или, точнее, подтвердили – в этом проекте? Часть из них нам была известна заранее, потому что опыт работы с кризисными проектами у нас уже был.

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

Второй вывод: кризисный подход и короткие проекты перехода – это лотерея. Это не первый наш проект такого рода, и нужно говорить прямо и честно: никакой гарантии результата здесь нет. Если кажется, что можно собрать набор факторов и научиться «быстро переводить системы», – это «ошибка выжившего». Любой быстрый переход – это лотерея, и чаще проигрышная. Кризисное управление не дает гарантий.

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

Четвертый, самый важный вывод: любой кризисный проект – это не про эффективность. Как только в таком проекте появляется идея «сэкономить бюджет» или «ужаться по финансам», можно считать, что проект обречен. Кризис – это не про финансово-экономическую результативность. И мы изначально понимали, что этот проект не про зарабатывание денег, а про результат – и, в каком-то смысле, про опыт, которым потом можно делиться.

Критерии успеха и признаки корректного перехода

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

У любого проекта есть три критерия успешности:

• Сделано то, что требуется. Причем не то, что хотел заказчик, а то, что действительно нужно бизнесу и пользователям.

• Сделано в срок. В нашем случае сроки были сорваны.

• Сделано в рамках бюджета. И это тоже не про нас.

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

Первое – сохранение текущего функционала и методик работы. Если при переходе теряются функции управления или учета, это уже не переход, а внедрение новой системы.

Второе – обеспечение преемственности информации. Вся историческая информация, необходимая для работы, должна быть перенесена в новую систему. Это обязательное условие. Если вы запускаете новую систему «с нуля», а вся история остается в старой системе – это не переход с программного обеспечения, потому что вы не обеспечиваете преемственность информации.

Третье – развитие текущих инструментов. Переход может быть не только про сохранение, но и про расширение возможностей.

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

Методология перехода и этапы реализации

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

Когда вы заходите в проект перехода, вам нужно максимально глубоко проанализировать все, что происходит в компании. Это полноценное обследование: описание бизнес-процессов, методик, функциональных требований, взаимодействия между подразделениями, используемого программного обеспечения, инфраструктуры, серверов – всего. Для понимания масштаба: описание работы предприятия среднего размера может занимать до 600 страниц.

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

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

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

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

И только после этого начинается реализация проекта (или, что бывает чаще, портфеля проектов). Такие переходы не делаются в один шаг. Минимум два этапа: методологическая подготовка и автоматизация.

У такого подхода есть свои особенности.

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

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

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

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

P.S. Хочу выразить благодарность Сергею Евстраткину и Динаре Мустафиной, коллегам со стороны наших заказчиков, а также Николаю Шилкину и Анне Лешак, ключевым сотрудникам команды с нашей стороны. Без их профессионализма, терпения и мужества описанный выше проект провалился бы чуть более чем полностью.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах..