Менять ли самописное ПО на тиражные продукты? Если да, то как организовать переход, ведь одномоментным он быть не может? Об опыте масштабного проекта такого класса рассказывает ИТ-директор группы компаний «Детский мир» Сергей Рогов.

Intelligent Enterprise: Каково положение с самостоятельными разработками в вашей компании? Как и почему оно меняется?

Сергей Рогов: Я работаю в этой должности чуть больше двух лет, и на момент моего прихода в управляющую компанию группы было 17 прикладных бизнес-приложений (учет зарплаты — отдельная система, учёт кадров — еще одна и т. д.). Большинство было разработано самостоятельно, часть интегрирована, часть нет. Сеть тогда только начала развиваться. Пока было два-три магазина, самописные приложения нас устраивали. Они были неплохо написаны, работали стабильно, были полностью управляемы и контролируемы собственной командой. О рисках масштабирования или ухода разработчиков тогда никто не задумывался. С быстрыми изменениями в бизнесе положение начало меняться. Самописные приложения перестали удовлетворять руководство.

Сегодняшняя стратегия у нас такова. Идет внедрение ERP-системы, построенной на нескольких платформах различных производителей. Ядро автоматизации — Oracle Retail, финансовая часть — на базе продуктов «1С», аналитическое BI-решение — хранилище данных на платформе Oracle с аналитическим инструментарием от Cognos, и специализированное решение для управления контрактами, для упорядочивания работы с поставщиками товаров. Для управления товародвижением и поддержки основных бизнес-процессов установлена система «Домино» (компании «Софт-Вест»). Это конструктор, имеющий внутренний язык программирования и обладающий довольно большими возможностями. Все его настройки и дополнительные модули сделаны за семь лет эксплуатации в «Детском мире» нашим ИТ-подразделением. Вся функциональность, ранее реализованная в разрозненных самописных программах, постепенно передается в ERP-систему, и в результате должно остаться лишь одно такое приложение — «Домино». Остальные исчезнут.

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

Почему же было принято решение о переход на тиражные продукты?

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

Второй момент — невозможность создать действительно хороший и отчуждаемый программный продукт. Обидно, что такая «домашняя» разработка лишает классных программистов возможности его сделать. Как правило, такие разработки не оформляются в виде проекта внутри компании. Понятно, что применяя внутреннюю разработку, компания пытается сократить издержки. И на мой взгляд, не­­оправданно тяжело «не ИТ-компании» держать полный штат, полную структуру, необходимую для качественной разработки. Это штат аналитиков и постановщиков задач, руководители, кодировщики, тестировщики, разработчики методики тестирования, пользовательской и технической документации. Все эти звенья необходимы для разработки отчуждаемой продукции высокого уровня. Качественная учебная база, сервис, методики сопровождения — все это присуще ИТ-компаниям, которые профессионально занимаются разработкой ПО. Создавать высококачественный продукт можно только при наличии такой структуры, рассчитанной на длительное использование Если не ИТ-компания готова содержать такой штат — это ее выбор. Но насколько это экономически выгодно — большой вопрос. Если бы мы вступили на такой путь, я должен был бы просто поменять вывеску «Департамент ИТ» на «Детский мир — софт».

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

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

Не согласен. Это зависит от того, как подходить к проекту. Если управление идет методом: «Я сказал, поменять вот это и вот то, так меняйте быст­ро» — и исполнители меняют, если нигде никаких формальных следов не остается, а через год все забывают, что и где и, главное, зачем меняли, то зависимость будет всегда, кто бы ни был исполнителем. Но это в корне неверный подход. Чтобы система стала отчуждаемой, независимой ни от кого, нужно правильно ставить задачу перед исполнителями. Это безусловно будет дороже стоить, но материализация риска зависимости обойдется компании ещё дороже. Мы все это просчитывали.

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

Вы все процессы сначала описываете «как есть», а потом «как будет»? Распространенный контраргумент — это очень долго и дорого.

Хрестоматийно такой путь верен, но мы применяем более гибкие современные подходы. Если мы внедряем Oracle, то используем методику этого вендора AIM, но с небольшими ново­введениями, которые позволяют нам значительно сократить время и затраты. Ее ключевой тезис таков: зачем описывать то, что есть, если это в любом случае будет ломаться?

Прежде всего мы прописываем положение «как должно быть». Такой подход иногда называют «ванильным» внедрением: мы готовы максимально использовать процессы, настроенные в системе, и ломать свои собственные, перестраивать их. К этому мы пришли сознательно, проанализировали, что у нас есть, и сделали вывод, что модернизировать сложившиеся процессы бессмысленно, всё нужно полностью перестраивать. Отступления от стандартных процессов, предлагаемых системой, у нас оставляют не более 10%. Топ-менеджмент принимает активное участие во внедрении. Конечно, если бы не было такой вовлеченности топ-менеджмента в этот проект, ни о чем подобном речь бы не шла и вообще проект не продвигался бы столь быстро и широко. Разумеется, внедрению предшествовала большая предварительная работа, в том числе разъяснительная. Но теперь ясное понимание, что это не ИТ-проект, а бизнес-проект, у руководства есть.

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

При таких серьезных изменениях жизни компании недовольство людей неизбежно…

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

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

Как же вы будете передавать свою систему на аутсорсинг, если неясно, что внутри «черного ящика»?

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

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

Но пока ведется вся эта работа, приложение должно жить и даже меняться. Как вы этим управляете?

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

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