Что делать бизнесу, если ИТ-процессы не по размеру?

Представьте себе сервисную компанию, оказывающую услуги бухгалтерского и налогового аутсорсинга.

В ней работает 100 сотрудников, причем на 2/3 коллектив состоит из высокооплачиваемых экспертов. Все ее бизнес-процессы и результаты жестко завязаны на сроки предоставления бухгалтерской и налоговой отчетности заказчиков в соответствующие органы. А значит, и на четкую бесперебойную работу компьютерной сети, ПО на платформе «1С» и серверов, на которых оно хранится. В этом случае бизнес фактически делает главную ставку именно на ИТ. На то, что ИТ не просто «успевают» за ним, а всегда работают на опережение, да еще и безупречно. И когда компания сталкивается с тем, что это не так (регулярные простои оборудования, зависания или медлительность ПО, утечка данных клиентов или их шифрование вирусами-шифраторами), она теряет не только прибыль (от 2,5 до 10 млн. руб. за квартал), но и заказчиков, и наработанную репутацию... А постепенно теряет и бизнес. Эта ситуация характерна не только для сферы финансового, налогового и кадрового аудита, но и для многих других категорий предприятий. Специфика, уровень зависимости от ИТ, масштабы издержек и требования к непрерывности бизнеса у них будут разными, а растущая зависимость от ИТ, а также учащение сбоев и удорожание их последствий — универсальны.

Причина всех этих проблем — отсутствие системного подхода к ИТ. А подход этот в современном мире, как известно, приобретается только с помощью зрелых ИТ-процессов. В них сегодня нуждаются не только средние компании с устоявшимся бизнесом, но и малые предприятия. Однако прежде чем ответить на вопросы «Что дает процессный подход бизнесу?» и «Какого размера должны быть процессы, чтобы в них было удобно работать конкретному предприятию?», нужно понять, что же такое — правильный ИТ-процесс.

Что такое ИТ-процессы и зачем они бизнесу

Процесс — это алгоритмизированный, четко выстроенный набор действий, который решает группу проблем или задач. На выходе он дает заказчику гарантированный результат. Целостная система ИТ-процессов обеспечивает компании слаженную работу и сопровождение систем с четко заданным уровнем сервиса. «Лестница» SLA (Service Level Agreement), фундаментом которой являются ИТ-процессы, позволяет любому СМБ-предприятию мгновенно попасть в поле гарантированного качества ИТ-обслуживания. Не беспредметно говорить о качестве («ничего не работает — что делать?»), а оперировать конкретными показателями — общими и частными, о которых заказчик и исполнитель (например, аутсорсинговая компания) заранее договорились.

Показатели обслуживания могут, например, задавать время реакции специалистов на любую проблему у заказчика (скажем, 10 мин), сроки ее решения (40 мин) и/или определять доступность наиболее критичных для бизнеса сервисов — скажем, «1С» (99,9% времени в сутки). При этом для отслеживания степени реального выполнения показателей и их сравнения с эталонными значениями компании уже требуется один из выстроенных процессов «высшего уровня» — управление качеством сервиса.

Процессы или практики: не делайте ошибок!

Хочу особо предостеречь бизнес от замещения ИТ-процессов практиками. Это самая частая ошибка (после полного отсутствия процессов и работы по схеме «сломалось — починили»), уводящая совсем в другую сторону от построения «лестницы» гарантированных показателей обслуживания.

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

Когда ИТ-процессы оказываются лишними

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

Различие этих процессов легко увидеть на примере: если принтер раз за разом «жует» бумагу, то отношение к этой ситуации, как к инциденту, приведет к тому, что сотрудник ИТ-департамента будет все время восстанавливать его работоспособность. А процесс управления проблемами выявит, что у принтера износились ролики и их нужно заменить.

Однако внедрение управления проблемами и применение его ко всем сбоям в работе компьютерного оборудования и ПО возможно лишь в компаниях со средней и высокой зрелостью ИТ. Процесс поможет им предотвратить рост инцидентов, ведущих к постоянным простоям и избежать ежемесячного повышения затрат на ИТ (типичный показатель для растущего предприятия 30–50% в год). Предприятиям же с низкой зрелостью ИТ слишком ранний переход на процессное управление проблемами только добавит неразберихи, так как у них еще не отстроены ключевые для них управление инцидентами, управление запросами и функции ServiceDesk.

Как реализовать ИТ-процессы на практике

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

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

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

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

Когда процессы малы для компании. Если уже знакомая нам сервисная компания получит недостаточную номенклатуру или слишком упрощенную реализацию процессов, она не достигнет результата — повышения управляемости ИТ и нужных ей параметров SLA. Как правило, ее ИТ-специалисты — внешние или внутренние — будут лишь закрывать инциденты, а системные проблемы никуда не уйдут. В результате такого латания дыр надежность инфраструктуры не вырастет, а будет падать. Соответственно и главная цель — непрерывность бизнес-процессов (продаж, работы с клиентами, работы с регионами и пр.) и бизнеса в целом — не будет достигнута. А об управлении ИТ (планировании расходной части, увязывании работ с дальнейшими целями предприятия и т. п.) не пойдет и речи! Ведь все силы и средства будут брошены на то, чтобы бороться с текущими бедами.

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

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

Как подобрать процессы по размеру

Чтобы понять, какие процессы нужны сегодня, а какие завтра, предприятие должно оценить, в какой ячейке матрицы процессов оно находится. Эти ячейки различаются масштабом предприятия (измеряется численностью сотрудников или, точнее, количеством автоматизированных рабочих мест) и зрелостью ИТ. С масштабом все понятно (менее 50 человек, 51–200, 200–500), тогда как зрелость компании — это (в данном контексте) уровень понимания бизнесом своих потребностей в ИТ и зависимости от них. А также знание того, с помощью какой команды и каких инструментов нужные процессы можно реализовать. Оценить зрелость ИТ нетрудно, если узнать, как компания на практике реагирует на проблемы.

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

Чтобы подобрать процессы по размеру, СМБ-предприятию нужно «найти себя» на пересечении двух параметров из таблицы.

Матрица обязательных ИТ-процессов для предприятий СМБ разного масштаба и зрелости

Масштаб компании	Степень зрелости ИТ на предприятии
200–500 рабочих мест	7 ServiceDesk Управление инцидентами Управление запросами	8 +Управление проблемами +Управление изменениями +Управление уровнем сервиса	9 +Управление конфигурациями +Управление доступностью
51–200 рабочих мест	4 ServiceDesk Управление инцидентами Управление запросами	5 +Управление проблемами +Управление изменениями +Управление уровнем сервиса	6 +Управление конфигурациями
<50 рабочих мест	1 ServiceDesk Управление инцидентами Управление запросами	2 +Управление проблемами +Управление уровнем сервиса	3 +Управление изменениями
	Низкая	Средняя	Высокая

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

Рост только одного параметра — это риск

Здесь я должен предупредить еще об одной опасности, подстерегающей предприятия СМБ. Если у компании (например, с 200–500 сотрудниками)растет масштаб, но не растет зрелость ИТ, планомерного и эффективного продвижения по матрице процессов не получится. Потому что компания будет активно, но не всегда эффективно инвестировать в ИТ (в оборудование и ПО). Вложив в эту часть бизнеса немалые средства, она остановится, посчитав свою задачу выполненной. Без выстроенных процессов, которые упорядочат и планы развития, и инвестиции, так и будет казаться. На деле же такое предприятие будет тратить «лишние» миллионы рублей на ненужные инвестиции туда, где все и так работает хорошо. Например, на новые серверы для производственной системы, тогда как истинная причина проблем (резкое замедление работы бизнес-приложений на платформе «1С:Предприятие») будет заключаться в неверной настройке оборудования. Причина устраняется за неделю, если, конечно, позволяет квалификация. Но не зная об этом, компания будет много и долго работать с ИТ, не достигая главной цели — высокой надежности инфраструктуры. А инфраструктура так и не сможет поддержать непрерывность бизнеса и производственных процессов.

Если же у компании быстрее растет зрелость, чем масштаб, она будет внедрять правильные, но не востребованные бизнесом процессы (например, управление конфигурациями для малого бизнеса). Эти процессы не окупятся, не поддержат бизнес в его нынешнем состоянии и будут постоянно служить источником лишних трат, так как для них нужны и софт, и люди.

Как выбрать «донора» ИТ-процессов?

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

Здесь хорошо бы выяснить, умеет ли ИТ-аутсорсер, к которому предприятие-заказчик присматривается как к «донору» качественных ИТ-процессов, их внедрять. И тут лучше совместить формальные и неформальные критерии оценки.

К первым относится сертификация по ISO 9001 и особенно по ISO 20000 (международные стандарты для управления и обслуживания ИТ-сервисов). Аутсорсера можно и нужно спросить, какие процессы у него реализованы с учетом этих стандартов. Как именно он планирует создавать их у вас как у потенциального заказчика? Важно помнить, что фактически внедренные ИТ-процессы всегда имеют детальные схемы, регламенты и инструкции. Если их нет — значит, у аутсорсера нет и необходимых процессов, чтобы он ни говорил.

К неформальным признакам я бы отнес прежде всего соразмерность масштаба аутсорсера и заказчика. Если у корпоративного заказчика 500 сотрудников в штате, пусть у аутсорсера будет 200–400 человек, а не 5000. Потому что «пятитысячник» быстро потеряет интерес к небольшому заказчику. Если же у ИТ-аутсорсера в штате лишь 10–20 человек, ни его ресурсов, ни компетенций, ни процессов просто не хватит для работы с таким клиентом, пусть он и будет ему крайне интересен. К тому же у такой компании, как правило, будет не более одного эксперта в штате. И он окажется задействован только на самых важных проектах. А ведь вам тоже могут понадобиться экспертные знания — например, в нестандартных ситуациях.

В заключение

Подчеркну еще раз — основное преимущество правильно выбранного внешнего поставщика ИТ-услуг в том, что он не подгоняет заказчика под те процессы, которые у него хорошо выстроены. Например, из-за выгоды или желания показаться лучше, чем он есть на самом деле. Добросовестный и компетентный провайдер ИТ-аутсорсинга быстро и просто помещает клиента в «ячейку», действительно отвечающую его масштабу, степени зрелости ИТ и их динамике. Хорошо понимая при этом, что кажущиеся однотипными предприятия СМБ в действительности очень разнообразны — их отличают и наборы процессов, и алгоритмы их реализации, и способ перехода из ячейки в ячейку, и связность ИТ-процессов, и многое другое. Поэтому ИТ-аутсорсер, у которого всегда под рукой не только готовая матрица, но и готовые способы реализации перехода компании из одной ячейки в другую (например, когда ее ИТ-зрелость выросла), здесь особенно необходим.