Все идет от процессов. Для того чтобы ответить на вопрос о достаточности любого ресурса, будь то человеческий или технический, надо иметь четкое представление, на что эти ресурсы тратятся. Если мы опишем процесс предоставления какой-то услуги, то поймем, сколько и каких ресурсов нам надо на каждую операцию. Мы сможем понять, насколько наш процесс оптимален и на каких участках его можно оптимизировать. А в перспективе сможем не только измерять, но и сопоставлять с имеющимися показателями этого же процесса. О том, как выстраиваются процессы управления в ИТ-отделах, как идут ITSM-проекты и с какими проблемами приходится сталкиваться, шел разговор на заседании круглого стола клуба CIO металлургии, организованном компанией "Оптима-Интеграция".
Участники круглого стола:
Сергей Баранов, начальник управления ВТ НТМК
Юрий Сарапулов, директор по ИТ Выксунского металлургического завода
Наталья Сарапулова, главный специалист дирекции по ИТ ОМК
Борис Славин, директор по ИТ группы ЧТПЗ
Ефим Старостин, директор по информационным системам "Оптима-Интеграции"
Александр Крестьянов, директор по ИТ НКМКВедущий - Константин Зимин
Intelligent Enterprise: Давайте начнем разговор с тех задач, которые должны быть решены с запуском ITSM-проектов. Каковы цели этих проектов? Представляется, что их можно разделить на две крупные категории. Внутренняя цель - понять для себя, насколько эффективно работает ИТ-отдел, как загружены его сотрудники и достаточно ли у ИТ-директора ресурсов для выполнения поставленных задач. А вторая цель - внешняя: прозрачность работы ИТ-службы для высшего руководства, возможность подтвердить или опровергнуть ожидания топ-менеджеров в данном отношении.
Наталья Сарапулова: Согласна, но хочу сказать, что есть и третья цель - обеспечение процесса развития. Например, help desk, связанный с поддержкой какого-либо бизнес-приложения, решает не только задачу живучести системы, но и ее развития. Ведь помимо стандартных вопросов обслуживания на него поступают и запросы, связанные с развитием системы.
Борис Славин: Мне кажется, тут можно сформулировать общую задачу, позволяющую объединить вышеназванные цели. ИТ-директор, так же как и любой менеджер, управляет теми ресурсами, которые имеет. Причем главное для него -- не налаживание работы оборудования и не оптимизация схемы бизнес-процессов, а умение управлять стоимостью этих ресурсов. Любое производство будет эффективным настолько, насколько оно позволяет эффективно управлять стоимостью своих ресурсов. Точно так же нужно рассматривать и ИТ-службу. Основные ресурсы ИТ-отдела -- это сотрудники. Насколько хорошо мы управляем этими ресурсами и их стоимостью? По-моему, это один из основных вопросов, ради которого мы работаем. Насколько эффективно с точки зрения себестоимости мы обслуживаем наших заказчиков? Увы, не многие из нас могут ответить на этот вопрос.
Я пока тоже не могу сказать, четыреста человек в моей ИТ-службе -- это много или мало. Потому что не могу реально измерить затраты людских ресурсов и стоимость работ. Сейчас при внедрении help desk мы ставим перед собой задачу не просто выстроить процесс оказания ИТ-услуг, но и получить инструмент управления стоимостью тех ресурсов, которые при этом используются. Если мы научимся измерять себестоимость ИТ-сервиса, то сможем выстроить отношения с бизнесом на основе SLA -- не просто предоставлять услуги своим клиентам, но при этом еще и доказывать, что эти услуги будут стоить того, чтобы ими пользоваться. Появится возможность обосновать, что для повышения качества сервиса понадобится уже пятьсот сотрудников, а может, наоборот, исключение тех или иных задач даст возможность сократить штат до трёхсот человек. Сейчас я могу обосновывать подобные вещи только путём убеждения или своим авторитетом. А хотелось бы иметь четкую картину стоимости используемых ресурсов -- что такого рода услуги ведут к таким-то затратам, а столько-то человеко-часов тратится на поддержание работы серверов. Думаю, что возможность управлять стоимостью собственных ИТ-ресурсов является главной целью проектов ITSM, а реинжиниринг бизнес-процессов внутри ИТ-службы - средство достижения этой цели.
Александр Крестьянов: Да, зная зарплату специалиста, зная ту инфраструктурную часть, которая используется, мы можем точно сказать, сколько стоит этот ИТ-сервис. Очень точно. Более того, на сегодняшний день приказом генерального директора НКМК мы должны это считать. Однако, ответить на вопрос, много или мало, все равно трудно. Ведь для этого надо сравнивать с другими предприятиями, с показателями по отрасли и рынку. А таких показателей, увы, нет.
Ефим Старостин: Я не согласен. Да, чудесно знать, во сколько обходится тот или иной сервис, выполнение тех или иных работ. Но управление стоимостью -- это только один из видов "менеджмента", а их в методологии ITLM (IT Lifecycle Management. Прим. ред.) еще множество. С другой стороны, сравнить стоимость наших работ с рынком тоже не получается, потому что там практически невозможно найти полностью аналогичные услуги. Поэтому, как правило, интересует не собственно вопрос стоимости сервиса, а эффективность потраченных средств. Грубо говоря, увеличивать разницу стоимости того, что мы имеем, с тем, сколько мы за это платим, т. е. увеличивать эффективность -- это и есть главная забота менеджмента.
Юрий Сарапулов: Обоснование количества ИТ-сотрудников и оптимизация их загрузки - это все правильно, но, к сожалению, нередко не имеет отношения к реальной жизни. Чтобы металлургический бизнес был привлекательным на фондовой бирже, есть сложившиеся на мировом рынке показатели, в том числе выработка в тоннах на одного работника. Это приводит к тому, что руководство предприятия говорит - численность ИТ-отдела должно быть в два раза меньше. Что делать в такой ситуации и как обеспечить функционирование ИТ-систем?
Ефим Старостин: Решение этой задачи может быть обеспечено по той же схеме: надо соответствующим образом выстраивать процессы. Я как-то читал о порядке поведения боевого расчета на военных кораблях. В штатном режиме пушки определенного калибра обслуживаются расчетом, например, из 14 матросов, т. е. описан штатный процесс работы расчета. Но в бою, как вы понимаете, бывают неизбежные потери, и поэтому в том же документе описан своего рода "бизнес-процесс", как те же орудия могут обслуживаться, если в расчете осталось шестеро. И даже есть описание как производить стрельбу, когда их осталось всего двое.
Если менеджмент ставит задачу уменьшить численность ИТ-службы, это означает, что мы должны переработать бизнес-процессы, понимая, конечно, чт? при этом мы потеряем. Ведь задача правильного построения процессов стоит не только в том, чтобы нарисовать идеальную картинку, -- нужно определить оптимальный путь при наличии конкретных ресурсов и целей. Это одна из задач, которую надо уметь решать ИТ-директору, ему просто необходимо быть готовым к этому. Возможно, в какой-то переходный период работа будет идти в аварийном режиме, но затем ИТ-директор должен подготовленно перейти на другой уровень организации процессов.
Борис Славин: Без тех людей, которыми мы руководим, мы ничего не значим. И поэтому когда перед нами поставлены задачи, всё будет зависеть от того, насколько мы сможем консолидировать для их решения имеющиеся у нас ресурсы. На первый взгляд ИТ-служба наших заводов многочисленна, но ресурсов для решения какой-то важной задачи все равно порой не хватает. Это не означает, что необходимо иметь как можно больше ресурсов, но это значит, что надо уметь вовремя их консолидировать, расставить приоритеты по задачам и нацелить на их выполнение.
Прежде всего ИТ-директор - управленец, и его ресурсами являются люди. Если он хочет быть не директором, а консультантом, тогда ему никто не нужен, он самодостаточен и может консультировать сколько угодно. Но для руководителя нужны ресурсы, причем ресурсы управляемые. Не просто пятьсот человек в подчинении, а пятьсот человек, которые могут "встать под ружье" и идти в нужном направлении.
Обсудив цели, давайте перейдём к обоснованию инвестиций в систему управления ИТ-ресурсами и процессами ИТ-отдела. Многие ИТ-директора сетуют, как сложно доказать бизнес-менеджерам необходимость внедрения отнюдь не дешевых систем поддержки ИТ-процессов. Бизнес с этой системой напрямую не связан и не испытывает в ней необходимости. Какие заветные слова надо сказать руководителю предприятия?
Ефим Старостин: Нет таких слов. Есть два способа убедить руководителя. Первый - это спекуляция на его образованности. Большинству руководителей во время их учебы внушили мысль, что ведение дел в соответствии с "правильной методологией" -- безусловно хорошо, и они в это верят. А второй способ воздействия -- показать, каких впечатляющих результатов добились другие компании, направляющие инвестиции в область внедрения методологии управления. Если бы у нас в отечестве было такое предприятие, на котором в полной мере оказались реализованы все ITSM-процессы, к тому же поддержанные соответствующими средствами автоматизации, то туда можно было бы водить руководителей и собственников на экскурсии. Пока, к сожалению, их пользу в основном приходится доказывать собственным авторитетом.
Наталья Сарапулова: Когда-то у металлургов был документ, который регулировал эти вопросы. Он назывался "рациональный объем автоматизации". Там все было сказано, что и как надо делать. Для каждого металлургического агрегата было прописано, чем он должен быть вооружен. Может быть, и сегодня, обобщив опыт передовых заводов, можно было бы показать, без чего бизнес не может обойтись.
Ефим Старостин: Если пойти тем путем, о котором вы говорите, -- обобщить опыт, понять, без чего не могут жить современные ИТ, -- то, как это ни удивительно, мы получим точно тот же перечень процессов управления, что записан в библиотеке ITIL. И практически ни одного другого слова не будет. Но мне кажется, что не нужно относиться к самой методологии с религиозным фанатизмом. Да, есть задача выстраивания грамотных процессов, и ее нужно решать. Но задачу эту надо решать постепенно, до некоторого разумного уровня автоматизации, достижение которого возможно при существующих ресурсах.
Сергей Баранов: Это очень важный момент - двигаться постепенно. У нас на НТМК построение процессов управления ИТ-инфраструктурой и ИТ-сервисами растянулось почти на пятнадцать лет. Уже тогда мы задумывались о том, как управлять инфраструктурой, создавали собственные системы мониторинга и впервые познакомились с HP OpenView. В то время это была функционально плохо развитая система, и поэтому использовали мы её исключительно для мониторинга корпоративной сети. Но этого было недостаточно, и мы начали просматривать все известные продукты для управления ИТ-инфраструктурой. В 1999 - 2002 годах провели ряд пилотных проектов у себя на комбинате, посмотрели четыре ведущие системы -- от IBM, HP, CA и BMC. В конечном итоге мы выбрали IBM Tivoli, и, наверное, одна из главных причин этого была в том, что у нее, в отличие от HP и CA, был достаточно легкий клиент, который можно было поставить на слабопроизводительные компьютеры. В HP OpenView в те годы не было средств управления рабочими станциями, компания CA была мало представлена в России, а продукты BMC по функциональности были недостаточны для решения наших задач.
Приобретение продуктов IBM Tivoli тоже растянулось на пять лет, мы их покупали не одним пакетом, а по кусочкам, что не очень затратно. Причем мы получали ощутимый эффект от внедрения каждой подсистемы. Вначале занялись мониторингом сетевой инфраструктуры. Это мониторинг сетевого оборудования и каналов связи с помощью Tivoli NetView. Потом с помощью Tivoli Monitoring реализовали мониторинг состояния операционных систем, баз данных и приложений. Например, для SAP R/3 мы отслеживаем и анализируем по пороговым значениям порядка трёхсот параметров.
Затем развернули Tivoli Remote Control. Понятно, что если пользователь находится далеко -- а у нас он может быть на расстоянии 5 - 7 километров, то оперативно прибыть на место для устранения сбоя довольно сложно. Поэтому возможность зайти в систему, перехватить экран и помочь пользователю очень удобна.
Затем мы развернули подсистему инвентаризации оборудования и ПО. Модуль Tivoli Inventory выполняет только основные задачи технической инвентаризации, и мы выбрали систему Peregrine Asset Center (сейчас Peregrine приобретена компанией HP. - Прим. ред.), которая позволила организовать учет всех ИТ-активов на протяжении их жизненного цикла - от приобретения до списания. Сейчас у нас 4500 компьютеров, сетевое оборудование и программное обеспечение занесены в единую базу данных, и мы в любой момент времени можем узнать, у какого конкретного человека какой компьютер стоит, каковы его характеристики, операционные системы и к каким ресурсам он подключен. Кроме того, помимо базовой информации в системе есть и дополнительная -- имеющиеся на складе комплектующие, есть ли у нас запчасти для ремонта этого оборудования. Затем сделали централизованное развертывание и обновление ПО через Tivoli Configuration Manager - это очень удобно, не надо посылать массу специалистов по объектам.
Наконец, относительно недавно мы создали центр обработки и разрешения пользовательских запросов на основе Peregrine Service Center. В рамках этой системы мы планируем автоматизировать пять операционных процессов ИТ-отдела -- управление инцидентами, проблемами, изменениями, релизами и конфигурациями. В первую очередь занялись управлением инцидентами как самым основным процессом ITSM. Проект у нас идет порядка восьми месяцев, и на сегодняшний день запущены два процесса -- управление инцидентами и управление проблемами.
Важный момент момент: с чего начинать, с сервис-центра или управления приложениями и их мониторинга? Сначала мы планировали автоматизировать сервисную службу и только после этого заняться "второстепенными" процессами мониторинга инфраструктуры и управленияею. Оказалось, что этого мало, ведь если возник инцидент, то хотелось бы располагать достаточной информацией: что за компьютер, каковы операционные системы, доступ к каким из них он имеет. Должна проводиться и инвентаризация оборудования. Скажем, почему на данном компьютере не работает приложение? Может, там просто видеокарта слабая. Если не сделать инвентаризацию, то система упрощается, но эффект от её работы будет значительно ниже. Не работает компьютер, значит, надо посылать специалиста, узнать, по какой причине. Для достижения эффекта нужен максимум информации для принятия оперативного решения. Вот поэтому мы сначала установили продукты, обеспечивающие мониторинг ПО и оборудования, а потом уже приступили к верхней части этого большого айсберга -- сервис-центру.
Что касается обоснования инвестиций, то проекты, связанные с мониторингом, вообще-то не очень затратны, существенно более сложным и затратным является проект создания сервисного центра. При этом все инвестиции -- как в мониторинг инфраструктуры, так и в сервисный центр -- можно обосновать экономически, и мы это делали. В частности, для автоматизации приема и обработки заявок у нас до этого использовалась система собственной разработки. Разрабатывали мы её довольно давно, и, конечно, вставали проблемы ее документирования и т. д. Но систему надо развивать, и когда мы стали анализировать затраты на её развитие и поддержку, то выяснилось, что затраты на приобретение нового продукта с ними соизмеримы. Вопрос "нужно - не нужно" у нас просто не стоял. Но еще раз хочу обратить внимание: мы двигались постепенно и тем самым избежали большого дорогостоящего проекта.
Юрий Сарапулов: А каково влияние ITSM-проекта на культуру менеджмента на предприятии? Понятно, что подобные системы необходимы для поддержания ИТ-инфраструктуры, но есть и вторая задача, большего значения, - это повышение культуры топ-менеджмента предприятия в том числе и через такие проекты. Ведь топ-менеджеры привыкли свои претензии выставлять ИТ-директору по телефону лично …
Сергей Баранов: Да, раньше руководители верхнего уровня в случае инцидента звонили начальнику ИТ-службы. Но сейчас у нас этого нет. О существовании службы сервисной поддержки знают все, в том числе и директор. Его секретарь звонит в сервисную службу, заявку у нее принимают, а потом ей же сообщают: "Всё устранено, доложите директору". Удовлетворенность бизнеса чувствуется уже по одному тому, что есть обратная связь, которой раньше не было.
Наталья Сарапулова: Наш опыт немного другой. У нас в компании существует help desk, который отвечает за поддержку ИТ-инфраструктуры, но для поддержки новых внедряемых бизнес-систем мы создали другую точку обращения. Общая техническая поддержка у нас работает на своем help desk, а к нам обращаются только по корпоративной системе -- кому-то нужен отчет вдоль, а не поперек, кому-то надо добавить новую информацию, у кого-то возникла ошибка, а кто-то не может выполнить свои функциональные обязанности. Вообще говоря, мы старались создать систему не только поддержки пользователей, но и планирования ресурсов и поддержки самой разработки. Кроме сбора сведений о пользовательских потребностях и планирования их реализации мы хотели также создать депозиторий разработок, чтобы каждый программист мог централизованно сохранять свои наработки, чтобы можно было работу одного специалиста безболезненно передавать другому и поддерживать процесс разработки, когда множество программистов в разных офисах работает над одной задачей (у нас по крайней мере три группы разработчиков распределены по разным центрам, и их деятельность нужно координировать). Был найден свободно распространяемый продукт, который мы настроили его под себя, и это потребовало не очень много ресурсов.
С февраля 2007 года система запущена, и у нас есть общий план разработок по всем группам. Мы поддерживаем пользователей, имея в каждой группе одного диспетчера help desk. Есть возможность поиска, построения различных диаграмм и отчетов, и я как главный администратор могу вмешиваться в работу каждого планировщика, создавать группы специалистов, решающих одну задачу, видеть, какая часть плана выполнена, а какая нет. И когда нужна информация о том, какие изменения делались в каком-либо модуле, я открываю систему и вижу, кто, когда, по какой причине и что делал.
А насколько разумно иметь два разных help desk по ИТ-инфраструктуре и инцидентам, связанным с бизнес-приложениями? Не нарушает ли это принцип единой точки контакта? Как в такой ситуации проводить общий анализ инцидентов?
Наталья Сарапулова: С другой стороны, тяжело представить себе диспетчера help desk, способного классифицировать абсолютно все проблемы… Практика показывает, что наша система и традиционный help desk друг другу не мешают, а дополняют и прекрасно сосуществуют.
Сергей Баранов: Не согласен. Во-первых, квалификация диспетчеров первой линии поддержки - отнюдь не нулевая. Они не простые телефонистки, на первой линии (у нас это один диспетчер, работающий круглосуточно) отсеивается 90% запросов. Обрабатывается примерно пятьдесят запросов в день, это не так уж много, значит, система работает хорошо. Тяжелые инциденты бывают редко. Основные проблемы - не работающий принтер по причине того, что в него не положили бумагу, и т. п. Во-вторых, единая точка входа без труда обеспечивает маршрутизацию запроса к специалисту по приложению. Пользователи вообще не классифицируют проблемы, они говорят: не работает SAP R/3. Приняв такой запрос, диспетчер сразу посылает его на вторую линию поддержки, к специалисту по R/3. Ведь все прописано, сервис-центр имеет свою базу данных: после того как инцидент закроется, информация о том, что предпринято для его устранения, попадает в промежуточную базу данных. То есть при возникновении инцидента диспетчер легко найдет информацию о том, как устранялись аналогичные инциденты и какие действия нужно предпринять.
Александр Крестьянов: У нас дело поставлено аналогично. Запуск любого модуля прикладной системы автоматически влечет создание группы поддержки. Для того чтобы диспетчер единого сервис-центра правильно идентифицировал проблемы как относящиеся к новому модулю, проводится изменение классификации проблем. И тогда диспетчер в состоянии правильно переправить запрос по адресу. Правда, должен отметить, что до уровня 90% закрытых инцидентов на первой линии поддержки мы не добрались -- инцидентов у нас побольше. И хотя на первой линии поддержки дежурит не один, а три диспетчера, мы остановились на 75--80% инцидентов, закрытых на первой линии. Причем в основном, это удаётся за счет опыта работы, повторяемости инцидентов и базы знаний, которая накапливается.
Ефим Старостин: Давайте попробуем взглянуть на проблему более "системно", что ли. На работу ИТ-отдела можно посмотреть как на следующую цепочку: заказчик (бизнес) -- собственное производство (ИТ-инфраструктура) - поставщик (разработчик нового программного обеспечения, будь то вендор или внутренняя группа разработки). Это классический случай, который сплошь и рядом имеет место в бизнесе: есть заказчик, есть собственное производство и есть поставщики. И бизнес уже давно ориентируется на то, что раз есть такие три звена в цепочке, то должны быть три группы процессов, их обслуживающих: процессы, регламентирующие наши отношения с бизнесом, процессы, которые управляют нашим производством, и процессы, которые управляют созданием новых приложений или получением услуг от внешнего мира.
Теперь с точки ИТ-директора подумаем, а зачем нам нужны построенные процессы. Во-первых, процессы -- это средство регламентации действий подчиненных. С другой стороны, расписанные процессы являются средством оптимизации работы. Это не всегда наиболее дешевый и короткий путь к успеху, но всегда самый оптимальный. В-третьих -- независимость процессов от разума и навыков конкретных людей. И, наконец, самое важное - для чего нужны процессы: поскольку их исполнение процессов неизбежно приводит к завершению каждой операции, то возможно накопление каких-то контрольных измерений, на базе которых мы можем усовершенствовать свои процессы и минимизировать затраты на их содержание.
Зачем нужны процессы ИТ-отдела топ-менеджеру? Как он может быть уверен, что я все делаю правильно, оптимально и наиболее дешевым образом? Это возможно только тогда, когда я скажу, что мои процессы соответствуют какому-то эталону. Если группа процессов работает в полном соответствии с действующим стандартом, то у топ-менеджера голова не болит. Он знает, что если мне завтра на голову упадет кирпич, налаженные процессы не дадут погибнуть механизму. Теперь вспомним, что эти процессы разбиты на три различные группы и исходя из этого должно быть три группы инструментов. Здесь важно не поддаться на вроде бы банальную истину, что лучше все унифицировать, будь то поручения в организационно-распорядительной деятельности или удовлетворения новых требований к заказчику. Я не разделяю идеи унификации. Управление требованиями в области создания новых приложений -- это отдельный набор продуктов и отдельные стандарты как на систему автоматизации, так и на процессы.
Хотя интеграция этих систем обязательна. Например, единые средства доставки тех же самых поручений. Но в бэк-офисе этих процессов должны стоять специализированные системы.
Более того, если мы посмотрим на эти три группы процессов, то увидим, что в двух их них взаимодействие основано на проектном подходе, а в области эксплуатации ИТ-инфраструктуры - на процессах. Эта разница безусловно отражается на средствах автоматизации. Да, интеграция нужна, но функционально это должны быть различные системы.
Перейдем к последнему вопросу -- насколько сложно проведение ITSM-проектов? Существует мнение, что по сложности они сравнимы с проектами внедрения ERP-систем. Так ли это или тут очень сильная натяжка?
Сергей Баранов: Действительно, сильная натяжка, сравнение ERP- и ITSM-проектов некорректно. Продукты для мониторинга, удаленного управления и инвентаризации мы внедряли самостоятельно, и ничего сложного здесь нет. Было много разговоров, что внедрять систему автоматизации сервис-центра так же тяжело, как и SAP R/3. Но и тут проект длился восемь месяцев, провели мы его тоже во многом самостоятельно, но и с помощью специалистов IBM Global Services. Обучение пользователей заняло около недели. В общем, больших проблем не было, процессы ITSM интуитивно понятны. Мы работали немножко не так, и когда нам консультанты сказали, что лучше сделать по определенному шаблону, мы сначала подумали - а зачем? Но через месяц-два поняли, что именно так и надо делать. Да, вроде бы вводишь излишнюю информацию, различные уточнения, тратишь время. Зато потом можно делать разные отчеты, анализировать. На что точно не надо жалеть времени - так это на классификацию инцидентов.
Александр Крестьянов: Мы тоже всё внедряли своими силами. Единственный момент, где действительно нам потребовались консультанты, -- это стыковки с соседними системами, без которых процессы в ИТ-отделе по-хорошему жить не будут. Например, стыковка с модулем управления кадрами, с управлением основными фондами и т. д. Чтобы величины, которые ведутся в системе, не расходились с бухгалтерскими данными, требуются консультанты. А в остальном, я считаю, всё интуитивно понятно и ясно, что нужно делать.
Наталья Сарапулова: Да, действительно, ITSM-проекты проще для внедрения по одной причине -- они упрощают взаимодействие и при этом в принципе не ведут к резким изменениям, например, в обслуживании. Как картридж надо было менять, так его и меняют. Другое дело, что выстраиваются взаимоотношения. Если раньше мы принимались за устранение инцидента просто по звонку, то сегодня в работу ничто не берется без подписи. ITSM-проекты очень сильно формализуют взаимоотношения и хорошо помогают. Сотрудники быстро обучаются, мы потратили немного времени на то, чтобы всех заставить работать правильно. Зато овывобождается время, которое ранее тратилось на ненужные телодвижения.
Я бы сказала, что основное преимущество таких систем в том, что накапливается база знаний. Второе - что идёт самообучение. Если всё рассматривать в комплексе - сотрудников компании, пользующихся нашими услугами, и ИТ-сотрудников, которые эти услуги оказывают, - то главное в том, что быстрее передается опыт. Происходит определенное самообучение, и это важно. Сотрудник, хотя бы один раз попавший на заметку из-за того, что он что-то неправильно сделал, больше уже не попадается -- он обучается мгновенно. Ведь стоит попасться второй или третий раз -- и пошлют на курсы в учебный центр. Мы этим приемом очень сильно пользуемся. Если мы видим, что человек постоянно делает одну и ту же ошибку, то посылаем его на обучение. Если и это не помогло, то можно уж и вывод сделать, что он необучаемый. Вся система, как живой организм, начинает быстрее приспосабливаться.
