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

Игорь Кульган родился 17 июня 1968 года. Закончил физический факультет МГУ и Академию Народного Хозяйства при Правительстве РФ. Работал руководитель ИТ в российском отделении PricewaterhouseCoopers, генеральным директором независимого издательства "ИнфоАрт", генеральным директором компании Exteria, генеральным директором компании EPAM Systems, директором по ИТ компании ЕвроХим (Группа МДМ). Последние два года — директор по управлению бизнес-процессами и информационными системами холдинга "РусПромАвто". С 1 сентября 2005 года назначен директором дивизиона "Двигатели" объединяющего пять заводов холдинга "РусПромАвто".

Intelligent Enterprise: Давайте начнем разговор об оптимизации процессов с самой, пожалуй, сложной для производственных предприятий области - производственных планов. Каким образом организовано производственное планирование в вашем холдинге, и какие требования здесь предъявляются к ИТ-системам?

Игорь Кульган: В автомобильной отрасли известны различные модели планирования, в том числе принципиально разные подходы "Ниссана" и "Тойоты". Одни делают ставку на автоматизацию, роботизацию, другие - на творчество людей, оптимизацию этой составляющей. В частности, в компании "Тойота" считают, что любой процесс, вложенный в систему автоматизации класса ERP, становится окостенелым, застывшим, трудно изменяемым. И уж точно такая система никогда не предложит, как его оптимизировать. Если же система состоит из людей, а не из компьютеров, то при правильном подходе они будут ее модернизировать и улучшать. Это основная их концепция. По этому поводу есть достаточно много литературы. Ключевой термин такого подхода - "бережливое" производство, хотя это не совсем точный перевод английского термина "lean". Суть в том, чтобы уйти от массового производства, основы которого заложил еще Форд, и перейти к производству "в одну деталь", "точно вовремя", в полном соответствии с заказом. В результате производится не 1000 машин на склад, а одна машина сейчас - та, которую немедленно заберет заказчик. Это ломает все исторически сложившиеся подходы.

У нас в России издавна делались попытки оптимизировать оборудование и людей. Считалось, что станок должен работать максимальное время, и человек был бы занят максимальное время. Это приводило и до сих пор приводит к огромному незавершенному производству, очень долгим срокам выполнения заказа, проблемам с качеством. Покупали станок, который штампует миллион банок одним ударом, ведь себестоимость одной банки при такой штамповке очень низкая. А если учесть, что нужно было собрать миллион банок здесь, миллион - в другом месте, организовать транспортировку, то в итоге время прохождения получается просто огромным. Если считать по итоговой стоимости, лучше поставить пресс, штампующий по одной банке.

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

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

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

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

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

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

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

Вообще говоря, все это имеет к ИТ косвенное отношение. Почему же вы, будучи ИТ-директором, занимаетесь этим?

Все из-за процессов (кстати, в русском написании моей должности есть слова "управление бизнес-процессами", и это принципиальный момент с точки зрения трансформации роли ИТ-директоров).

Просто описывать бизнес-процесс - примитивно и бесполезно. Фиксировать положение "как есть" неинтересно, цель описания - оптимизация. Когда я брался за эту работу, мной двигал в первую очередь интерес к оптимизации процессов. Есть разные критерии и методы для этого. У нас теперь определен главный метод, у нас "одна религия" - бережливое производство. Хотя мы говорим только о производстве, но изменяться, причем принципиально, и финансы, и снабжение, и сбыт. Например, нам будет выгоден не тот клиент, который берет сразу 1000 машин, а тот, кто заказывает ежемесячно по 30 штук в течение 35 месяцев.

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

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

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

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

У нас в "РусПромАвто" дивизиональная структура. Это означает, что именно дивизион - центр ответственности и центр компетенции по основным направлениям деятельности. Обычно это одно или несколько предприятий, торговый дом и вспомогательные подразделения. При этом логично ожидать, что структура будет матричной, когда каждый дивизион имеет своих финансистов, сбытовиков и пр., но все они подчиняются и функциональному руководителю в управляющей компании. В силу исторических причин на постсоветских предприятиях очень тяжело смириться с этой "перекрестной" структурой управления, когда есть прямое подчинение и функциональное. Человек знает, кто у него начальник, его и слушает, а всех остальных - только до тех пор, пока не иссякнет его "добрая воля". Однако в ИТ ситуация другая: так как директора заводов об ИТ знают мало, они готовы ответственность за эту сферу передать кому-то другому. Вот финансы они не отдадут, производство тем более, а отвечать за сбои в ИТ им совсем не хочется. Подчиненных у меня, как у ИТ-директора холдинга, немного, всего 15 человек. Раньше было еще меньше, но сейчас сотрудники набраны именно для того, чтобы усилить функциональную составляющую ИТ в матричной структуре. Мы должны стать центром компетенции для всех остальных ИТ-менеджеров холдинга. Как внедрять то или иное решение? Что приоритетно? Как строить стратегию? Именно на эти вопросы нужно отвечать. Все директора по ИТ предприятий мне функционально подчинены, так что хотя в прямом подчинении людей немного, реально я распоряжаюсь тысячами сотрудников, занятых в ИТ-подразделениях заводов, могу перебрасывать ресурсы и координировать общую работу.

Лучшие практики передаются следующим образом. У нас есть центры компетенции по определенным направлениям. Если вопрос по ERP - тут, конечно, нужно обращаться на "УралАЗ". Но это не значит, что везде нужно внедрять BAAN, как на этом заводе. Но во всех вопросах, связанных с ERP, "УралАЗ" поможет разобраться. Важно, чтобы для него самого это не было обузой. Затем и нужен комплекс административных и организационных решений, которые мы сейчас и реализуем. Есть центры компетенции и по другим направлениям. Постепенно вся эта деятельность систематизируется.

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

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

Вы не считаете нужным централизовать закупки?

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

Что касается возможной экономии на объеме закупок, тут соображения следующие. На сколько снизит цену вендор, если мы придем к нему с большим заказом? Ну, процентов на двадцать. На сколько "упадут" в цене интеграторы - участники тендеров, когда они демпингуют друг перед другом? В разы. Вот и весь расчет.

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

Каковы с вашей точки зрения факторы успешности проекта? Как вы добиваетесь успеха?

Прежде всего, проект должен быть хорошо подготовлен. Мне очень нравится "правило А3", которое есть у "Тойоты". Любой проект, от закупки шкафа до сложной техники, должен излагаться на листе формата А3. Если больше - то не читается и отправляется на доработку. На листе А3 есть шесть зон, по три с каждой стороны.

1. Формулировка проблемы. Что вы собираетесь решать? Уже на этом этапе часто возникают сложности.

2. Альтернативные варианты решения. Они всегда есть. Если нет хотя бы трех, ищите дальше.

3. Экономический эффект, если есть, или какое-либо другое обоснование. Когда начинается какой-то проект, он должен иметь несколько категорий обоснований. Примерами таких категорий являются: безусловное выживание бизнеса, сохранение конкурентоспособности, повышение управляемости компании. Мы все время пытаемся так вести дело, чтобы проект имел экономическую эффективность. Но если ее нет - не надо ее придумывать. Например, если строите систему видеонаблюдения на заводе, не надо писать в обосновании, что после этого воровство исчезнет на 100%, и давать эту цифру как экономический эффект. Мы стараемся подобные искусственные категории не придумывать.

4. Укрупненный план проекта.

5. Стоимость проекта.

6. Вехи, ключевые точки и результаты в них.

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

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