«Мы хотим заменить систему на новую, потому что в старой всё плохо» — именно такую фразу слышит очередной вендор при заключении контракта на замену или модернизацию системы. С одной стороны, это действительно так, но все же стоит дополнить эту фразу: «Мы хотим заменить систему на новую, потому что в старой хотим убрать недостатки и сохранить достоинства». Казалось бы, небольшая разница, но на практике это оборачивается провалами внедрения новых систем. Почему так происходит и что с этим можно сделать — рассмотрим в этой статье.
Меня зовут Сергей, в IT я работаю более 20 лет и сейчас руковожу направлением разработки одного из бизнес-центров в компании БАРС Груп. В зоне моих обязанностей — курирование разработки множества крупных и мелких проектов, но чаще всего я встречаюсь с проектами замены одной информационной системы заказчика на новую, разработанную нами на актуальных технологиях и с дополнительными возможностями. За время своей работы я наблюдал за ходом проектов, участвовал в них и искал способы сделать разработку информационных систем проще и с минимальными затратами труда разработчиков. Наибольшую пользу, как ни странно, я получил не от специальной IT-литературы, а от дисциплины системного анализа, поэтому мой опыт будет полезен и разработчикам, и аналитикам, и отчасти руководителям проектов.
Почему одна и та же система работает по-разному
Начнем, пожалуй, с понимания того, что любая система реализует какую-либо функцию, возможно, даже несколько. Каждая функция подразумевает некоторый процесс. Рассмотрим подробнее, основываясь на трудах Щедровицкого. В упрощенном виде можно представить следующую картину:
Есть некий процесс, заданный нормативно-правовыми актами (НПА), и есть организация, которая «примеряет» на себя этот бизнес-процесс. Сам бизнес-процесс, проявляясь в каждой конкретной организации, видоизменяется и адаптируется под ее организационную структуру и материальные носители (людей с их менталитетом, технику, программное обеспечение, окружающую среду). Назовем его БП.
В результате получается уникальное сочетание условий «здесь и сейчас». Любое программное обеспечение начинает использоваться не так, как задумывали разработчики, а так, как удобнее для конкретного БП. Получившаяся система (функциональная структура, организационная структура, морфология — материальные носители системы, то есть техника и программное обеспечение, а также люди, эксплуатирующие и то, и другое) имеет свои преимущества и недостатки, которые воплощаются в негласных правилах работы с программой — как вносить данные, что не всегда совпадает с представлениями разработчиков.
Чаще всего проблемы замены систем связаны с трудностями миграции старой системы в новую. Под миграцией системы обычно понимают только перенос программных функций и данных, а этого недостаточно — упущена половина: технологии и структура организации.
Давайте рассмотрим этот вопрос на примере заявления Илона Маска, который нашел в системе социального обеспечения людей с возрастом более 150 лет. Упростим задачу и будем мигрировать только людей с одним атрибутом — датой рождения:
Старая система: дата рождения (поле типа «дата»)
Новая система: дата рождения (поле типа «дата»)
Вроде бы все один в один, но в старой системе есть вариативность этого поля, которая позволяет не указывать значение, и оно по умолчанию заменяется на 20.05.1875, а в новой системе пустое значение соответствует 01.01.0001. Вот уже, казалось бы, при идеальном переводе значения поля «пусто» в «пусто» мы получим разный результат при работе старой и новой системы. Поэтому, несмотря на похожий тип данных, поведение новой системы будет отличаться в случае разных информационных систем (стандартов БД, языка программирования). Поэтому при миграции систем следует учитывать ограничения и особенности технологических платформ, на которых построены эти системы.
Давайте теперь посмотрим на второй аспект — людей, которые создают свои правила при работе для своего удобства или же по необходимости отразить реальный мир в программе с ограниченным функционалом. Чаще всего пользователи, решая свои задачи, начинают накладывать правила поверх. Возьмем аналогичный пример. Допустим, в ходе эксплуатации старой системы у пользователей из даты рождения был известен только год, и корректно внести эту информацию они не могли в поле типа «дата». Тогда они попросили программистов сделать поле текстовым, но при этом оставив маску. В результате получилось: пользователь мог вносить даты вида 00.00.1980. При замене системы этот момент всплыл, когда попытались мигрировать данные. Хотя и в старой, и в новой системе на бизнес-уровне это было поле «дата рождения», на самом деле в старой системе это было вариативное поле с возможностью заполнения гораздо большим диапазоном значений (дата, год).
Логичным решением было бы поменять в новой системе тип данных на текстовый — и проблема решена, но нет: в этом случае придется менять и другие части новой системы, которые спроектированы работать только с правильными значениями поля «дата» соответствующего типа. Да, это сделать можно и нужно, но новая система уже на этапе внедрения, и на переделки уже времени нет в лучшем случае, а в худшем — система поставляется вендором как готовая и неизменяемая, с зашитыми масками ввода даты и выбора через календарь.
Каков же путь?
Давайте оттолкнемся от реальной невысказанной потребности заказчика: «Система должна иметь преимущества старой, но содержать меньше недостатков». Другими словами — ему нужна более быстрая лошадь. Один из вариантов решения — продать машину как эволюционное развитие, но это очень масштабное изменение, и не каждый заказчик готов менять свою организационную и функциональную структуру под новый программный продукт. Поэтому легче выбрать другой вариант: новая система должна быть функционально полной относительно старой системы. Звучит сложно, поэтому давайте рассмотрим на примере.
Пусть старая система представлена функцией f(x), где каждому значению X соответствует некое состояние системы, при этом X — это значение атрибутов сущности. Для нашего примера X — это дата рождения, а f(x) — набор состояний системы при этом значении: X = 01.01.1900 — f(x) = хорошая дата, с ней можем работать вот так... X = 00.00.1920 — f(x) = это год рождения, с ним работаем вот так... X = 01.01.4000 — f(x) = значение даты рождения не задано, с ним работаем вот так...
В таком случае новая система g(x) должна включать все возможности старой системы и добавлять новые: X = 01.01.1900 — g(x) = хорошая дата, с ней можем работать вот так... X = 00.00.1920 — g(x) = это год рождения, с ним работаем вот так... X = 01.01.4000 — g(x) = значение даты рождения не задано, с ним работаем вот так... X = 01.01.0001 — g(x) = служебное значение даты (человек сгенерирован системой), с ним работаем вот так...
Таким образом, для корректной замены системы необходимо убедиться, что все состояния старой системы могут быть сопоставлены с новой системой. Любое состояние старой системы должно быть воспроизведено в новой, если оно является корректным с точки зрения бизнес-процесса организации.
Алгоритм миграции систем и данных
Определяются бизнес-сущности — объекты реального мира.
Определяются состояния бизнес-сущностей в реальном мире согласно НПА или другим правилам (это наше X).
Определяется, как в старой системе (каждому X соответствует состояние системы f(x)) с учетом технологической платформы, структуры организации и т. д.
Определяем, готов ли заказчик менять все и вся внутри себя, помимо используемого программного продукта. Если да — пункт 5, если нет — пункт 6.
Определяем для каждого X состояние новой системы g(x) и проводим процесс изменения системы заказчика (это отдельный большой процесс, не рассматриваемый в этой статье). После чего переносим f(x) с трансформацией, с допустимой потерей части информации f(x) в g(x).
Сопоставляем каждое состояние f(x) с g(x) и переносим данные без потери состояния системы (к сожалению, можем перенести и мусорные данные и процессы), в результате чего новая система с течением времени будет стремиться к виду старой с некоторыми улучшениями, но с теми же проблемами.
Вывод для менеджеров
Если вы приходите внедрять новую систему, а заказчик не готов менять свои процессы, структуру своей организации, то вам придется существенно доработать новую систему и сделать ее копией старой — это нужно заложить в проект внедрения.
Если заказчик готов к изменениям, то в проект внедрения следует заложить существенные затраты на перестройку организации заказчика, вплоть до изменения должностных инструкций, создания новых должностей и ликвидации старых.
Вывод для разработчиков
Если вы приходите внедрять новую систему, обязательно изучите ограничения старой технологической платформы и техники — о них в ТЗ вряд ли будет полноценная информация. Плюс: следует учитывать, что ни один if в legacy-коде, как правило, ставится не просто так, а является реализацией какого-либо бизнес-правила и часто является следствием опыта работы с предыдущей программой.
