Время нюансов

Логотип компании
Время нюансов
Зачастую получается так, что граница между ИТ и бизнесом размыта сильнее, чем мы можем предположить.

Что такое бизнес-процесс глазами айтишника? Нет, классическое определение приводить не стоит – общеизвестно. Лучше, как говорится, вникнем в частности.

Бизнес-roadmap – процесс?

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

Так вот, если вернуться к вопросу о развитии. Отвечают за развитие сотрудники ИТ-службы. А вот кто инициирует развитие? С одной стороны, это сам бизнес. Поменялось что-то в договоренностях с партнерами, изменилось законодательство, изменилась концепция бизнеса в целом (да, бывает и такое) – ИТ-сотрудники вынуждены доработать средство автоматизации до новых требований. Причем объем доработок зачастую заранее не спрогнозируешь. Нельзя сказать, что, например, изменение законодательства будет в такую-то дату и потребует таких-то доработок. Другое дело – изменение процесса. Но его тоже зачастую спрогнозировать сложно: изменения порой вносятся по ходу, и айтишники об этом узнают последними, а бизнес ожидает, что «будет сделано позавчера». Но вот сообщить об изменении не спешит. А через некоторое время «догоняет» еще одним изменением, и так далее. В ряде случаев спасает ITIL – и процесс управления изменениями работает. Но это, как правило, в больших компаниях. Небольшие компании такую управленческую роскошь позволяют себе нечасто: просто потому, что выстраивание и поддержка ИТ-процесса (в данном случае по ITIL) требуют расширения штата (да, именно так: жизнь «по ITIL» однозначно требует жертв. И эти жертвы в первую очередь финансовые: наем дополнительных специалистов и возможное приобретение специализированного ПО, возможно – реорганизация и связанные с ней затраты…). При этом ПО необязательно для автоматизации – например, если ИТ заключает SLA с бизнесом, то его надо выдерживать и работать проактивно. А это – приобретение разного рода систем мониторинга, активации, реагирования и т. д. Эффективное же владение подобными системами, кстати, зачастую строится на том, что ITIL-процессы уже есть де-факто. Но даже когда их нет – приходится соответствовать. Впрочем, это все тоже применимо для большой компании. Дело в том, что специализированное ПО для небольших компаний будет стоить достаточно дорого. Поэтому или OpenSource, или подождать, пока подрастем. Другого, к сожалению, в общем случае не дано. (Частности могут выпадать из этого правила: может существовать ПО, недорогое, которое решает узкую задачу и которое доступно небольшой компании. Но, повторюсь, вспомогательные ИТ-системы – это удел больших компаний.)

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

Бизнес – сквозной процесс?

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

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

Бизнес – оценка?

В-третьих, ни для кого ни секрет, что представитель бизнеса и представитель ИТ рассматривают бизнес-процессы по-разному. Для представителей бизнеса процесс – это выполнение его задач, достижение его KPI (особенно в случае если в процессе участвует кто-то из подчиненных или он сам). Для айтишника же бизнес-процесс больше напоминает абстракцию: это алгоритм, который необходимо подвергнуть автоматизации. Это в самом сухом виде. И, кстати, ничего плохого в такой постановке вопроса нет: каждый отвечает за себя, за свою работу. И оценивают представителей бизнес-подразделений и айтишников по-разному. Айтишника могут оценивать по отсутствию ошибок, соответствию сроков и качества ИТ-продукта заранее составленным планам и т. д., а представителя бизнес-подразделений – по достигнутому бизнес-результату (увеличению прибыли, продвижению на рынок, увеличению оборота и т. д.). В этом смысле сотрудники ИТ являются инструментом для достижения бизнес-целей сотрудника бизнес-подразделения.

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

Кроме того, учитывая, что ИТ влияют на бизнес (а если на секунду оставить политкорректность, на самом деле бизнес зависит от ИТ; впрочем, верно и обратное), то зачастую за айтишниками закрепляют типично бизнесовую ответственность. Логика проста: если они обеспечивают ИТ своей поддержкой, то вполне разумно, чтобы они отвечали за всё вместе с бизнесом. Тут вообще-то по-правильному надо написать «отвечали совместно с бизнесом в объеме оказанной поддержки и обеспечения» – но об этом аспекте обычно забывают. И на ИТ-подразделение ложится вполне себе бизнесовый KPI, который оно (ИТ) обеспечить никак не в состоянии. Ну как, например, обеспечить показатель «рост прямых продаж товаров в сегменте B2B» команде, состоящей из системных администраторов и специалистов поддержки ПО? Правильный ответ: скорее всего, никак. А вот выполнить косвенный KPI, например, такого вида, как «обеспечить работу системы прямых продаж товаров в сегменте B2B с доступностью 95% и отсутствием перерывов в предоставлении услуги в рабоче время», они вполне в состоянии. Понятно, что первый KPI может быть трансформирован во второй. И что один второй KPI не перекрывает первый – но он и не должен. Понятно также, что второй KPI – это один из набора KPI, описывающих обеспечение требований бизнеса. И в итоге KPI, по которому будет оцениваться эффективность процесса со стороны бизнеса, обретает тень в виде KPI, по которому будут оценивать эффективность со стороны ИТ. Все логично.

Итого

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

Второй вопрос: а часто ли получается трансформировать KPI бизнеса в KPI ИТ? Из моего опыта: с первой попытки почти ни разу, зато после первого подведения итогов – почти всегда. Дело в том, что как раз подведение итогов очень четко фокусирует сферы ответственности. И если ИТ-служба отвечает за обеспечение, то не стоит измерять его рамками бизнеса. И наоборот: бессмысленно измерять бизнес-характеристики прикладными метриками ИТ. Богу Богово, а кесарю кесарево. И никак иначе.

Опубликовано 20.05.2015

Похожие статьи