Toyota Motorsport разрабатывает автомобили для «Формулы-1» и готовит их к этим гонкам. Многие ИТ-проблемы, уже давно решаемые здесь, сейчас остро встают и перед российскими компаниями. Старший ИТ-менеджер Toyota Motorsport Вальдемар Клемм касался подобных проблем в своем выступлении на осеннем московском форуме «IT-Лидер». Сразу после доклада мы решили поговорить с г-ном Клеммом на эту тему более подробно.

Вальдемар Клемм (Waldemar Klemm) закончил курс чистой математики в университете г. Гейдельберга и получил стипендию от корпорации IBM, где участвовал в реализации нескольких успешных проектов по созданию и оптимизации ИТ-инфраструктур.
По завершении обучения г-н Клемм работал в нескольких ИТ-компаниях и фирмах инжиниринговых услуг, специализировавшихся на САПР/АСУ, технических расчетах и моделировании.
В компании Toyota он отвечает за внедрение ИТ (инфраструктуры, программного и аппаратного обеспечения) в рамках всего проекта «Формула 1».
В компании Toyota Motorsport Вальдемар Клемм работает с 1999 года. В настоящее время занимает должность старшего управляющего по вопросам ИТ.

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

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

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

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

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

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

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

Давайте начнем с CAD-системы. За чертежом каждой детали, за каждым ее объектом стоит некая модель, в которой в свою очередь содержится информация, связанная с тем, как мы управляем ее производством и затем сборочными операциями. Наряду с чертежами здесь по сути рождается спецификация изделия (Bill of Materials, BOM. — Прим. ред.), представляющая собой, как известно, важнейшее понятие большинства производственных бизнес-процессов. Эту же спецификацию можно и нужно активно использовать в SAP для ИТ-поддержки тесно связанных с производством бизнес-процессов — закупок, учета, логистики и пр.

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

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

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

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

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

Самостоятельно мы производим около 80 процентов комплектующих для наших автомобилей. Однако есть узлы, которые нам самим производить нецелесообразно. Например, это относится к отливкам блоков цилиндров, которые поставляются нам с предприятий-партнеров. Разумеется, в данном случае необходимо делать заказы и управлять поставками, что можно и нужно выполнять с помощью системы SAP. Однако прежде чем что-то поставить, надо договориться, чту именно мы должны изготовить, и здесь снова приходится сфокусироваться на системах поддержки проектирования и управления жизненным циклом изделия. Речь, разумеется, идет о взаимодействии в рамках совместной работы над его цифровой моделью. Не менее активно используем мы и модуль контроля модели изделия (model checker.— Прим. ред.), позволяющий тщательно проверить все параметры сопряжения изготавливаемого нашим партнером компонента с конструкцией автомобиля. Подобные работы можно в качестве своего рода пилотного проекта вести с одним внешним поставщиком, а затем расширить на других партнеров. В общем, для нас взаимодействие с поставщиками в значительной мере опять-таки сводится к применению производственных систем.

Большой интерес у нас в стране сейчас вызывают вопросы стандартизации обмена информацией с партнерами по бизнесу. Как в этом отношении строится работа у вас?

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

Поэтому сейчас в любом случае речь идет об отраслевых стандартах и отраслевых объединениях, которые берут на себя координацию работ по распространению стандарта в тех или иных производственных сферах. Что касается нас, то мы, например, используем стандарт STEP (Standard for the Exchange of Product model data), являющийся нейтральным по отношению к спецификациям отдельных программных систем. Мы применяем его в качестве стандарта представления геометрии изделия, а также для описания ряда его параметров по всему жизненному циклу. Он, кстати, широко используется и в авиакосмической промышленности. С целью координации работ по расширению применения данной спецификации для наших задач сформировано некое отраслевое некоммерческое сообщество под названием OpenSTEP. Каждая входящая в него компания отчисляет ежегодные взносы, идущие на поддержку деятельности сообщества. Словом, организационные приемы тут в общем нехитрые, но они как раз и оказываются наиболее эффективными. Это, разумеется, касается не только спецификации STEP.

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

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

Явные очертания бюджетного подхода к планированию ИТ-решений и принципиальная ограниченность бюджета тесно связаны, в свою очередь, с проблемами баланса вложений в инновации и поддержку. И здесь определять политику может и должен сам ИТ-отдел. К примеру, на работу службы HelpDesk — типичного направления, связанного с поддержкой, у нас расходуется около 8 процентов от бюджета, на инновации около 20 процентов, на организацию систем хранения — порядка трети ИТ-бюждета. Последнее направление очень показательно в смысле разделения ИТ-бюджета на две обсуждаемые нами составляющие. Как видим, оно довольно емкое в плане расходования средств, но мы все равно стараемся использовать здесь самые передовые технологии. И это при том, что ИТ-инновации для нас исключительно важны, а технологии хранения данных — это все же в основном ИТ-поддержка. Почему так? Да прежде всего потому, что при грамотном подходе к их развитию в перспективе можно будет сэкономить, да еще и выиграть в качестве. А высвободившуюся часть бюджета направить на инновации. ИТ-иннновации, еще раз подчеркну, жизненно важны для нашего бизнеса, и я это хорошо знаю уже не как CIO, а как бизнес-менеджер.

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

Идеи, заложенные в технологию ILM (Information Lifecycle Management. — Прим. ред.), вроде бы не новы и вполне прозрачны, так что поначалу можно подумать, что здесь всё внедряется очень просто, были бы средства. Вместе с тем наш опыт показывает, что эффективному ее использованию должны непременно способствовать четкие правила работы с информацией. Особо подчеркну это слово — «четкие», поскольку понимать, что часто используемую информацию надо всегда иметь под рукой, а редко используемую можно сохранять на более медленных и дешевых носителях, здесь явно недостаточно. Каждый заезд нашего болида связан с генерацией огромного количества информации, снимаемой с различных датчиков. Объем этой информации огромен, и история её изменения тоже важна. Всесторонне проанализировав ситуацию, мы пришли к выводу, что для оперативного доступа нам нужны результаты трех заездов — не больше и не меньше. И подобный подход необходим при решении еще очень многих вопросов, прежде чем переходить непосредственно к технологиям ILM.

Еще в связи с данной концепцией хотелось бы выделить задачи обработки неструктурированной информации. Проблема в том, что ее не только труднее классифицировать (а стало быть, и адекватно хранить), чем структурированную. Это в общем широко известно. С ней труднее работать и в историческом аспекте. По прошествии времени зачастую вовсе не обязательно заново перечитывать массу документов и внимательно просматривать какие-то презентационные материалы. Иногда куда важнее на основании всего этого массива быстро составить объективное впечатление о том, какие проблемы стояли на момент создания этих документов и каким образом они решались. Здесь к известным проблемам организации иерархических систем хранения сразу добавляются чисто программные, алгоритмические, логические проблемы обработки неструктурированного контента, установления связи между отдель­ными его элементами. И нам еще предстоит решить многие из них.
И все же, как вы правильно отметили, мы являемся, пожалуй, одними из самых опытных клиентов в отношении использования ILM. Здесь мы изначально полагались на решения корпорации EMC, став около трех лет назад едва ли не первыми клиентами этой компании по данным технологиям. Впрочем, сотрудничество с ней мы успешно развиваем по сей день.