Вот ведь как выходит. Что нам предлагается сегодня для нормального внедрения системы типа ERP? Оговоримся, что «нормальное» – это когда внедрение проходит в сроки и без существенного превышения бюджета. Ну, и самое главное – чтобы люди были бы довольны, им было бы удобно выполнять свои обязанности. Так вот. На самом деле ничего толком не предлагается.

Хорошо, в 70-е и 80-е нашим отцам и старшим братьям предлагали отталкиваться от понятия «жизненный цикл ПО», которое предполагало, что требования после формулирования не меняются совсем. Именно поэтому для «Шаттла» народ ваял программное обеспечение 17 месяцев. А потом настали переломные 90-е, и Буч сотоварищи предложили объектно-ориентированный подход к анализу и проектированию ПО. Чуть позже появился UML, унифицированный процесс… Да и Министерство обороны США тоже не сидело без дела. В итоге сейчас предлагаются так называемые гибкие методологии типа экстремального программирования, такие как Scrum и т. п. Тут даже спорить нечего – огромный шаг вперед. Но с одной оговоркой.

Что нам предлагают итеративные методы? Они предлагают последовательно наращивать функционал, уточняя требования «по ходу пьесы». Все вроде бы и хорошо. А теперь представим, что бы внедряем что-то типа 1С или Navision. Описываем бизнес-процессы, модифицируем их, выделяем требования, начинаем модифицировать стандартную систему под конкретные требования... Стоп, вот тут-то нас ждет подвох. Как, простите, мы будем внедрять систему кусками? Да еще выдавая каждые три-четыре недели готовые части? Одно дело, когда в Компании вообще нет никакой системы – в этом случае плавно переходим с Excel на нашу свежеиспеченную систему. А если уже что-то работает? Вы всерьез думаете, что пользователи будут параллельно работать в двух системах? Если система пишется для табачного ларька, то будут. А если пользователи в день набивают по 500 накладных, то на фиг они вас пошлют, и будут правы. Да и ошибок не избежать – все ж таки должен соблюдаться принцип однократного ввода информации. В практике автора была попытка работать параллельно в двух системах на достаточно крупном складе. Самые старательные продержались ровно два дня. Люди просто физически не успевали работать на два фронта: машины стоят под разгрузку, сразу штук десять (завозы-то, как водится, сезонные –  то пусто, то густо). Фура простаивает – деньги капают. Деньги капают – народ нервничает. Такие дела...

В принципе, людей можно заставить (удастся ли?) работать сразу в двух системах. Но здесь возникает сразу два очень неприятных вопроса.

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

Второе. Надо иметь средства сверять данные в двух системах. Иначе зачем все это затевалось? А тут еще надо понять, какую информацию именно надо сверять, а какую нет.

Короче говоря, время разработки увеличивается, причем существенно. Раза в два – точно. Расчет тут очень простой – писать интерфейс для фазы по времени занимает примерно столько же, сколько и разработка нового функционала. Причем, разработка нового функционала и интерфейсов к нему ведется параллельно. Возможно такое? Не слишком ли дорого? Может, есть другой путь? Конечно, всегда есть путь разработать все от начала до конца, потом это дело отдать пользователям. А там уж – если выплывут, то и хорошо. При этом, нужен рашпиль, чтобы заточить «готовый» функционал под то, что на самом деле нужно.

Но мы-то решили использовать именно гибкие технологии, которые, как нам обещают многочисленные книги, дают прирост в качестве разработки. Кроме того, в случае внедрения программного обеспечения по схеме «шаг за шагом» в новой системе постепенно наращивается первичное химерическое информационное поле. Химерическое – потому что нам никогда не удастся сделать слепок данных, который соответствует реальному положению дел в реальном времени. С задержкой, пусть и небольшой – можем, а в реальном режиме времени – нет. Это принципиальный момент, с ним ничего поделать нельзя. Если же внедрять по схеме «Биг Бен», то нас ожидает крайне дорогостоящая и нудная процедура выверки всех данных, загрузка их в новую систему, и т.д. и т.п. В первом случае нам тоже предстояло бы с этим столкнуться, но масштабы бедствия намного скромнее. Раз так, необходимо адаптировать существующие процессы под наши требования, которые обозначены выше. А именно – совместить фазы разработки собственно нового функционала и разработки интерфейсов.

Поскольку параллельно, очевидно, их делать не удастся, то можно предложить такие варианты. Первое предложение заключается в том, чтобы разделить эти фазы и чередовать между собой при одновременном сокращении времени одной фазы. Второе – раз увеличивать срок фазы нельзя, значит, будем сокращать объем функционала, реализуемый в одну фазу. И тот, и другой вариант означают, что время разработки увеличится как минимум в два раза. Как говорят нам старшие товарищи, необходимо от союза «или» перейти к союзу «и», то есть и время разработки оставить почти без изменения, и разработать поэтапный переход от одной системы к другой. На практике это подразумевает, что нам необходимо взять из существующих процессов разработки лучшие части, одновременно решая насущную задачу «как бы мне, рябине, к дубу перебраться». Сумеем ли? Похоже, что решение есть. Раз мы не можем физически увеличить время, да и людей добавлять нет смысла (так как тут же увеличиваются финансовые расходы), то надо суметь уменьшить время разработки самих интерфейсов.

Вот и выход.

Первое. Найти точки соприкосновения у двух систем в плане возможности работы их с одинаковыми форматами данных.

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

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

Четвертое. Собственно при разработке сущностей сразу подключать их к универсальному механизму.

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

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

И, наконец, беда может подстерегать нас в случае перестройки не только бизнес-процессов, но и классификации используемых сущностей (например, перекодировка товаров, с которыми работает компания, или введение новых единиц измерения и новых учетных единиц – раньше товар учитывали комплектами, а теперь учитываем упаковками...). Хорошо, если хоть как-то можно поставить их в соответствие друг другу, но иногда это не удается. Так, в новой системе мы сумеем запросто списать или оприходовать товар в новых единицах измерения, а вот в старой так не получится, поэтому остатки будут все время разными и никогда не сойдутся. А как же тогда сравнивать их и зачем?

Когда мы можем почти безболезненно получить интерфейсы для двух систем? Очевидно, когда они обе базируются на одном и том же базовом программном обеспечении, пусть и разных версий. Кстати, часто бывает так, что Компания переходит к системе большей версии. Например, с Navision 3.60 на Navision 4.0. Естественно, что это все равно полноценное внедрение, но люди уже готовы к переходу, так как принципы работы с программным обеспечением остаются, в общем и целом, теми же самыми. Архитектура тоже обычно не претерпевает существенных изменений. Одно из исключений – 1С версии 7 и 8. Специалисты утверждают, что это совершенно разные системы с точки зрения программирования. К сожалению, с ростом Компании возникает необходимость перехода именно на другую платформу, поэтому такой вот фокус не всегда удается. Скорее, удается достаточно редко.

Выводы.

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

А. Стрельников