Евгений Ерофеев, "ФТД Царицыно" : Децентрализация - основа устойчивости.

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

Intelligent Enterprise: Если говорить о развитии бизнеса вашей компании, какие особенно важные моменты вы бы здесь выделили?

Евгений Ерофеев: Безусловно, бизнес у нас весьма заметно развивается в количественном отношении. Но тут, я думаю, мы в нашей стране не уникальны. Более интересна наша ситуация в отношении качественной составляющей развития. История мясокомбината "Царицыно" насчитывает уже 35 лет, и большую часть этого времени мы существовали, по сути, в форме единственного производственного предприятия. В последнее время мы представляем собой группу предприятий, среди которых теперь есть и чисто торговые компании, являющиеся дочерними по отношению к основной. Мы также приобрели мясоперерабатывающее предприятие в Щелково, и теперь даже производственная площадка у нас, по сути, имеет распределенную структуру. Все перечисленное я сознательно отношу именно к качественному развитию бизнеса, поскольку встающие при этом проблемы его автоматизации часто необходимо решать именно на качественно новом уровне.

Особо отмечу наш новый проект. Мы сейчас очень серьезно развиваем совершенно новое для себя логистическое направление. Причем развиваем не только (а может, и не столько) как вспомогательное к основному нашему бизнесу, а именно как один из основных коммерчески важных для нас видов деятельности. То есть "Царицыно" будет предоставлять на рынке профессиональные услуги независимой логистики третьим фирмам.

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

Какие конкретные проблемы автоматизации, тесно связанные с развитием бизнеса, вы могли бы назвать?

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается нашего предприятия, то у нас учет затрат на производстве и соответственно расчет себестоимости ведется в системе Baan IV. Это очень сложный функционал, и я думаю, что в отношении его использования мы как раз продвинулись весьма далеко. Но есть и всегда останутся те участки на производстве, где функции Baan просто не нужны. Такие участки будут автоматизироваться посредством собственных программных продуктов. Как я уже говорил, при всей имеющейся у нас богатой инфраструктуре для автоматизации склада мы внедряем Axapta. Это тоже иллюстрация практикуемого нами децентрализованного подхода.

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

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

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

Мы в целом ориентируемся на приобретение недешевого оборудования, которое первоначально может поставляться и в самой минимальной комплектации. Так, оборудование, купленное нами еще в 1999 году, неоднократно модернизировалось и успешно работает до сих пор. Далее мы придерживаемся простого правила, что если используется линейка оборудования одного производителя, то ее надо по возможности продолжать использовать. Например, в связи с масштабным проектом по внедрению Baan IV у нас в свое время сформировался парк техники на платформе Sun. Сейчас многие серверы можно заменить более дешевыми, казалось бы, серверами Intel. Однако по совокупной стоимости перехода такой шаг окажется невыгодным для компании.

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

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