Версия 04:00, 27 марта 2010

Б

руководитель проектов компании CustIS (Заказные ИнформСистемы)

Здесь мы публикуем полную версию статьи. Её журнальная версия опубликована в Директор информационной службы (CIO.RU), № 2 (февраль) 2010, стр 21-23 ^[1]

Реинжиниринг системы управления товарными запасами в ТС федерального масштаба.

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

Невозможная задача

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

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

1. Обычно, вместе с желаемыми преимуществами, новая система предполагает и несколько отличающиеся бизнес-процессы. В этом случае компании придется менять свои собственные бизнес-процессы, которые отлаживались годами, и зачастую составляют «now-how». Альтернативный вариант — существенно адаптировать новую систему, или разработать «с нуля» под нужды компании — представляется непомерно сложным, длительным и дорогим.
2. Внедрение связано с риском остановки бизнеса на неопределенный срок, пока новая система не «задышит». Вероятны неоднократные фальстарты и откаты к старой системе.
3. Вопрос о переходе усложняется тем, что за годы развития система обросла всевозможными специфическими доделками, интеграцией с другими системами в ИТ-ландшафте компании. Полных требований к системе обычно предоставить невозможно.
4. К системе привыкли многочисленные пользователи, которых придется переучивать. Это тоже длительный процесс, без которого невозможно запускать новую систему.
5. У компании уже внедрена одна из крупных систем, представленных на рынке. И даже если за много лет стали понятны ограничения и недостатки используемой системы, существенно лучших вариантов на рынке и не видно.

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

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

Глубокий реинжиниринг

Речь пойдет о реинжиниринге системы управления товарными запасами и поставками, которая за несколько лет работы стала «line of business»-приложением. Она управляла запасами на складах, а также снабжением розничных магазинов по всей территории РФ и в нескольких зарубежных филиалах крупной торговой компании.

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

• объем данных на сервере — более 900 Гб;

• пиковая нагрузка в день — более 500 тыс. проводок;
• максимальная нагрузка в месяц — 10 млн проводок;
• объем бизнес-логики с начала эксплуатации системы — вырос в три раза;
• время на внедрение и развитие — 11,5 человеко-лет.

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

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

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

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

Шаг за шагом пройдешь весь путь

Концепция

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

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

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

В результате постепенно стал вырисовываться облик будущей системы и ее основные функциональные блоки.

Итеративный подход

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

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

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

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

Параллельно с новыми постановками шла разработка и тестирование по тем требованиям, которые были сформулированы ранее.

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

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

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

Тесное сотрудничество

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

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

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

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

Бережное внедрение

Как уже говорилось выше, старая система представляла собой приложение, работающее практически в режиме 24x7. Остановка снабжения магазинов на одну-две недели для перехода на новую систему стоила бы очень дорого. Кроме того, при старте новой системы всегда велика вероятность того, что быстро обнаружатся важные забытые требования, и придется откатываться назад, на старую систему. Эти риски всем хотелось свести к минимуму. Но как? Задача похожа на то, как если бы вас попросили заменить у локомотива на полном ходу старый паровой котел на новый электродвигатель.

Нужно было обеспечить такой режим внедрения, чтобы переход со старой системы на новую происходил постепенно. Этот подход соответствует идеологии бережного внедрения, о которой более детально рассказано в статье Михаила Заборова «Управляемая ликвидация» (ДИС, № 12, 2008 г.).

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

Сначала новые технологии работы были опробованы на нескольких московских магазинах. А после доработки выявленных недостатков в два приема были подключены все московские и подмосковные магазины.

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

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

Невозможное возможно!

Ко времени публикации этой статьи вся российская розничная сеть заказчика управляется новой системой. От старта проекта до внедрения системы в первых магазинах прошло всего 16 месяцев.

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

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

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

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

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

Ссылки

1. ↑ "Директор информационной службы (CIO.RU), № 2 (февраль) 2010, стр.21-23.