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

Родился в 1958 году. В 1981­м закончил Московский физико­технический институт, а в 1984­м — аспирантуру МФТИ.
С 1996 по 1999 гг. — инженер­программист ОАО «Царицыно».
С 1999 по 2000 гг. — заместитель начальника отдела информационно­ вычислительных систем ОАО «Царицыно», а с 2000 по 2005 гг. – начальник этого отдела.
В 2000—2002 гг. руководил внедрением ERP­системы BAAN IV на Царицынском мясокомбинате.
С 2005 по 2006 гг. — начальник отдела информационного обеспечения ОАО «Фирменный Торговый Дом Царицыно». В 2005—2007 гг. руководил проектом внедрения ERP­системы Microsoft Dynamics AX (Axapta) в логистическом центре компании.
В настоящее время — заместитель генерального директора по информационным технологиям.
Женат, имеет двоих детей.

 

Intelligent Enterprise: Сейчас бизнес вашей компании существенно диверсифицируется. Как это отражается на деятельности ИТ­департамента?

Евгений Ерофеев: Акцент на диверсификацию бизнеса у нас действительно очень существенен, и здесь, наверное, надо пояснить, о каких масштабах преобразования идет речь. Дело в том, что некоторые «ответвления» от основной деятельности, связанной с производством мясной продукции, сущест­вовали и раньше. У нас, например, имеется звероферма по выработке ценной пушнины, а также хлебопекарное производство. Сейчас же, говоря о том, что наша компания активно инвестирует независимый логистический бизнес, способный предоставлять сторонним заказчикам услуги конкурентоспособного уровня, мы имеем в виду качественно новую ситуацию. В том числе и для подразделения информационных технологий.

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

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

И наконец, ситуация со взаимопроникновением задач ИТ и бизнеса усложнятся из­за того, что его автоматизация сейчас всё в большей степени строится на базе различных информационных систем. Это часто относится даже к бизнесу, развивающемуся в каком­то одном направлении, а уж в случае диверсификации — тем более справедливо.

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

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

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

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

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

Да, неоднозначность толкования имеет место. В отношении имитационного моделирования не могу не признать пользы подобных решений, и не в последнюю очередь это касается нового для нас логистического направления. В частности, в системе GMCS Cargо Terminal, которая внедрена в нашем торговом доме, мы намерены практиковать имитационное моделирование для того, чтобы выяснить, например, возможность заполнения какого­либо транспорта дополнительным грузом. Делать подобные расчеты вручную не слишком эффективно. Я думаю, что такие задачи придётся решать и в будущем. Но в любом случае прежде чем проводить имитационное моделирование, нужно иметь ясность с бизнес­процессами. Поэтому их моделирование первично и безусловно является более важной задачей. Именно ее решение в отличие от имитационного моделирования позволяет не просто виртуально сконструировать какой­то отдельный участок процесса и оценить его функционирование, но и «прощупать» возможности развития всего бизнеса в целом со всеми его внутренними взаимосвязями.

А что в таком случае вы могли бы сказать по поводу инструментов моделирования бизнес­процесов? Всегда ли эти средства целесообразно применять?

Тут уместнее было бы говорить не столько об инструментах, сколько о методологиях. С моей точки зрения давно известные стандарты серии IDEF в данном случае являются оптимальными. Они просты в использовании, и это серьезное их преимущество. Кроме того, они служат основой для наших ГОСТов 34­й серии, что тоже немаловажно. То, что ассоциируемые с данным стандартом средства моделирования не столь популярны на российском рынке, — скорее результат слабой активности поставщиков, нежели следствие недостатков самих программных средств. Что касается, например, ныне популярного средства ARIS, то это все­таки довольно сложный инструмент, под который надо специально держать бизнес­аналитиков.

Ключевой нюанс применения средств информационной поддержки моделирования (да и моделирования вообще) состоит в том, что из чисто практических соображений детализация моделей не должна быть слишком подробной. Иначе даже при наличии ИТ­поддержки будет очень трудно двигаться вперед. В случае интенсивных и значительных изменений бизнес­процессов единст­венный выход — отслеживать только значимые изменения, не уходя в моделях чересчур глубоко. Говоря более профессиональным языком, я имею в виду уровень декомпозиции бизнес­процессов, который, на мой взгляд, вряд ли должен быть выше пятого. Лучше всего, если вообще можно ограничиться вложенностью третьего уровня при условии, что при этом удастся захватить около восьмидесяти процентов проблем, связанных с бизнес­процессами.

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

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

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

Если же говорить о программной поддержке более конкретно, то критерием выбора для нас в подобной ситуации явилась универсальность предоставляемого сервиса и вместе с тем его расширяемость. Продукт не должен был зависеть от специфики товара, от сложившихся отношений с поставщиками и клиентами и от параметров самого склада. При этом он должен был поддерживать любые операции складской грузообработки, отражать возможности сдачи складских площадей в аренду и проч. Короче, необходимо многое из того, что может быть реализовано в будущем. В итоге для автоматизации распределительного центра мы остановились на решении GMCS Cargo Terminal на базе Microsoft Dynamics AX, которое сейчас сопрягаем с также активно используемыми у нас продуктами собственной разработки.
Иными словами, принципиально новое направление бизнеса в большинстве случаев означает освоение принципиально новых для компании подходов, технологий и продуктов в области автоматизации. И всё это надо сводить в единое информационное пространство.

Адаптация работы ИТ­подразделения к требованиям диверсифицируемого бизнеса — это еще и вопрос организационный. Известно, например, что в некоторых компаниях, где качественное расширение бизнеса также стоит на повестке дня, вводят позиции директоров или вице­президентов по бизнес­процессам, подчиняя им в том числе и ИТ­отдел. Рассматриваете ли вы процесс изменения работы ИТ­подразделения в новых условиях с организационной точки зрения?

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

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

Что касается нашей компании, то сейчас подобная группа бизнес­моделирования формируется; правда, пока можно говорить скорее о неформальных механизмах взаимодействия, нежели о формальном создании какого­либо подразделения. К такой группе можно отнести директора нашей компании по логистике, руководителей отделов закупки и продаж и меня. Не могу сказать, насколько подобная группа будет выделена в качестве формальной организационной единицы впоследствии, но в содержательном аспекте ее деятельность уже сейчас обозначается всё более отчетливо.

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

Всё, о чем вы говорите, представляет собой по­настоящему сложную проблему, которую, я думаю, на сегодня вряд ли кому­то удалось решить полностью. Различие в менталитете специалистов, ориентированных на развитие и на поддержку, безусловно имеет значение, но на практике гораздо важнее и сложнее привить им необходимые технические знания, с которыми они не знакомы. Это касается и архитектуры, и СУБД, и инфраструктурных решений.

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

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

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

Помогают ли в таком случае при подготовке пользователей какие­либо технологические приемы и прибегаете ли вы к ним?

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