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

В 1987 году окончил МАДИ, а в 1990-м — аспирантуру этого же института.
В начале 90-х занимался самостоятельной разработкой и внедрением бухгалтерских программ, являлся автором популярной в то время бухгалтерской программы «Авансы и долги».
С 1996-го по 2001-й работал в Германии сначала программистом, а затем руководителем команды программистов, занимался разработкой корпоративных информационных систем.
С 2001 по 2005 год возглавлял процесс разработки и внедрения корпоративной информационной системы в компании «Вимм-Билль-Данн».
В 2005—2006 годах был руководителем управления разработки и внедрения информационных систем в «Норильском Никеле».
С конца 2006-го является директором управления информационных технологий в группе компаний «Виктория».

Intelligent Enterprise: Вы пришли в компанию «Виктория» совсем недавно. С какими проблемами пришлось столкнуться?

Дмитрий Сорокин: Задачи, вставшие передо мной как ИТ-директором группы компаний «Виктория», в общем вполне типичны хотя бы потому, что касаются, наверное, самого популярного и злободневного вопроса внедрения ERP-систем. Информационная поддержка бизнеса у нас основывалась, да и сейчас осуществляется на базе Microsoft Axapta, в развертывании которой были тем не менее допущены определенные ошибки. Это прежде всего потеря контроля за развитием системы уже в период ее промышленной эксплуатации. Axapta использовалась в качестве конструктора бизнес-приложений, что вообще для данной системы является совершенно нормальной, если не сказать необходимой практикой. Однако беда была в том, что процессами происходящих изменений в целом никто не управлял. Когда проводились одни изменения, сводилась на нет работа других, по сути существовало несколько региональных версий системы, и единой архитектуры не было вообще. Мы ввели понятие релизов, версионности изменений, ужесточили процесс их документирования, словом, попытались упорядочить контроль над всем этим процессом. Но время было упущено, и стало ясно, что надо предпринимать более кардинальные шаги. То есть фактически внедрять Axapta заново или, раз уж мы вынуждены начинать все с чистого листа, развертывать на предприятии иную систему, а если окажется целесообразным, то, может, и создавать собственную. Я считаю, что все варианты были нами проработаны весьма тщательно и беспристрастно, в результате чего мы остановились на системе SAP.

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

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

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

Можно, конечно, поставить вопрос о выборе системы в несколько иной плоскости, предположив, что вариант корпоративных разработок по определению хуже воспринимается бизнесом. Дескать, ему гораздо ближе готовая ERP-система, тем более опробованная в компаниях аналогичного профиля, нежели «чистые» технологии и инструменты разработки, на основе которых еще нужно будет что-то создавать. Может, это отчасти и так, тем более что бизнес и не должен разбираться в технологиях. Однако бизнес бизнесу рознь. Могу сказать, что розничная торговля весьма прагматична. Дело в том, что в некоторых наших отраслях, предприятия которых значимы даже в мировых масштабах, существуют некие амбиции абсолютных лидеров. Условно говоря, здесь считают, что их бизнесу подходит всё только самое известное и самое лучшее. Все это накладывает отпечаток и на выбор информационных систем. Так вот, в отличие от данной ситуации отечественная розница прекрасно понимает, что сейчас по оборотам она во многие разы отстает от мировых лидеров своего сегмента. Поэтому бизнес здесь, объективно сознавая это отставание, готов без излишних амбиций впитывать лучшую практику автоматизации, которая будет тем полезнее, чем больше будет сокращаться указанный разрыв. Подход здесь предельно прагматичен, с порога ничего не отвергается, и можно рассматривать любые взвешенные предложения. Кроме того, по вопросам стратегии развития ИТ в компании, выбора корпоративной информационной системы и целесообразности проведения самостоятельных разработок мы консультировались с очень известными фирмами, которые имеют авторитет не только в кругах, близких к информационным технологиям, но и в бизнес-среде. Речь идет, в частности, о Gartner и IBM.

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

То есть получается, что если при выборе системы пытаться заглянуть как можно дальше вперед, то вопрос выбора между собственной разработкой и внедрением тиражной системы не так полярен, как он сейчас воспринимается большинством специалистов?

Да, в общем так оно и есть. Давайте более детально обрисуем те типичные вопросы, о которых неминуемо должны задумываться сотрудники, ответственные за выбор стратегии автоматизации. Рассматривая ближайшую перспективу, все понимают, что если пойти по пути разработки, то практически все нужно будет начинать с нуля. И это очень многих пугает, что в общем вполне оправданно. В случае выбора тиражного продукта подобная ситуация сложиться никак не может, однако если заглянуть чуть дальше, то мы увидим, что после внедрения любой системы неминуемо начинается процесс ее изменения. И этот второй этап, который по сути носит перманентный характер, как раз и является более важным для бизнеса. С его началом принципиальная разница между собственной (или, скажем, заказной) разработкой и тиражной системой заканчивается. А если изначально было решено опираться на тиражную систему, то на втором этапе многое должно измениться, и это касается буквально всего: организационных принципов проведения работ, взгляда на внедряемую систему с точки зрения заложенного в ней технологического потенциала, понимания ее возможностей, наконец.

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

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

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

Как известно, любая современная ERP-система, с одной стороны, включает в себя набор готовых функциональных модулей и возможностей по их настройке, а с другой — встроенный инструментарий разработки. Значимость последнего никак нельзя недооценивать. Я, например, с ходу и не могу назвать больших, успешных и при этом уже длительное время развивающихся внедрений, где вообще ничего не дорабатывалось бы. Иногда, конечно, удается добиваться эффекта и настройками, но при этом надо иметь в виду, что в ряде случаев получить адекватное бизнес-задачам надежное и непротиворечивое решение здесь удаётся усилиями ничуть не меньшими, чем в случае разработки. К тому же я как человек, длительное время посвятивший себя именно корпоративным разработкам, смотрю, скажем, на систему SAP несколько иначе, чем многие мои коллеги. Я рассматриваю ее как платформу для создания фактически любых функций автоматизации бизнеса. Более того, она представляется мне вполне самостоятельным продуктом, который в принципе можно было бы продвигать на рынке отдельно от базового функционала ERP-системы. Думаю также, что если бы компания SAP делала это, то корпоративных клиентов у нее было бы даже больше, чем сейчас. Конечно, мои рассуждения скорее гипотетические: я понимаю, насколько важно с коммерческой точки зрения (по крайней мере на сегодняшний день) для такой компании, как SAP, представать перед корпоративными пользователями именно в качестве производителя мощной тиражной системы поддержки бизнес-процессов, тем более что вся история и весь авторитет этой компании как раз и связаны с данным направлением. По той же причине и маркетинговые ресурсы здесь в значительно большей степени работают на пропаганду именно тиражных решений. Понятно также, какие усилия в SAP отвлекаются на то, чтобы поддерживать преемственность и совместимость версий тиражных продуктов. Однако несмотря на это мне все равно кажется очень важной оценка возможностей встроенных средств разработки той или иной компании, которые теперь всё больше превращаются в платформы, содержащие мощные серверы приложений, пресловутую логику оркестровки, системы обмена сообщениями и прочие разнообразные сервисы.

Проблема автоматизации предприятия с точки зрения технологий тоже, кстати, наталкивает на мысль, что два обсуждаемых нами подхода — внедрение тиражной системы и разработка собственной — оказываются не столь уж полярными по сути. Разница между ними скорее обусловлена существующим технологическим уровнем. Средства разработки, скажем та же Microsoft .NET, сегодня уже достаточно мощны и к тому же весьма активно совершенствуются. Но пока они не достигли такого уровня, чтобы можно было говорить о быстром создании с их помощью того самого базового слоя автоматизации, который на сегодня реализуется тиражными системами, что в свою очередь фактически позволяло бы избежать начала работ с нулевой отметки. Поставщики же тиражных систем, как мы сказали, объективно вынуждены тратить львиную долю своего технического и маркетингового потенциала отнюдь не на развитие инструментальных средств. Вместе с тем некоторые инициативы по созданию сред разработки с весьма мощными заранее созданными объектами, отражающими функции, которые характерны именно для систем корпоративного управления, уже появляются. Есть они, скажем, у той же Microsoft. В любом случае их использование — дело, конечно, не завтрашнего дня, но сама тенденция к сближению тиражных систем и средств разработки все-таки имеет место. Я думаю, все заметные на рынке вендоры понимают роль инструментальных средств, какой бы маркетинговой тактики они в данный момент ни придерживались.

Вам как-то удалось уже применить все те тезисы, о которых вы говорили, в вашем собственном корпоративном проекте?

Проект у нас практически в начальной стадии, поэтому многое нам еще предстоит использовать, но по мере продвижения работ мы действительно стараемся опираться на все эти тезисы. Как я уже отмечал, были попытки разобраться с нынешним внедрением Axapta и упорядочить работу по дальнейшей ее модификации, ориентируясь на методику управления изменениями. Достичь этого не удалось в известной мере из-за того, что конфигурация системы уже к моменту моего прихода была крайне сложной, противоречивой и плохо документированной. Это еще раз доказывает, что во время эксплуатации при проведении многочисленных изменений (а это объективно необходимо и запрещать их ни в коем случае не следует) нельзя выпускать систему из рук, условно говоря, ни на один день. Мгновенно рождается хаос, и потом с накопившимися изменениями можно просто не справиться.

Что касается нынешнего внедрения SAP, то мы взяли за основу преднастроенное решение novaRetail, созданное компанией CIBER Novasoft на базе отраслевого пакета для розничной торговли SAP for Retail. Но не потому, что это решение отраслевое и в нем якобы учтены все особенности розничного бизнеса, что в свою очередь позволяло бы полностью покрыть и наши потребности в автоматизации. Выбрали мы его для того, чтобы как можно быстрее и с меньшей затратой собственных ресурсов перейти все к той же стадии непрерывного развития решения, которая, еще раз подчеркну, является ключевой для бизнеса. Развернув функционал преднастроенного решения, можно уже объективно сравнить, что мы имеем в данной конфигурации, что в ней удовлетворяет требованиям нашего бизнеса, а что нет, как реализованы в готовой системе те или иные процессы и т. д. Соответственно после этого легче предпринимать целенаправленные действия по изменениям.

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

Если мы изначально очень четко ориентируемся на управление изменениями и на модификацию системы в процессе эксплуатации, отражается ли это каким-то образом на самом проекте по внедрению базового функционала, или дело только в том, чтобы параллельно обеспечить подготовку к управлению этими изменениями?

В принципе отражается. По сути все, о чем я говорил выше, можно более просто выразить в виде некоего кредо: систему менять необходимо всегда, но делать это лучше тогда, когда она уже работает. Из этого мы и исходим. Теперь посмотрим, какая ситуация очень часто имеет место на практике. В компанию N приходят бизнес-консультанты и начинают обследование ее деятельности. Эта работа может затянуться на несколько месяцев, после чего консультанты говорят, что внедряемую систему X необходимо адаптировать под имеющиеся на предприятии бизнес-процессы, и еще в течение полугода создают технический проект. За это время бизнес очень сильно изменился, и надо, условно говоря, начинать проект по изменению существующего технического проекта. В конце концов всем это надоедает, и за основу принимается какой-то текущий вариант. Начинается внедрение, но опять-таки не в соответствии с текущими требованиями бизнеса, а в соответствии с каким-то вариантом технического проекта, на котором остановились. И это уже не говоря о том, что бизнес в процессе внедрения тоже продолжает меняться.

Против такого по сути классического подхода я всегда возражал и в нашем случае систему SAP никогда таким образом внедрять не стал бы. У нас отсутствует этап предварительного обследования. Вместо этого мы изучили то самое преднастроенное под бизнес розничной торговли решение и затем, выделив дельту, которая отличает его от требований нашего бизнеса, сформировали самый короткий список необходимых нам изменений. Это потребовало около двух месяцев работы, включая обучение проектной команды по освоению функ­циональности novaRetail. Более того, мы пошли на серьезные изменения собственного бизнеса под систему, ограничившись изменениями лишь в тех процессах, которые, как мы считаем, обеспечивают нам преимущества перед конкурентами. Такой подход позволит нам закончить проект по внедрению ERP-системы буквально за несколько месяцев при объективно необходимом (хотя, быть может, и не полном) соответствии функций системы текущим требованиям бизнеса. К моменту же начала промышленной эксплуатации, как я уже говорил, будет запущен процесс управления изменениями системы, что позволит скоординировано и целенаправленно изменять систему в соответствии с возникающими у бизнеса требованиями, приоритетами и необходимыми ресурсами. Такой подход обеспечит нам не только успешное завершение проекта внедрения, но и плодотворное использование информационной системы SAP в группе компаний «Виктория» в будущем.