Славин Борис БорисовичРодился в 1962 году в Москве. Закончил физический факультет МГУ им. М.В. Ломоносова по специальности «Ядерная физика». Кандидат физико-математических наук.До 1995 года работал в Московском радиотехническом институте РАН, Научно-техническом фонде при Московском физическом обществе. Имеет публикации по компьютерному моделированию низкотемпературной плазмы. С 1995 года возглавлял ИТ-службы в фирмах «Партия», «АйТи». В декабре 2001 года приглашен в компанию «Инком-Авто». Под его руководством в компании была модернизирована ИТ-инфраструктура (телекоммуникации и телефония, структурированные кабельные системы, вычислительное оборудование), внедрены различные программы автоматизации предприятия, разработаны и внедрены собственные системы на MS SQL. Входит в совет директоров «Инком-Авто». |
Intelligent Enterprise: Борис Борисович, вы работаете в распределенной компании, а преимущества и недостатки механизмов централизованного и распределенного управления ИТ-отделом сейчас обсуждаются очень живо. Могли бы вы внести свой вклад в это обсуждение?
Борис Славин: Поддержка информационной системы компании, имеющей сеть распределенных филиалов, является частью общего вопроса управления таким предприятием. Поэтому невозможно рассматривать методы организации службы ИТ без привязки к конкретным моделям организации самого бизнеса. Существуют компании, в которых часть функций (например, финансы, поставки, взаимоотношения с регулирующими органами) централизована, а другая часть (сбыт, производство) передана филиалам. У некоторых компаний в филиалах могут быть сосредоточены все функции отдельного предприятия, а в центре только методологические и координирующие структуры. Понятно, что и архитектура ИТ-поддержки таких компаний будет отражать сложившуюся на предприятии факторизацию бизнес-функций между центром и дочерними структурами.
Кроме того, следует учитывать и географическое расположение филиалов. Так, для организации обслуживания розничной сети в одном городе, например, в Москве, можно ограничиться одним централизованным HelpDesk’ом. В случае же, когда речь идет о региональных филиалах, расположенных в различных географических зонах, сервисные службы ИТ (HelpDesk) однозначно должны быть разделены по регионам. Ведь надо понимать, что ИТ-сервис не может работать с опозданием в два-три дня, он требуется срочно, иногда в течение часа, а то и меньше.
Но даже если мы говорим о сервисной поддержке филиалов в одном городе, существуют две полярные модели. Согласно одной из них эффективность ИТ-поддержки достигается за счет использования централизованного HelpDesk’а, с единой базой обработки заявок, распределением проблем по специалистам. Данную модель можно сравнить с работой службы «скорой помощи». Но есть и другая модель, которая имеет свои преимущества. Мне она даже больше нравится. В этой модели за каждым филиалом (или «кустом» филиалов, если они не очень большие) закрепляется выделенный сотрудник ИТ-службы, что-то вроде «мини-ИТ-директора» для своих филиалов. Он полностью за них отвечает, используя централизованные ресурсы в том случае, если ему не хватает умения, знаний и пр. Такую модель я называю моделью «семейного доктора», когда ИТ-специалист полностью курирует свои филиалы во всех областях, связанных с ИТ. Какие плюсы у такой системы? Инженер поддержки, который является «семейным доктором», заинтересован в том, чтобы в них не просто все работало сейчас, но и ничего плохого не произошло в будущем, он выступает «лоббистом» интересов своего филиала перед центром. Минусом же централизованной поддержки становится то, что сегодня дежурит один сотрудник, завтра другой, послезавтра третий, и даже если специалист выезжает на место, у него нет особой заинтересованности в работе конкретного филиала. А очень важно, чтобы она была. Но у централизованной поддержки есть и плюсы: здесь нет зависимости от конкретных людей и их личностных качеств в лице тех самых «маленьких ИТ-директоров». Централизованный HelpDesk более технологичен, он позволяет проще автоматизировать деятельность самой службы ИТ-поддержки. Но я бы не стал отдавать преимущество той или иной модели — в конце концов, структура ИТ-службы отражает не только структуру управления в компании и географию расположения филиалов, но и менталитет управленческой культуры на предприятии. Выбирать надо не то, что с точки зрения теории должно быть, а то, что более эффективно.
Если говорить не только о деятельности службы поддержки HelpDesk, а об ИТ в целом, безусловно, существуют функции, которые в любом случае остаются за центральным офисом. Как минимум это стратегия развития ИТ. Даже когда компании в холдинге полностью автономны, стратегия, как правило, остается за центром. А дальше уже все зависит от того, насколько холдинг централизован. Если, допустим, управление финансами в компании централизовано, то соответственно все, что касается поддержки финансовой деятельности в ИТ-системах, тоже остается централизованным.
Еще одна функция всегда останется наряду со стратегией в ведении центрального аппарата ИТ-службы — это формирование общих регламентов и стандартов развития ИТ инфраструктуры. Иными словами, то, что можно определить понятием «стандартизация деятельности ИТ-инфраструктуры». На самом деле это тоже является частью стратегии, поскольку стратегия единой компании всегда подразумевает, что компания развивается по единым стандартам. Впрочем, и здесь бывают исключения. Есть компании, деятельность которых заключается в покупке, реформировании, увеличении стоимости и последующей продаже различных бизнесов. В таких случаях роль центральной ИТ-службы может вообще ограничиваться лишь функцией аудиторского и консультационного центра, как и роль самого управления такой компании.
Можно ли сочетать те подходы, о которых мы с вами говорили только что, в рамках деятельности ИТ-отдела одной компании?
Я бы ответил, что не только можно, но и нужно сочетать различные подходы к организации ИТ-службы. Ведь иногда мы находим там, где не ждем. Только комбинируя разные методологии организации работы, можно найти какие-то интересные решения. И надо сказать, что для ИТ-директора поиск и нахождение креативных решений в организации информационной системы, определение оптимального баланса между различными формами работы — по сути, один из самых главных моментов деятельности. Знание методологий и стандартов не отменяют творческого отношения при использовании ИТ в конкретных случаях и экспериментов в структурировании ИТ-службы.
Немногим более года назад мы были с экскурсией в Германии, где нам показывали организацию работы типичного немецкого автоцентра. Я решил узнать, как построена поддержка ИТ на таком предприятии. Автоцентр небольшой, больше похож на один из филиалов распределенной компании, но он полностью независим. Это частная собственность, которой владеет хозяин (он же и выступал в роли экскурсовода), и уже не в первом поколении. Выяснилось, что в этом автоцентре всего один человек занимается ИТ, причем уровень его как специалиста не очень высокий. Я поинтересовался, как же он справляется, ведь на предприятии довольно сложное серверное и телекоммуникационное оборудование, современное программное обеспечение. Ответ был прост: вся ИТ-поддержка находится на аутсорсинге. Техника установлена сторонними организациями, которые осуществляют поддержку в течение гарантийного срока, а затем меняют оборудование. Внедрение и работоспособность ПО также обеспечиваются со стороны. В задачу ИТ-специалиста на таком предприятии входит квалифицирование проблемы и умение ее переадресовать именно той организации, которая ее может решить. Это аутсорсинг в чистом виде, причем доведенный до своего логического конца, когда реально нет никакой ИТ-службы на предприятии. Сначала все это показалось мне очень примитивным и малоинтересным для моей практики. Но потом, когда я посмотрел на эту модель не с точки зрения данного отдельного предприятия, то понял, что любой филиал в компании, в которой я работаю, должен чувствовать себя точно так же, как этот автоцентр в Германии. В наших филиалах тоже нет выделенной ИТ-службы, а есть один универсальный специалист (модель «семейного доктора»), которому они всегда могут позвонить, и который будет решать их проблемы самостоятельно либо используя ресурсы центральных служб. По сути дела, филиал распределенной компании можно сравнить с независимой фирмой с очень большой степенью аутсорсинга. В этом случае аутсорсинг для филиалов предоставляет центральный аппарат ИТ-службы. Тогда все становится на свои места. Причем чем меньше филиал, тем больше используется аутсорсинг центрального офиса.
Вы предложили региональное разделение функций ИТ-отдела. Но ведь есть и функциональное. Так как же делить функции ИТ-отдела?
В случае поддержки ИТ-инфраструктуры небольших филиалов предпочтительнее специалисты широкого профиля. Их уровень в каждой области может быть не очень высок, но зато они могут ориентироваться во всех возникших проблемах и правильно их ранжировать. Что касается центрального офиса, здесь есть возможность иметь «узких» специалистов, профессионалов только в одной из функций ИТ. Это специалисты по вычислительной технике и телекоммуникационному оборудованию, по сетевым операционным системам и телефонии, специализированному программному обеспечению и документообороту и так далее. Центральный офис — это центр компетенций по всем ИТ-проблемам, и его структурирование должно строиться по функциональному принципу. Но здесь нужно руководствоваться не количеством функций ИТ-службы, коих может быть очень много. Например, если их 20, то это не значит, что должно быть и 20 подразделений. Я считаю, что выделять сотрудников в отдельные структуры целесообразно, если методы управления в таких подразделениях разные. Например, управление службой технической поддержки строится отлично от управления группой, которая занимается разработкой программного обеспечения. И это понятно, от технической поддержки мы требуем прежде всего качества сервиса, скорости устранения неполадок и минимизации количества сбоев, а от группы по разработке приложений мы ожидаем новых технологических прорывов, деятельность этого подразделения в большей степени носит инновационный характер. Более того, данными людьми управлять надо по-другому, на них даже «прикрикнуть» иногда нельзя. Повысишь голос, а у сотрудника пропадет желание работать, и он не найдет тот верный алгоритм, без которого потом ничего не «склеится». Особую группу составляют специалисты, управляющие проектами, — projeсt-менеджеры. Они, как спортсмены, заточены прежде всего на работу в жестких временных и бюджетных рамках. Это особая категория специалистов, которых не стоит смешивать с другими сотрудниками ИТ-службы.
Но, вообще говоря, я против того, чтобы вырабатывать универсальные рекомендации по структурированию ИТ-службы. Нет одной модели, которая бы подошла всем, поскольку у каждого предприятия имеются свои особенности, своя стратегия развития ИТ. Одна компания в данный момент много вкладывает в разработку ПО собственными силами, отдел разработки может даже превышать по размеру все другие ИТ-подразделения и требовать особой глубокой структуризации (с выделением отдельных архитекторов ПО, отделов тестирования и т. п.). Другая компания, наоборот, больше инвестирует во внедрения сторонних продуктов — здесь особую роль приобретают именно менеджеры проектов. Третья считает, что на данном этапе вообще инвестиции в инновации надо уменьшить, и тогда на первый план выходят техническая поддержка и минимизация расходов. У каждой компании есть свои приоритеты на каждом этапе, и поэтому роль подразделений ИТ службы может меняться, как, в общем, и вся ее структура.
Насколько важно рассматривать технологические варианты решений для случаев централизованного и распределенного бизнеса, имея в виду как базовые, так и прикладные системы?
Это очень важный вопрос, от него, в конце концов, зависит качество всей информационной системы. ИТ-решения можно считать эффективными настолько, насколько их использование соответствует бизнесу компании. Можно привести немало примеров, когда необдуманное увлечение внедрениями ERP-систем порождало в компаниях многочисленные проблемы. Дело в том, что архитектура ERP-решений заведомо предполагает, что вы строите централизованную, высокоинтегрированную систему. Но часто бизнесу это может быть противопоказано. Допустим, у вас финансовый учет и управление закупками централизованы, а сбыт или производство базируются в филиалах; то есть операционная деятельность осуществляется в филиалах, управленческий учет — в центре. В таких условиях при внедрении стандартной ERP-системы имеется два выхода. Либо надо эту систему «сломать», «поделить на куски», а потом уже отдельные модули системы внедрять в филиалах и центральном офисе, нарушая тем самым архитектуру ERP. Либо организовывать работу филиалов в единой централизованной базе данных, что может сделать неустойчивой работу всей информационной системы, поскольку бизнес сам по себе децентрализован. Что произойдет, например, в случае длительного отключения электричества в центральном офисе — все филиалы перестанут работать!
Если бизнес филиала может развиваться самостоятельно, значит, он должен быть полностью автономным и с точки зрения используемого ПО. Конечно, когда мы говорим о компании, предоставляющей услуги за счет единой обработки информации, централизованная система оправдана. Например, в компании, распространяющей билеты на авиарейсы, в филиалах не могут продавать билеты, если не работает центральный офис. И это не вызывает возражений, так как иначе есть вероятность, что на одно место посадят несколько человек. Но если мы говорим о торговой сети, то магазин должен уметь работать независимо от центрального офиса, пусть даже на офис бомба упадет. Бизнес так построен. Магазинам, сервисным центрам не нужен центральный офис для оперативной деятельности, они могут и должны работать автономно. Если бизнес может так функционировать, значит, и информационная система должна функционировать точно так же. Выбор ИТ должен основываться на архитектуре бизнеса, а не на том, что в данный момент модно в ИТ-индустрии.
Как строится взаимодействие ИТ-отдела с пользователями на этапе выбора и внедрения ключевого для бизнеса ПО (в отличие от аналогичного взаимодействия на этапе непрерывной поддержки решения)?
Раньше я считал, что программный продукт, который мной выбран, самый лучший. И все должны мне подчиниться в этом выборе и делать то, что я считаю нужным. Но тогда я был молодой, и опыта было мало. Сейчас у меня другая позиция — уверен, что в выборе информационной системы обязательно должны участвовать ключевые пользователи от бизнеса. ИТ-директор должен выступать в роли консультанта и помощника, его задача — не дать пройти заведомо неправильным решениям или решениям, которые будут мешать внедрению систем в других подразделениях компании. Но бизнес-пользователю обязательно надо дать сделать выбор. Зачем? Дело в том, что ключевые пользователи должны участвовать во внедрении наряду со специалистами ИТ-службы, и даже более того — брать на себя всю ответственность за результат внедрения новых технологий. Тогда преимуществом будет не только успех внедрения ИТ-решения, но и качество внедренного продукта. У нас, когда идет проект, ресурсы ИТ-службы задействованы ровно настолько, насколько они необходимы в качестве квалифицированной помощи, реально же внедряют те люди, у которых это ПО будут использовать. Очень хорошая параллель — MS Office. Мы ведь никогда не говорим о внедрении данного ПО. Мы его ставим, а люди сами выясняют, как им пользоваться и что нужно делать, если надо — обращаются за советами. Пользователи вполне успешно уживаются с этим продуктом, потому что в нем заинтересованы, никто не заставляет их с ним работать насильно. То же самое должно быть и со специализированным программным обеспечением. Чтобы бизнес-пользователи поняли, что программа необходима прежде всего им самим, они должны участвовать как в ее выборе, так и во внедрении, и, что немаловажно, быть ответственными за ведение внедренческого проекта в целом. Мне часто возражают: это не по правилам, заказчик должен быть спонсором проекта, а не ответственным за его результат, исполнителем же ИТ-проектов должна выступать ИТ-служба. Я же уверен, что если ради эффективности внедрений надо даже нарушить общепризнанные правила, лучше их нарушить. И нарушаю…
Расскажите о проблемах тиражирования системы как выделенного этапа жизненного цикла ИТ-решения в компании.
Тиражирование системы, как правило, уже не вызывает таких проблем, как в случае пилотного проекта. Здесь гораздо меньше инновационной деятельности и больше работы для менеджеров проектов. Если решение «доведено до ума» и все признали, что оно полезно, то тиражирование в другие филиалы имеет скорее организационный характер и занимает гораздо меньше времени. Это не внедрение даже, потому что уже разработаны все процедуры, регламенты, нет вопросов к программному обеспечению и всем известно, что нужно делать. Проблемы, правда, возникают, когда сам бизнес нетиражируемый. И в этом случае причина не в ИТ, а в организации бизнеса.
Например, одна компания объединила под единым руководством несколько заводов, производящих одну и ту же продукцию. Отработанное на одном из этих заводов ИТ-решение доказало свою эффективность и было принято для тиражирования на всех заводах холдинга. Процесс оказался очень непростым. Это и понятно, заводы, объединенные не так давно в единый холдинг, работают более 10 (а то и 20, 30) лет. Сложившиеся за это время традиции менеджмента и управленческие структуры оказались на этих предприятиях очень разными. В таких условиях внедрение ИТ-решений должно проводиться одновременно с кардинальной реорганизацией бизнес-процессов и систем управления, что требует вовлечения более значительных ресурсов холдинга. Тем более возможны случаи, когда при тиражировании должна быть все-таки учтена и специфика того или иного филиала. Вообще следует помнить, что ИТ-решение — это во многом овеществленные в автоматизированном продукте технология бизнеса и структура управления. Информационная система — это не автомобиль, в который любой может сесть и поехать, это скорее нервная система, которую невозможно пересадить, но можно и нужно выращивать, от ее эффективности во многом зависит эффективность самого бизнеса.
Насколько целесообразно учитывать опыт зарубежных решений для российских коммерческих предприятий?
Сейчас руководители бизнеса все больше начинают понимать, что за рубежом есть опыт, который нужно использовать. Этому способствуют и успехи иностранных компаний, пришедших на наш рынок. Естественно, надо отделять котлеты от мух. Было бы неверно удариться в другую крайность, считая, что за рубежом все лучше. Если взять тот же пример немецкого автоцентра, то видно, что качество и планирование сервисных работ, оптимизация расходов организованы там несравненно лучше, чем у нас. Замечу — не за счет более дорогого оборудования (у нас не хуже), а за счет более высокой оптимизации бизнес-процессов и исполнительской дисциплины. Это в полной мере касается и систем автоматизации. Такой опыт, безусловно, надо перенимать. Но в части маркетинговой деятельности, развития бизнеса у нас имеются практики не хуже западных. Например, хозяин упомянутого выше автоцентра вообще не собирается развивать свой бизнес, строить новый автоцентр, да и вообще менять что-либо. Новое ПО он внедрял исключительно ради оптимизации расходов. У него есть своя клиентская база, он с ней и работает, рекламу товара за него осуществляет поставщик. Так работали и его отец, и его дед. Таких предприятий на Западе очень много. У нас же рынок бурно развивается, компании в течение двух-трех лет удваивают обороты. И следовать примеру западных компаний в области развития надо очень аккуратно.
Если говорить об ИТ-решениях, то те продукты, в которых прописаны стандартизованные бизнес-процессы, лучше брать на Западе, и сейчас многие это уже понимают. Но ИТ-решения, связанные с развитием компании, с реализацией «штучных» амбициозных и креативных проектов, копировать с западных технологий надо с большой осмотрительностью, лучше создавать свои.
Вы приводили пример немецкой фирмы, когда мы говорили об аутсорсинге, который там используется. В нашем случае роль аутсорсера выполняет центральный офис. Как же с перенесением опыта, ведь это вроде бы совершенно другая модель?
Чтобы понять, можно или нельзя использовать частную модель, лучше смешать все краски. Представим на время, что собственников больше не существует, а есть одна большая компания, в которой независимые предприятия — ее разные филиалы. К примеру, «Инком-Авто», где в настоящее время работаю я, — это один филиал, «Автомир» — это другой филиал, «Рольф» — третий. А есть еще филиалы, причем в разных странах, где производят автомобили («Тойота», «Хендэ», ВАЗ и т. п.), разрабатывают отраслевые решения программного обеспечения. В такой гипотетической гиперкомпании вообще нет аутсорсинга, той или иной деятельностью будет заниматься соответствующее подразделение в рамках своей компетенции. Более того, передовой опыт, накопленный в «филиале» такой компании, вполне может быть использован в каждом из ее «подразделений».
Разделение труда в мире приводит к тому, что все больше стираются грани между предприятиями. И соответственно понятие аутсорсинга, понятие центра и филиала размываются. Здесь как в физике: возьмете одну точку отсчета — вам кажется, что вы двигаетесь, а с другой точки зрения — стоите на месте. Да, такой подход не отражает проблем, связанных, например, с безопасностью. Однако решение этих проблем лежит в другой плоскости. Их, безусловно, надо решать, но решать отдельно. А какая, например, ERP-система должна подходить для нашей гипотетической компании? Вопрос не столько риторический, сколько провокационный, такую систему трудно себе представить. Это еще раз подтверждает, что у ERP-архитектуры вряд ли есть будущее. Преимущество будет у таких систем, которые инвариантны как для отдельных компаний, так и для компаний с распределенной филиальной сетью, с развитым разделением труда.
Главное в работе ИТ-директора — не бояться правил, не бояться менять точку отсчета. Иногда с противоположной стороны можно увидеть то, что позволит принять правильное решение, результатом которого в конце концов будет увеличение эффективности работы компании.
