Иногда бывает нельзя просто дождаться развертывания новой системы, в которой будет все, что хочет руководство компании, а требуется сначала «догнать» прежнюю систему, и затем уже «перегнать» ее, реализовав новый функционал
Наверное, каждая большая компания хотя бы раз переживала масштабную смену информационной системы. Организация растет, и в какой-то момент информационная система, с которой начиналась работа, перестает удовлетворять новым требованиям бизнеса. Встает вопрос о замене системы на другую — более современную, производительную, более «серьезную».
Многие считают, что когда компания переходит из разряда средних в разряд крупных, то замена большой информационной системы становится практически неосуществимой из-за целого ряда очень существенных вопросов. Во-первых, обычно внедрение новой системы предполагает внесение изменений в бизнес-процессы компании, которые отлаживались годами и зачастую, по мнению ее руководства, представляют собой ноу-хау. Альтернативный вариант — существенно адаптировать новую систему или разработать ее «с нуля» под нужды компании — представляется непомерно сложным, длительным и дорогим. Во-вторых, внедрение связано с риском фактической остановки бизнеса на неопределенный срок, до тех пор пока новая система, наконец, не «задышит». В-третьих, за годы своего развития прежняя система обросла всевозможными специфическими доработками и глубоко интегрировалась в ИТ-ландшафт компании, а потому сформулировать полные требования к новой системе, отталкиваясь от того, что уже есть, зачастую невозможно. В-четвертых, к системе успели привыкнуть многочисленные пользователи. Переучивать их — длительный процесс, без которого запуск новой системы не будет успешным. В-пятых, прежняя система, внедренная в компании, — наверняка одна из тех, что представлены на рынке, и даже если за много лет ее эксплуатации стали понятны ее ограничения и недостатки, существенно лучших вариантов подчас не видно.
Можно и дальше перечислять опасения, которые испытывает руководство большой компании, когда задумывается над перспективой замены основного инструмента управления бизнесом, особенно если в памяти еще свежи трудности предыдущего перехода. В результате руководство может предпочесть медленный эволюционный путь развития, даже осознавая, что с этого момента прежняя система станет тормозом в развитии основной деятельности компании.
Нельзя не признать, что эти опасения имеют под собой серьезную почву. И все же есть несколько подходов, в совокупности позволяющих преодолеть вышеперечисленные сложности с приемлемыми рисками и в разумные сроки решить поставленную задачу. Проиллюстрируем их на примере проекта, реализованного для крупной розничной торговой сети федерального масштаба.
Глубокий реинжиниринг
Речь пойдет о реинжиниринге системы крупной торговой компании для управления ее складскими товарными запасами и поставками товаров в розничные магазины по всей территории РФ и в зарубежные филиалы. Несколько лет система активно развивалась, поддерживая динамичный бизнес торговой сети. Нагрузка на систему постоянно росла, и к началу серьезных преобразований объем данных на сервере составлял более 900 Гбайт, пиковая нагрузка в день составляла более 500 тыс. проводок, а максимальная нагрузка за месяц достигала 10 млн. проводок. Объем бизнес-логики с начала эксплуатации системы вырос в три раза. В общей сложности на внедрение и развитие системы было потрачено 11,5 человеко-лет.
В начале 2008 года после детального анализа было принято решение провести глубокий реинжиниринг системы. Причин для этого накопилось много. Бизнес-процессы за это время изменились кардинально: компания перешла от «тянущей» к «толкающей» логистике с категорийным товарным менеджментом. Кроме того, руководство приняло решение часть закупок и поставок производить в предупакованных наборах товара и таким образом снизить логистические издержки. Для ИТ-поддержки потребовался новый большой блок функций, охватывающий все бизнес-процессы. Старая система представляла собой код, неразрывно связанный с несколькими соседними модулями в монолитный продукт, развернутый на одном сервере. Для облегчения управления отдельными модулями требовалось повышать их автономность и переходить к современной трехзвенной архитектуре, которая бы обеспечила более высокую масштабируемость системы. Необходимый комплекс изменений невозможно было провести эволюционным путем на нагруженной системе в приемлемые сроки. Были и другие причины.
Задача усложнялась тем, что пока проектировалась и разрабатывалась новая система, прежняя продолжала развиваться. Постоянно требовались доработки функционала, поэтому просто дождаться новой системы, в которой «все это будет», было нельзя, требовалось сначала «догнать» прежнюю систему, а затем уже «перегнать» ее, реализовав новый функционал.
Дорогу осилит идущий
Разработка концепции заняла около месяца плотной совместной работы исполнителя и заказчика. Помимо описания целей и задач проекта, а также перечня автоматизируемых бизнес-процессов (границ проекта), концепция включала несколько разделов, во многом определявших архитектуру будущей системы.
В нашем случае удачной идеей оказалось включить в концепцию эскизы учетного плана счетов новой системы. Эти диаграммы описывают основные аспекты учета в лаконичном и интуитивно-понятном виде, хорошо отражая реальные бизнес-процессы, благодаря чему специалистам розничной сети было просто верифицировать эти документы. В результате стал постепенно вырисовываться облик будущей системы и ее основные функциональные блоки.
Как известно, если разрабатываемая система призвана заменить уже существующую, остро встает вопрос разработки требований. Прежняя система обычно уже не может служить достоверным источником. На выявление новых требований, разработку полного технического задания и его согласование может уйти очень много времени, особенно если система большая и сложная. За этот срок требования успевают существенно измениться и техническое задание становится уже неактуальным. В такой ситуации очень помогают «гибкие» (agile) методологии. Их основой является итеративный подход, при котором формирование требований, проектирование, разработка, тестирование и внедрение нового функционала происходит небольшими регулярными итерациями.
В данном проекте разработанная концепция послужила основой для итерационного подхода. Она определяла ряд функциональных областей, которые можно было прорабатывать поэтапно, обговаривая детали с небольшой группой представителей розничной сети.
Аналитики проекта провели ряд встреч с представителями бизнес-руководства и ключевыми пользователями прежней системы, выяснили их текущие проблемы и отразили их пожелания в ходе разработки архитектуры новой системы. В результате стала возможной постановка задач для отдельных частей системы, и задачи эти было гораздо проще понять и согласовать. Параллельно шла разработка и тестирование по тем требованиям, которые были сформулированы ранее.
Во время разработки появлялось огромное количество новых требований, которые невозможно было выявить в начале проекта. Появилось даже несколько новых систем, с которыми также нужно было организовать взаимодействие. Добавилось несколько больших блоков функциональности — их первоначально включать в проект не планировалось.
Иногда в процессе анализа выяснялось, что существующие бизнес-процессы плохо согласуются с предлагаемыми концептуальными изменениями. В таких случаях или принималось решение об изменениях в проекте новой системы, или планировалось изменение бизнес-процессов компании. Это сдвигало сроки готовности системы, но в ряде случаев руководство розничной сети пошло на такое решение, понимая, какие преимущества получит их бизнес и какой ценой они будут достигнуты. Важно, что каждый раз это был сознательный выбор руководства, а не жесткое ограничение системы.
Те, кто выполняли масштабные проекты, знают, что невозможно создать качественную новую систему без тесного сотрудничества на всех уровнях — не только ключевых архитектурных решений, но и мелких деталей системы.
Примерно раз в месяц промежуточные результаты демонстрировались (в виде работающей системы) представителям розничной сети, включая будущих пользователей и сотрудников группы внедрения. Это позволило максимально быстро наладить обратную связь и скорректировать представления разработчиков и аналитиков о том, что должно получиться в конечном итоге. В свою очередь, пользователи видели, как постепенно вырисовывается та система, с которой им предстоит работать.
В ходе реализации системы было принято необычное для подобных проектов решение: один из ИТ-специалистов розничной компании, хорошо знакомый с ее бизнес-процессами, был включен в команду исполнителя на правах обычного разработчика и освоил новые для него технологии. Благодаря этому у компании, заказчика системы, появилась возможность получать максимум информации о внутреннем устройстве будущего программного продукта, его внутреннем качестве, процессе разработки. Кроме того, у компании появилась уверенность в том, что в ходе создания системы не будут упущены нюансы ее бизнес-процессов.
Разработчики постарались максимально облегчить пользователям переход на новую систему. Цветовое кодирование, «горячие клавиши», состояния документов — все это составляет язык, на котором думают пользователи. Там, где было возможно, элементы пользовательского интерфейса новой системы воспроизводились по образцу прежней.
Бережное внедрение
Прежняя система представляла собой приложение, работающее практически в режиме 24x7. Остановка снабжения магазинов на одну-две недели при переходе на новую систему стоила бы очень дорого. Кроме того, была велика вероятность того, что при переходе на эксплуатацию новой системы быстро обнаружатся важные забытые требования, и в результате придется на какое-то время переходить на прежнюю систему. Эти риски всем хотелось свести к минимуму. Но как?
Нужно было переход с прежней системы на новую сделать постепенным. Этот подход соответствует идеологии бережного внедрения (см. статью Михаила Заборова «Управляемая ликвидация», журнал «Директор ИС», 2008, № 12). Совместно с ИТ-специалистами розничной компании был придуман механизм взаимодействия прежней и новой систем, позволяющий переводить на новую систему снабжение отдельных региональных филиалов и даже отдельных магазинов. Сначала новые технологии работы были опробованы на нескольких московских магазинах. После устранения выявленных недостатков в два приема были подключены все московские и подмосковные магазины.
Бережное внедрение решило также проблему с обучением пользователей в региональных филиалах — благодаря тому, что механизм плавного перевода позволил внедрять систему в регионах по очереди.
К середине февраля нынешнего года вся российская часть розничной сети будет управляться новой системой. От старта проекта до внедрения системы в первые магазины прошло 16 месяцев. Не останавливая ни на один день основную деятельность торговой сети, удалось заменить прежнюю, изжившую себя систему, на новую, отвечающую сегодняшним требованиям, радикально отличающуюся по технической архитектуре, производительности и возможностям.
Игорь Беспальчук — руководитель проектов компании CustIS («Заказные ИнформСистемы»)