Есть одно известное высказывание: «Каждая наука настолько наука, насколько в ней есть математики». Сегодня нечто похожее можно сказать про взаимосвязь бизнес-процессов и информационных технологий. Подавляющее большинство бизнес-процессов эффективны настолько, насколько они обеспечиваются эффективными и оптимальными решениями в плане ИТ.
К этому состоянию бизнес пришел сравнительно недавно. Всего 10-15 лет назад внедрение ИТ-технологий в бизнес проходило через странно звучащие сегодня этапы:
1. «Начальное заражение бизнеса информационными технологиями».
Было время, когда ИТ реально воспринималось субъектами бизнес-процессов как игрушка, новая мода, более мощный, но непонятный и сложный калькулятор.
Я помню до сих пор бухгалтеров старой закалки, которые доверяли больше железным арифмометрам, и это было милое время, когда между ИТ-специалистами (поголовно называемыми программистами) и бизнес-подразделениями царила «гармония». Никто друг другу не мешал.
Но потом молодые бухгалтеры (двоечники, не научившиеся в институтах считать на арифмометрах и калькуляторах) стали требовать, чтобы ПК не зависали, чтобы программа считала быстрее, чтобы печать бланков соответствовала ГОСТам, чтобы (о боже!) два сотрудника одновременно могли работать с одной базой.
Айтишники встретили новое время с энтузиазмом, заразившим руководство готовностью утверждать новые штатные расписания и расходы на сервера, СКС, модемы и даже цветные лазерные принтеры стоимостью с новый автомобиль.
2. «Взятие под контроль».
Всё хорошее когда-то заканчивается. Наступило время обоснований ИТ-бюджетов, планирования расходов на ИТ, а кое-где даже перевод ИТ-подразделений на самоокупаемость (потом из этого родился ИТ-аутсорсинг). Пользователь стал более капризен, он почувствовал себя клиентом (который всегда прав). И такое инфантильно-потребительское по отношению к ИТ представление было даже у топ-менеджеров.
Под контроль взяли финансирование, но в бизнес-процессы организации информационные технологии по-прежнему включались дробью разрозненных автономных приложений, которые как-то помогали и даже ускоряли получение данных и отчетов на стол руководству. Тем не менее это этап уже серьезной (не опытно-экспериментальной) интеграции информационных технологий в бизнес-процессы компании.
3. «Управление данными»
— этап осознания роли ИТ в бизнесе как основного инструмента по эффективному управлению информацией, информационными потоками.
Данные перестают «обрабатываться с помощью ИТ», данные вместе с операциями над ними (описанными в бизнес-процессах) - образуют информационную систему, а ИТ-инфраструктура обеспечивает эффективную работу в интересах бизнеса инфосистем предприятия.
4. «Зрелость»
— тот этап, к которому шли раньше предприятия годами, и который сейчас должен реализовываться в течение нескольких месяцев после начала работы бизнес-единицы, а ещё лучше за несколько месяцев до начала.
Зрелость — это когда все информационные потоки, образующие информационную систему, как раз и являются отражением структуры предприятия и всех её бизнес-процессов.
То есть ИТ перестает быть всего лишь инструментом-палочкой (раньше даже термин был — «костыль»). Роль информационных технологий в бизнесе изменилась. Теперь ИТ и есть бизнес, неотъемлемая его часть, зарабатывающая не деньги на покупку серверов, а вообще ВСЕ деньги для компании.
На этом этапе топ-менеджеры уже не могут «переводить стрелки» на сисадмина (или ИТ-менеджера) при невыполнении задач из-за неработающей электронной почты.
И у ИТ-менеджера метрики и KPI завязаны на результаты всей компании, а не только на uptime серверов. Это этап общей ответственности и понимания, что ИТ (информационные технологии) — это общий термин для бизнес-технологий.
Следующий этап — это когда ИТ порождают новые бизнес-модели за счёт глобального проникновения и всеобъемлющего информационного доступа. Не исключено, что лет через 10 будет совсем неуместным вопрос, есть ли бизнес и бизнес-процессы вне Интернета (или как он тогда будет называться).
Концепция управления качеством информационных услуг (Information Technology Service Management - ITSM) возникла в результате принципиального изменения сегодняшней роли ИТ-подразделений. Бизнес-процессы настолько тесно увязаны с приложениями, техническими ресурсами и деятельностью персонала отделов автоматизации, что эффективность последних оказывается одним из решающих факторов эффективности компании в целом.
Сами информационные технологии, на которые опирается компания в повседневной работе, постоянно усложняются, корпоративная инфраструктура растет и требует значительных усилий для своего поддержания в работоспособном состоянии. А бизнес-подразделения хотят, чтобы ИТ-механизмы работали как часы, обслуживая их с надлежащим качеством и при оптимальных затратах.
Основная идея внедрения ITSM состоит в том, чтобы ИТ-отдел перестал быть вспомогательным элементом для основного бизнеса компании, ответственным только за работу отдельных серверов, сетей и приложений, «где-то и как-то» применяющихся в компании. Отдел автоматизации становится полноправным участником бизнеса, выступая в роли поставщика определенных услуг для бизнес-подразделений, а отношения между ними формализуются как отношения «поставщик услуг - потребитель услуг«. Бизнес-подразделение формулирует свои требования к необходимому спектру услуг и их качеству, руководство компании определяет объем финансирования для выполнения этих требований, а подразделения автоматизации поддерживают и развивают информационную инфраструктуру компании таким образом, чтобы она была в состоянии обеспечить запрошенную услугу с заданным качеством.
Для того чтобы сделать явью эту идеальную картинку, необходимо научить ИТ-отделы работать по-новому, перейти от управления отдельными информационными ресурсами компании к управлению услугами, которые на этих ресурсах базируются. Перестать воспринимать персонал других отделов только как своих пользователей, наладить отношениями с ними как с заказчиками.
Скажем, бухгалтерия хочет иметь автоматизированный процесс выставления счетов, что, с точки зрения ИТ-отдела услуга, которая будет реализована при помощи некоторой совокупности ПК, сервера, приложений и сети, будет обладать определенными характеристиками надежности, производительности, времени отклика, а предоставление этой услуги будет контролироваться, по результатам контроля будут сформированы отчеты в понятных заказчику бухгалтерских терминах. Эта услуга будет обладать, наконец, определенной себестоимостью, зависящей от надежности, производительности и, возможно, других характеристик. Значит, заказчик будет иметь представление о том, какие расходы повлечет за собой нужное ему качество услуги, и, можно надеяться, выдвинет ИТ-отделу реальные требования, а тот, в свою очередь, сможет организовать свою работу, исходя из реальных приоритетов.
Итак, ITSM подразумевает коренную реорганизацию службы эксплуатации информационных технологий. Опираясь на мировой опыт, компания Нewlett-Рackard разработала типовую модель управления качеством информационных услуг, так называемую ITSM Reference Model. Модель детально описывает процессы и взаимосвязи между ними, которые должен поддерживать ИТ-отдел, чтобы предоставлять информационные услуги с гарантированным качеством.
Ключевые элементы ITSM - процессы, персонал, технологии
Идеология ITSM держится на трех китах:
- формализация процессов функционирования информационных технологий;
- профессионализм и четкая ответственность сотрудников ИТ-отдела за определенный круг задач;
- технологическая инфраструктура обеспечения качества услуг: собственно информационные технологии, служба поддержки пользователей, служба управления конфигурациями и изменениями, система контроля услуг, служба тестирования и внедрения новых услуг и т.д.
Решающим для успеха внедрения ITSM является первый элемент - разработка производственных процессов ИТ-отдела, определяющих последовательность действий персонала в определенных ситуациях, координирующих работу всех сотрудников, служб и подразделений автоматизации. ИТ-отделы постоянно внедряют новые технологии, еще более усложняющие информационную инфраструктуру компании. Однако более эффективные системы сами по себе не обеспечат бизнес необходимыми услугами с требуемым качеством, если не определены процессы использования таких систем.
Типичные примеры ИТ-процессов - установка нового ПО, ликвидация проблем в сети, процесс перехода на новую резервную систему и т.д. Нечетко определенные и недокументированные процессы неизбежно станут источником незапланированных и, следовательно, неконтролируемых изменений в ИТ-инфраструктуре. Это приведет к большому числу переделок, дублированию функций, периодическим простоям и в конечном итоге к нерациональному использованию ресурсов, увеличению времени восстановления после сбоев и недовольству пользователей. А для бизнеса компании в целом, особенно если он уже успел обзавестись приставкой «е», последствия могут оказаться просто катастрофическими. Так, например, случилось с крупнейшим интерактивным аукционом eBay, который почти сутки находился в нерабочем состоянии из-за проблем с программным обеспечением. Это сразу почувствовали его клиенты во всем мире, а акции eBay подешевели суммарно на 5 млрд. долл., зато заработали конкуренты, ведь расстояние до конкурента на электронном рынке равно одному щелчку клавиши мыши.
Если для ИТ-процесса четко не сформулированы условия начала его выполнения, ИТ-отдел не сможет гарантировать, что соответствующая услуга будет предоставляться из раза в раз с неизменным качеством. Это, в свою очередь, повлияет на бизнес-процессы компании. Отрицательное влияние на эффективность бизнеса может оказать и отсутствие четко определенных взаимосвязей между процессами.
Поэтому важнейшая составляющая реализации ITSM - разработка формализованных процессов ИТ-отдела. Для каждого процесса определяется последовательность выполнения работ, необходимые ресурсы и затраты времени, средства автоматизации и контроля качества. Детальная проработка каждого ИТ-процесса в отдельности и всех ИТ-процессов вместе обеспечит согласованную работу бизнес-подразделений и служб автоматизации.
Кроме того, если процесс четко определен и документирован, включая входные параметры и результаты выполнения, можно измерить его производительность. Это особенно важно, если перед ИТ-отделом стоит задача реализации услуги заданного качества за определенную стоимость. Кроме того, это позволит совершенствовать процесс и вносить необходимые изменения в упреждающем режиме - еще до того, как произошел сбой в реализации услуги.
Внедрение процессной организации функционирования инженерных технологий приведет к изменению структуры ИТ-отдела, поскольку процесс задействует определенных людей, и их обязанности должны быть также определены и документированы, как и другие элементы любого процесса.
Особую роль играет менеджер процесса - Process Owner - сотрудник, который будет контролировать выполнение процесса от начала и до конца. Его обязанности и полномочия должны быть определены и подтверждены руководством компании, поскольку менеджеру процесса придется принимать решения, затрагивающие разные подразделения. Ведь ИТ-процесс, как правило, является кросс-функциональным и пересекает организационные границы. Когда в компании развертывается новое приложение или происходит модернизация сервера, директивы менеджера такого процесса обязаны выполнять сотрудники любых отделов, которых коснутся изменения информационной инфраструктуры. Менеджер процесса назначает ответственных за определенные задачи, анализирует влияние процесса на функционирование бизнеса компании, поддерживает взаимоотношения с менеджерами других подразделений. Для ИТ-отделов, которые привыкли распределять ответственность персонала по функциональным группам ресурсов и не имеют общего видения процессов, реорганизация работы, связанная с определением процесса и его менеджера, необходима, но и наиболее сложна.
Назначение менеджера процесса - один из элементов управления ИТ-услугами в целом. Другие характеристики управления процессами включают формализацию, повышение эффективности процесса и устранение причин неправильной работы, разработку и документирование процесса, контроль за тем, чтобы процесс соответствовал требованиям пользователей, а его результаты - заданным спецификациям.
Типовая модель
Два года назад Hewlett-Packard предложила типовую модель информационных технологий HP IT Reference Model, которая позволяет разработать структуру ИТ-процессов в компании и на ее основе реализовать управление качеством информационных услуг. Типовая модель представляет собой методику внедрения лучшего международного опыта в области ИТ, собранного в Библиотеке IT Infrastructure Library. Библиотека ITIL - это сборник из 68 книг по различным областям функционирования ИТ, включая планирование ресурсов, управление проблемами, управление инцидентами, разработку и внедрение новых услуг, снижение расходов, управление пользователями и т.д. Эта информация собиралась и систематизировалась Комитетом по телекоммуникациям при правительстве Великобритании, а сейчас поддерживается, издается и обновляется независимой организацией EXIN .
Библиотека ITIL - своеобразный эталон, сопоставляя с которым состояние информационных технологий компании можно определять области, требующие усовершенствования. НР взяла систему стандартов ITIL за основу и, добавив собственный опыт, а также опыт своих партнеров и заказчиков, разработала структуру ИТ-процессов и их взаимосвязей. Если Библиотека ITIL показывает, «что такое хорошо», то Типовая модель определяет пути достижения эталона. Типовая модель - самый верхний уровень системы управления качеством информационных услуг, карта стандартных ИТ-процессов, которая при внедрении в конкретной оргагнизации наполняется специфическим содержанием, позволяет распределить необходимые функциональные роли между сотрудниками ИТ-отдела и выбрать оптимальный инструментарий. НР подчеркивает, что разработанная модель применима к любой информационной инфраструктуре, независимо от ее масштаба и степени распределенности.
Типовая модель ИТ отображает жизненный цикл большинства услуг, которые ИТ-отдел может предоставлять бизнес-подразделениям компании. Прежде всего, она позволяет оценить текущее состояние информационной инфраструктуры, определить статус, значимость и взаимосвязи уже реализованных процессов. Благодаря этому ИТ-отдел поймет, какие процессы требуют переработки, каких процессов не хватает, каким он видит организацию ИТ-услуг в идеале и как спланировать достижение поставленных целей. Делая акцент на взаимосвязи между процессами, Типовая модель позволяет выделить приоритеты в реализации процессов. Определение зависимостей между процессами дает возможность выявить ту информацию, которая будет ими совместно использоваться, и тем самым упрощает разработку процессов. Типовая модель может стать отправной точкой для организационных изменений в работе ИТ-отдела. Работа с Типовой моделью и анализ процессов позволяет выявить потенциальные области применения технологий управления. Кроме того, ее использование даст возможность понять, какие информационные услуги ИТ-отдел должен обеспечивать внутренними силами, а где есть потенциал для аутсорсинга - передачи части функций сторонним организациям, и как внутренние процессы будут взаимодействовать с услугами от внешнего поставщика.
В Типовой модели НР все процессы разделены на пять групп, каждая из которых отражает определенный аспект жизненного цикла ИТ-услуги (рис.) - от анализа бизнес-задач, стоящих перед отделом автоматизации, до определения спецификаций услуги и разработки соглашений об уровне обслуживания, реализации, развертывания и поддержки услуг.
Гарантии предоставления услуг
Процессы этой группы занимают центральное место в структуре управления ИТ-услугами. Во-первых, они обеспечивают необходимую стабильность ИТ-среды. Во-вторых, с ними так или иначе взаимодействуют все остальные процессы.
Процесс управления изменениями (change management) регистрирует все изменения корпоративной информационной среды, координирует заявки на проведение работ, связанных с внесением изменений, устанавливает приоритеты для запросов на изменения, определяет полномочия на внесение изменений в работающую систему, распределяет ресурсы, координирует восстановление при сбоях в результате изменений и оценивает риски и влияние любых изменений на информационную среду. И поскольку любой процесс в представленной модели так или иначе вызывает изменения информационной инфраструктуры, он неизбежно взаимодействует с процессом управления изменениями - единственным в структуре ИТ-процессов, который регламентирует, контролирует и фиксирует изменения и тем самым обеспечивает устойчивое состояние информационной среды.
Процесс управления конфигурациями (configuration management) регистрирует и контролирует данные об ИТ-инфраструктуре. Этот процесс обрабатывает информацию о каждом элементе конфигурации (configuration item - CI): атрибуты CI (системы и сетевые устройства, прикладные программы, персонал, документация и т.д.), статус CI (в наличии, в ремонте, в производственной среде и т.д.) и взаимосвязи между ними (например, «компьютер А находится на рабочем столе пользователя X», «принтеры В, C и D доступны для использования» и т.д.). Процесс управления конфигурацией, который относится только к ресурсам ИТ-инфраструктуры, не следует путать со стандартной процедурой управления ресурсами предприятия. Любые процессы, влияющие на инфраструктуру (а это все процессы модели), будут взаимодействовать с процессом управления конфигурацией.
Привязка ИТ к бизнес-процессам
Процессы этой группы имеют стратегическое значение, поскольку обеспечивают ИТ-отделу возможность работать «как бизнес», а не «для бизнеса». Здесь анализируется потенциальный рынок услуг и возможная конкуренция, достигается взаимопонимание между ИТ-отделом и его заказчиками в отношении потребностей бизнеса и возможностей информационной инфраструктуры и, наконец, формулируется стратегия ИТ-отдела по оптимальному в смысле задействованных ресурсов способу предоставления информационных услуг.
В ходе анализа бизнес-процессов (business assessment) исследуется рынок ИТ-услуг и определяются бизнес-требования к ИТ-отделу. Процесс управления пользователями (customer management) позволяет ИТ-отделу выступить в роли полноправного бизнес-партнера для потребителей информационных услуг. Управление пользователями - это возможность прогнозировать их потребности, продавать ИТ-услуги, измерять степень удовлетворенности заказчика предоставленной ему услугой. Процесс управления пользователями взаимодействует с другими процессами «бизнес-группы». Информация о пользователях, полученная в ходе выполнения этого процесса, может использоваться при анализе рынка и конкурентной ситуации, а результаты анализа бизнес-процессов и данные о пользователях в свою очередь являются основой для разработки ИТ-стратегии.
Ключевое значение для ITSM имеет процесс разработки ИТ-стратегии (IT strategy development). Используя данные процессов бизнес-анализа и управления пользователями, этот процесс трансформирует требования бизнеса в цели и задачи ИТ-отдела и планы их достижения. Разработка ИТ-стратегии включает определение бюджета ИТ-отдела, документальное закрепление общего видения ИТ-процессов и услуг, описание этапов реализации поставленных задач, определение ключевых условий их достижения и возможных проблем, выбор архитектуры информационной среды и необходимых технологий, а также, возможно, принятие решения о структурной реорганизации ИТ-отдела.
Управление услугами
Процессы этой группы преобразуют общее видение информационных услуг, ИТ-стратегию, в определение конкретных услуг с помощью детальных спецификаций. Процессы управления услугами определяют уровни предоставляемых услуг, поддерживают заключение соглашений об уровне обслуживания (service level agreement, SLА), обеспечивают защиту инфраструктуры и данных. Процессы управления услугами позволяют получить информацию о доступности услуг, необходимых ресурсах и возможностях снижения расходов. На этих данных будет базироваться контракт на обслуживание.
По результатам анализа потребностей бизнеса процесс планирования услуг (service planning) составляет и контролирует «портфель» стандартных услуг, необходимых большинству корпоративных заказчиков. При необходимости стандартные услуги могут быть модифицированы для решения специфических задач бизнес-подразделения. Процесс планирования услуг разрабатывает подробные спецификации ИТ-услуги, которые затем будут использоваться другими процессами управления услугами. В функции этого процесса входит также анализ рисков, связанных с реализацией услуг, определение функциональных требований, заключение стратегических альянсов для реализации услуг, прекращение предоставления услуг.
Понятие требуемого уровня предоставляемой услуги, которое может включать перечень приложений на рабочих местах, время отклика компьютерных систем, время исправления неисправностей и т.д., является важнейшей составляющей управления информационными услугами и поддерживается процессом управления уровнем услуг (service level management). В ходе этого процесса на основе заданных параметров стандартной услуги и оценок ее стоимости определяется, обсуждается с заказчиком, отслеживается и фиксируется в отчетах необходимый заказчику уровень услуг. Подробные спецификации услуг, полученные в результате выполнения процесса планирования услуг, являются отправной точкой для заключения осмысленных соглашений SLA.
Процесс управления безопасностью (security management) - одна из недавних доработок Типовой модели НР. Его появление вызвано критическим значением гарантированной защиты компьютерной инфраструктуры для нормального функционирования электронного бизнеса. Процесс управления безопасностью определяет и контролирует параметры защиты корпоративной информации и ИТ-услуг, реализует и поддерживает инфраструктуру информационной безопасности в компании. Все услуги, предоставляемые отделом автоматизации, должны в обязательном порядке удовлетворять тем стандартам защиты, которые формулирует этот процесс. Функции процесса управления безопасностью включают определение корпоративной политики защиты и доведение ее до каждого сотрудника ИТ-подразделений, анализ проблем с защитой, оценку рисков, связанных с защитой информации, анализ возникающих инцидентов и др.
Процесс обеспечения готовности ресурсов и услуг (availability management) осуществляет контроль за готовностью услуги заказчику в соответствии с его требованиями. Готовность компьютерных систем и сетей - ключевые составляющие готовности услуги в целом. Процесс обеспечения готовности услуги может привести к изменению спецификаций услуги, определенных на этапе планирования, если это необходимо для удовлетворения потребностей заказчика. Соглашения SLA, за заключение которых отвечает процесс управления уровнем услуг, должны содержать данные о том, как будет использоваться услуга, как она будет предоставляться в случае возникновения серьезных внештатных ситуаций (подключение внешней резервной системы, реализация системы реагирования на аварии и т.д.), каким образом ИТ-отдел подготовится к сбоям в предоставлении услуги (например, будет поддерживать склад запасных деталей и т.д.). Эту важную информацию предоставляет процесс обеспечения готовности.
Процесс управления ресурсами (capacity management) осуществляет контроль за тем, чтобы рабочая нагрузка задействованных компьютерных ресурсов отвечала тем требованиям, которые оговорены в соглашении об уровне услуги. Этот процесс также является поставщиком данных для процесса планирования услуг и управления уровнем услуг.
Процесс снижения расходов (cost management) позволяет определить и контролировать реальную стоимость ИТ-услуги. Этот процесс прогнозирует прибыль от реализации услуги, определяет ее бюджет, анализирует, как используется услуга и соответствует ли она заданной стоимости, выдвигает предложения по совершенствованию услуги с целью снижения расходов, вычисляет и выставляет счета заказчикам. Результаты этого процесса используются процессами планирования услуг и управления уровнем услуг для оценки стоимости услуги, а также процессами «бизнес-группы».
Разработка и внедрение услуг
Процессы этой группы предназначены для разработки новых информационных услуг и совершенствования уже существующих, а также для реализации связанных с ними компонентов инфраструктуры - процедур, инструментария, установки оборудования, развертывания программ, разработки приложений, планов по обучению персонала и т.д. Информационная услуга и ее компоненты тестируются, после чего услуга интегрируется в продуктивную среду для определения следующей группы необходимых тестов. Только после успешного завершения тестирования в полном объеме услуга может внедряться в эксплуатацию.
Процесс реализации и тестирования (build&test) направлен на разработку и одобрение функциональной версии компонента информационной инфраструктуры, функции или услуги в целом. После того как сформулированы спецификации услуги, процесс реализации и тестирования получает нужные компоненты, реализует определенные функции или полномасштабное решение. Когда реализация компонента, функции или услуги завершена, проводится тщательное тестирование. В том числе проверяется соответствие компонентов и услуги принятым стандартам защиты. Процесс реализации и тестирования находится в тесном взаимодействии с процессами управления изменениями, управления конфигурациями и выпуском версии продуктивной системы.
Выпуск версии продуктивной системы (release to production) - это создание одной или нескольких копий нового или модифицированного компонента, сервисной функции и полномасштабной услуги в соответствии с подробным планом, который разрабатывается на этапе реализации и тестирования. Это процесс ввода услуги или ее компонентов в действие: он обеспечивает доставку, установку и интеграцию в рабочую среду необходимых ресурсов, реализацию механизмов поддержки и контроля за услугой, администрирование программного обеспечения, обучение пользователей и окончательные пользовательские тесты.
Оперативная поддержка
Последняя группа процессов отвечает за нормальное функционирование услуги, осуществляя оперативное управление ИТ-средой. Оперативные процессы отвечают за функционирование услуги, выполняют мониторинг и поддержку инфраструктуры услуг, разрешают и предотвращают проблемные ситуации, отслеживают удовлетворенность заказчика предоставляемой услугой.
Управление операциями (operations management) - это, скорее, совокупность нескольких различных задач и процедур, а не единый процесс. Все они вместе поддерживают повседневные действия по предоставлению ИТ-услуги в соответствии с соглашением об уровне обслуживания. Управление операциями гарантирует нормальную работу информационной среды, что, в свою очередь, обеспечивает нормальное обслуживание заказчика. Задачи управления операциями - это мониторинг состояния ресурсов, управление очередями на печать, управление резервированием, администрирование клиентов, серверов, сетей, пользователей, IP-адресов и баз данных и т.д.
Управление инцидентами (incident management) или служба поддержки (Help Desk) - процесс быстрого восстановления готовности услуги с наименьшими потерями в случае возникновения инцидентов в инфраструктуре. Служба поддержки обрабатывает звонки пользователей, регистрирует информацию о сбое, определяет приоритеты разрешения инцидентов. Управление инцидентами предполагает повседневное взаимодействие потребителя и поставщика услуги, являясь ценным источником информации о том, насколько пользователь удовлетворен ИТ-обслуживанием.
Если управление инцидентами - это оперативное реагирование на сбои, то управление проблемами (problem management) реализует упреждающий подход, позволяя выявить корневые причины сбоев и предотвратить их до того, как они окажут необратимое воздействие на информационную среду. Исходной информацией для анализа служат инциденты, которые разрешены предыдущим процессом. Управление проблемами включает анализ тенденций возникновения проблемных ситуаций, оценку и контроль известных ошибок в инфраструктуре, информирование других процессов о потенциальных проблемах.
Реализация ITSM
Достоинство Типовой модели НР в том, что она не имеет определенных точек начала или конца; внедрение ITSM на ее основе можно начинать с любых процессов. Но есть несколько вариантов, которые наиболее типичны, поскольку помогают организациям быстро справиться со своими проблемами.
Одна из наиболее болезненных ситуаций для ИТ-отдела - плохо работающая служба поддержки пользователей. Учащаются их жалобы, проблемы повторяются из раза в раз, растет список неразрешенных проблем. Причина, как правило, кроется в том, что отсутствуют или неправильно реализованы процессы управления инцидентами и проблемами. Беда в том, что в ИТ-отделе часто смешивают эти две разные задачи и поручают их одним и тем же сотрудникам. Но если и тем, и другим занимается один и тот же человек, у него никогда не дойдут руки до глубокого анализа; все время будет уходить на разрешение текущих инцидентов. Необходимо строго разграничить два этих процесса; тогда служба поддержки пользователей заработает нормально и ИТ-отдел сможет спрогнозировать проблемные ситуации и повысить надежность информационной инфраструктуры.
Если ИТ-отдел хочет стать поставщиком услуг, ему необходимо задуматься о том, каким образом он будет определять потребности своих клиентов и добиваться нужного качества обслуживания. А бизнес-подразделения хотят иметь возможность выбора нужных услуг, приобретения пакетов услуг. Для этого они должны как минимум понимать, что им предлагают. Но для ИТ-персонала проблематичной может оказаться даже попытка сформулировать возможности автоматизации на языке, доступном неспециалисту. Отношения ИТ-отдела с бизнес-подразделениями требуют формализации. Механизмом такой формализации являются соглашения SLA. Процесс управления уровнем услуг помогает выполнить все действия для заключения таких соглашений и, в совокупности с другими процессами, выявить необходимые связи между ИТ и бизнесом и получить общее видение услуг необходимого качества.
Наконец, реализацию ITSM часто начинают с процесса управления изменениями, поскольку он действительно играет ключевую роль для стабильной работы информационной инфраструктуры в компании. Без такой стабильности невозможен переход от поддержки технологий к предоставлению ИТ-услуг. Не менее важна реализация процесса управления конфигурациями. Если такой процесс есть, менеджер, отвечающий за изменения, быстро получит информацию об элементах конфигурации, с которыми связаны изменения, и сможет эффективно проанализировать возможные риски и влияние изменений на ИТ-среду. Служба поддержки пользователей будет иметь возможность автоматически получать список информационных ресурсов (ПК, приложения, соглашения SLA...), которые задействует обратившийся к ней пользователь. Эти примеры можно продолжать.
ITSM - новая для ИТ-отделов концепция. Но ее необходимость диктуется жизнью. Слишком велика сегодня роль информационных технологий для бизнеса, особенно для его «е»-компонента. То, что в Hewlett-Packard активно занялась этой проблемой, конечно, не случайно: технологическая основа для автоматизации работы ИТ-отдела - это платформа управления компьютерными системами и сетями HP OpenView ( , «Открытые системы», 2000, №7-8). Входящий в нее компонент IT Service Manager использует концепцию процессов и является обязательным компонентом проектов НР при развертывании ITSM-решений IT Service Manager интегрирован с другими компонентами OpenView, которые обеспечивают управление уровнем услуг, сбоями, проблемами, изменениями, позволяют взглянуть на информационные ресурсы с точки зрения бизнес-процессов и т.д. Внедрение ITSM-решений на основе Типовой модели и платформы OpenView в HP начали с себя, реорганизовав работу собственного ИТ-подразделения в соответствии с концепцией управления качеством информационных услуг.
Человек в течение всей истории своего развития старался всячески улучшить условия своего существования. Для этого он, используя свой труд, создавал блага, которые бы обеспечивали его едой, жилищем и другими жизненно важными атрибутами. Тем не менее очевиден факт, что данные новшества со временем морально и физически устаревали, и именно это давало толчок к созданию чего-то кардинально иного. Так, например, создав лук, люди успешно использовали его в военных действиях в течение веков. Однако возросшие потребности военного дела требовали пересмотра существующего арсенала, и так в X веке в Китае появилось первое огнестрельное оружие. Постоянно меняющаяся конъюнктура требовала от человека немедленной реакции в форме изобретения новшеств, что могло бы существенно увеличить его эффективность в тех или иных условиях. С появлением ЭВМ в 50-х годах прошлого столетия мир получил возможность накапливать, обрабатывать и передавать информацию, закодированную в цифровом формате. С развитием технологий, позволяющих таким образом работать с данными, существенно стали увеличиваться объемы информации, которые могли бы быть накоплены, обработаны или переданы. Именно развитие информационных технологий позволяет клиенту банка осуществить перевод денежных средств в дочерний офис на другом конце света за считанные минуты, сотруднику отдела продаж осуществить поиск в массиве данных необходимой информации о клиенте в кратчайшие сроки и банкам, не прибегая к печати банкнот, хранить сотни миллиардов долларов в безналичной форме. Информационные технологии предоставляют возможность экономическим агентам эффективно использовать информацию как фактор производства, увеличив свою производительность. 1.1.Этапы развития общества: от аграрного к информационному Сегодня экспертами принято выделять четыре основных этапа развития общественного порядка: . Аграрное общество; . Индустриальное общество; . Постиндустриальное общество; . Информационное общество; Суть аграрного общества заключается в зависимости от земли как фактора производства, причем первичный сектор является основным для экономической системы данного типа. Таким образом, общественное устройство аграрного типа характеризуется доминирующей ролью сельского хозяйства. До промышленной революции, начавшейся в конце XVIII века, аграрное общество являлось единственной формой общественного строя, что и обуславливало относительно низкие темпы экономического роста в сравнении с двумя последними веками, так как ориентация на ручной труд, отсутствие технологий, сравнительно низкий темп научного развития не позволяли развиваться мировой экономике так стремительно, как это происходит на современном этапе. Низкая социальная дифференциация, являющаяся характерной чертой аграрного общества, подчеркивала сложность самостоятельного накопления больших объемов капитала. Тем не менее, общество, особенное европейское, быстро развивалось. Увеличение объемов торговли, развитие финансовых институтов, науки и факторных рынков способствовали росту спроса на продукцию массового производства, что в результате привело к переходу от ручного труда к машинному типу производства. Данный период характеризуется высоким уровнем экономического роста, урбанизацией, изменениями в общественной структуре и развитием в таких областях как текстильная промышленность, металлургия, транспорт и связь. Индустриальное общество в отличие от аграрного связывают с преобладающей долей вторичного сектора экономики, который включает в себя обрабатывающую промышленность и строительство. Как известно, существует три сектора экономической деятельности: вышеупомянутые первичный и вторичный, представляющие собой сельское хозяйство, добывающую промышленность и обрабатывающую промышленность, строительство соответственно, а также третичный сектор, включающий в себя сферу услуг. На определенном этапе развития общество в состоянии полностью удовлетворить спрос населения на товарную продукцию. Уровень жизн
Не так часто случается, что гостем нашей традиционной рубрики “Кто он, современный ИТ-руководитель?” становится представитель производителя товаров повседневного спроса. В последний раз это было два года назад, когда мы обсуждали основные задачи ИТ-службы такого предприятия. Сегодня мы продолжаем разговор на эту тему с ИТ-директором компании Efes Rus Василием Власюком, который в беседе с научным редактором PC Week/RE Ольгой Павловой поделился своим опытом руководства ИТ-департаментом регионального подразделения крупной международной компании.
PC Week: Свой нынешний пост вы занимаете недавно — с января текущего года. С какими особенностями в сфере ИТ и бизнеса вам уже пришлось здесь столкнуться?
Василий Власюк: До прихода в Efes Rus я тринадцать лет работал в компании MARS — одном из известнейших производителей кондитерских изделий. И хотя обе компании относятся к одному и тому же рынку потребительских товаров, продукт Efes Rus имеет характерное отличие: он тяжелый и при этом относительно дешевый. Цена грузовика с пивом и грузовика с шоколадом различаются в десятки раз, и потому очень большую роль в затратах играют перевозки. Соответственно в связи с необходимостью оптимизации транспортных потоков у нас более значима роль транспортного менеджмента.
Если же сравнивать пивоваренное производство с такими высокотехнологическими сферами, как банковское дело или телекоммуникации, то у нас влияние ИТ не столь велико. Если в банке, скажем, произойдет сбой какой-либо ИТ-системы, то может встать весь бизнес. Мы же в подобной ситуации можем некоторое время продолжать работу без каких-либо значительных последствий.
PC Week: Наверное, это служит поводом для бизнеса считать ИТ-департамент вспомогательным подразделением, не приносящим никакой прибыли?
В. В.: Я считаю, что неправильно рассматривать ИТ как исключительно техническую функцию, даже если речь идет о рынке потребительских товаров. С моей точки зрения, главным конкурентным преимуществом внутреннего ИТ-отдела является понимание бизнес-процессов компании, а не чисто технических решений. То есть если мой ИТ-специалист знает только технику — как, скажем, настроить систему SAP или проложить сеть, — мне он не очень интересен, поскольку я легко могу купить такие знания на стороне.
Надо также отметить, что знания всех процессов концентрируются в относительно небольшом, в масштабах компании, отделе, поэтому в ряде случаев нам проще решать кроссфункциональные вопросы. Если, например, процесс продаж не стыкуется с процессом логистики, то два человека, сидящие рядом, могут быстрее устранить эту проблему, чем специалист отдела продаж, которому приходится искать ответственных в отделе логистики, связываться с ними по электронной почте или по телефону, договариваться и т. д.
PC Week: А где вы находите ИТ-специалистов, разбирающихся в бизнес-процессах?
В. В.: Обычно необходимые знания у человека начинают накапливаться в процессе работы в службе поддержки. При возникновении какой-либо проблемы создается инцидент, который тот хочет исследовать. Его главная цель, конечно же, — решение проблемы, но если этот человек достаточно любопытен, он может задаться вопросом, почему сложилась данная ситуация. И постепенно — как правило, после двух лет работы в службе поддержки — ИТ-специалист начинает разбираться в процессах не только в той области, за которую он отвечает, но и в ряде смежных. Как я уже говорил, проблемы у нас в основном кроссфункциональны.
Несомненно, все люди разные, есть и нелюбопытные. Однако по моему опыту они зачастую не приживаются. Да, такой человек может приносить пользу, просто решая конкретную проблему, но он не сможет дать ничего большего в будущем, останется на том же уровне профессионального развития.
PC Week: Какие первые шаги вы предприняли на новом месте?
В. В.: Я поставил перед собой задачу провести более четкое разделение обязанностей. Сегодня мы реализуем ИТ-структуру, в рамках которой выделяются группы, напрямую работающие с бизнесом. Человек, возглавляющий группу, по своей сути является мини-ИТ-директором, полностью отвечающим за всё, что происходит в зоне его ответственности. Можно сказать, что эти группы — в некотором роде лицо ИТ перед бизнесом.
В ИТ-структуре есть подразделение, отвечающее за техническую поддержку и решающее все технические вопросы, а также отделы по архитектуре, управлению проектами и эффективности бизнес-процессов. Последние два находятся сейчас в процесс формирования, идея их создания появилась с моим приходом.
PC Week: Какие вопросы входят в вашу компетенцию как ИТ-директора?
В. В.: Я вижу свою задачу отнюдь не в решении технических вопросов. Если бы это было так, мне не нужна была бы сложная ИТ-структура, а требовались бы просто консультанты, выполняющие распоряжения бизнеса. Моя миссия заключается в том, чтобы разбираться с проблемами в бизнес-процессах и предлагать варианты их решения. Конечно, эти решения могут быть непопулярны, поскольку предполагают изменение не ИТ-систем, а бизнес-процессов. На практике подобное случается часто, и приходится настойчиво и последовательно объяснять руководству, почему такие изменения необходимы.
Надо сказать, что сегодня Efes Rus переживает непростой период, связанный со слиянием двух компаний (два года назад был создан стратегический альянс британского концерна SABMiller и турецкой Anadolu Efes, в рамках которого компании объединили усилия на рынках России, Турции, а также в странах СНГ, Центральной Азии и Ближнего Востока. — О. П. ). В этой связи передо мной стоит серьёзная задача по объединению разных ИТ-ландшафтов и ИТ-коллективов, выработке единой ИТ-стратегии.
Раньше это были примерно равнозначные компании, и все их задачи вполне решались силами небольшого ИТ-отдела. В результате объединения и соответствующего увеличения оборота практически вдвое мы получили структуру, которая требует изменения системы управления. Я убежден, что когда бизнес проходит определенный порог, старыми методами работать уже невозможно — нужно провести структуризацию задач, отделить одни от других.
PC Week: Что будет представлять собой разрабатываемая вами ИТ-стратегия?
В. В.: Я полагаю, стратегия должна состоять из двух основных частей. Первая — это обеспечение работоспособности существующих систем. На деле выполнение данной задачи порой вызывает необходимость проведения изменений, связанных, скажем, с повышением эффективности функционирования данных систем. А для этого мы должны искать свежие ИТ-решения, позволяющие реализовать новые замыслы. Например, сейчас мы рассматриваем вопрос о переходе от использования своих дата-центров, которые обслуживают все наши системы, к закупке мощностей у провайдеров. То есть своего рода аутсорсинг.
Вторая часть связана с поддержкой бизнеса. Самое сложное в построении ИТ-стратегии — то, что она должна быть основана на бизнесе. Для этого необходимо первоначально выяснить, что требуется бизнесу, а потом уже предлагать какие-то варианты и строить ИТ-стратегию.
В нашей компании это организовано таким образом, что мы поочередно общаемся с директорами бизнес-подразделений, собирая пожелания о том, как у них будет развиваться бизнес. Затем этих пожелания обсуждаются на совете директоров, где все они консолидируются. Там же обсуждается и ИТ-бюджет, поскольку очевидно, что количество выделяемых денег не безгранично.
Исходя из текущей бизнес-ситуации я предполагаю, что у нас в следующем году фокус будет делаться именно на системы, обеспечивающие процессы продаж, т. е. автоматизирующие всё, что связано с работой торговых представителей и дистрибьюторов.
PC Week: Помимо закупки мощностей ЦОДов есть ли у вас планы по переводу каких-либо ИТ-сервисов на аутсорсинг?
В. В.: Надо признаться, что я очень не люблю аутсорсинг. Дело в том, что за свою карьеру я не видел ни одного случая, когда аутсорсинг оказался бы экономически эффективен. Объясняется это просто. Аутсорсер делает продукт или сервис дешевле, чем внутренний ИТ-отдел, только потому, что он реализует его на бóльших масштабах. Но в крупной компании с большим внутренним ИТ-отделом это будет стоить столько же.
Как известно, чудес не бывает. Мы живем в одном мире, и у сервис-провайдера точно такие же проблемы, как и у меня: надо найти людей, которые будут выполнять поставленные задачи, обучить их, беспокоиться о том, чтобы они не ушли, заботиться об их мотивации, следить за зарплатой, рынком труда и т. д. И почему вдруг внешний подрядчик будет делать это более эффективно, чем я?
Другая проблема использования аутсорсинга связана с тем, что при покупке сервиса требуется тратить время на то, чтобы управлять им, согласовывать уровни предоставления этого сервиса (SLA), следить за тем, чтобы они выполнялись. А если не выполняются, урегулировать разногласия. К сожалению, не получается просто купить и избавиться от забот.
Мы рассматриваем вопрос покупки мощностей серверов, поскольку это не сервис как таковой — провайдеры просто предоставляют нам необходимые мощности. Мы лишь говорим, что нам нужно столько-то процессоров и столько-то оперативной памяти, и просто получаем то, что хотим.
Сейчас специалисты моего ИТ-подразделения подсчитывают экономическую эффективность покупки мощностей. Для этого мы используем простые параметры: сколько людей требуется для обслуживания собственных дата-центров, сколько составляет их зарплата, сколько денег уходит на покупку собственного оборудования. Если все эти показатели вместе с учетом амортизации за три года продемонстрируют, что работа собственными силами обойдется дешевле, чем аутсорсинг, то я не стану его использовать. А если окажется, что дороже, то еще подумаю над эти вопросом.
PC Week: Как вы относитесь к другим популярным сегодня трендам, таким как облачные вычисления, большие данные и прочие?
В. В.: Я считаю, что облачные вычисления по сути очень похожи на аутсорсинг, поэтому отношение к ним у меня точно такое же. Но мы постоянно изучаем рынок — нужно всё-таки понимать, что там происходит. Например, SAP делает свое облако, посмотрим, что из этого выйдет. Но переходить в облако нужно только исходя из экономической выгоды. При этом первоначально я бы всё-таки попытался переводить в облако не бизнес-системы, а что-нибудь попроще — например, инфраструктурные решения, такие как корпоративная почта.
Что же касается больших данных, то если говорить честно, я никогда не сталкивался с этим на практике. Я знаю, что существует направление, позволяющее готовить гибкие отчеты и обладающее другими интересными возможностями, но я ни разу не видел бизнес, который решал бы сегодня какую-нибудь серьезную задачу с применением технологий Big Data. Мне кажется, это всё-таки дело будущего.
PC Week: Легко ли бизнес даёт деньги на внедрение новых технологий?
В. В.: Свою задачу я вижу в том, чтобы понять, что бизнес собирается делать в предстоящее время и какие проекты для этого следует реализовать. Далее я должен объяснить, что эти проекты будут стоить столько-то денег и добиться, чтобы бизнес с этим согласился. Естественно, руководство будет задаваться вопросом: “Почему так дорого?”. Поэтому мы должны прийти к соглашению и зафиксировать его. Допустим, бизнес хочет систему для мобильных компьютеров, которая будет стоить X млн. долл. Мы договариваемся и заносим данную сумму в бюджет. Однако в какой-то момент выясняется, что аппетиты отдела продаж выросли и их удовлетворение стоит уже не Х, а Х плюс некую дельту. Но в бюджете проекта этих денег нет. И тогда либо отдел продаж сокращает что-то из выполняемых задач, либо на собрании директоров решается, как перераспределить бюджет.
Правда, такая модель взаимодействия с бизнесом вступит в силу с будущего года. Это позволит оптимизировать наши планы.
PC Week: Какой опыт в последнее время был для вас самым полезным?
В. В.: Как ни странно это прозвучит, но именно уход из MARS. Это был непростой шаг, поскольку я уходил впервые в жизни, причем из компании, где я проработал много лет.
Главным обстоятельством, повлиявшим на мое решение, стало то, что в MARS имеется очень сильный глобальный ИТ-департамент, который покрывал часть моей ответственности как ИТ-директора в России. С одной стороны, это облегчает работу, а с другой — несколько ограничивало поле для принятия решений. Нередко случалось, что бизнес выдвигает некое требование, глобальные ИТ-руководители не собираются выделять на это деньги, и что я могу поделать? Слишком много времени уходило на проведение бесконечных сложных переговоров. В Efes Rus я имею большую свободу принятия решений, но при этом, конечно же, и большую ответственность. А в результате у нас в ИТ-департаменте самое большое развитие за этот год.
Вместе с тем надо отметить, что сегодня мне хотелось бы более официального признания того, что ИТ-департамент может реально влиять на бизнес-процессы. Например, что ИТ-специалист в состоянии дать правильный совет в сфере бизнеса. Допустим, приходят к нам сотрудники отделов логистики и продаж со своими просьбами, а ИТ-специалист понимает, что они говорят про одно и то же, но в разных формах. Поэтому он должен собрать их вместе и объяснить, каким на самом деле должен быть процесс и что он может быть реализован в единой системе. Именно это и есть та репутация, к которой я стремлюсь.
PC Week: Спасибо за беседу.
И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 2 000 лет, между тем как, с другой стороны, ему удался, но крайней мере приблизительно, анализ гораздо более содержательных и сложных форм. Почему так? Потому что развитое тело легче изучать, чем клеточку тела. К тому же при анализе экономических форм нельзя пользоваться ни микроскопом, ни химическими реактивами. То и другое должна заменить сила абстракции.
Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.
О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.
Многие авторы используют его «по умолчанию», как термин «интуитивно понятный» без расшифровки, либо вообще вносят дополнительную путаницу использованием альтернативной терминологии, например, пишут вместо бизнес-процесса «бизнес сущность» и т.д.
В этой статье я решил поговорить о том, что такое бизнес-процесс, рассказать об истории появления этого понятия и о том, где его можно и нужно применять. Также я планирую посвятить теме бизнес-процессов следующую статью, в которой расскажу, как правильно использовать бизнес-процессы.
Определение бизнес-процесса
Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом? В чем разница между этими терминами? Я пришел к следующему выводу:Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.
Почему я делаю особый упор на людях и коллективе:
- Бизнес-процесс всегда происходит с участием человека. Если действия выполняются автоматической системой или программой, это уже не бизнес-, а технологический процесс или спецификация. И тогда в силу вступают несколько иные стандарты, методы описания и особенности реализации.
- В бизнес-процессе всегда задействованы несколько людей в явной или неявной форме. Даже если человек работает один (например, писатель), все равно у него есть заказчики (издательские агентства) и потребители (читатели). Также продавец работает не в «вакууме» - у него есть поставщики и покупатели продукции, и все эти люди также задействованы тем или иным образом в бизнес-процессе.
Описание бизнес процесса
Также важно дать определение описанию бизнес процесса:Описание бизнес-процесса – это описание последовательности действий сотрудников при выполнении определенных действий в графическом и текстовом виде с целью регламентации действий в коллективе, анализа и оптимизации их последовательности.
И здесь необходимо понимать, что бизнес-процесс без описания не существует. Только в процессе описания появляется бизнес-процесс, т.е. невозможно реализовать одно без другого.
При этом все действия, которые описываются в бизнес-процессе, должны быть логичными, их последовательность должна приводить к определенной поставленной ранее цели.
Описание бизнес-процессов – работа творческая. Даже если вы описываете «то, что есть», все равно допускаются некоторые неточности, «сглаживаются» углы, какие-то действия упускаются для простоты восприятия. А если описывается «то, что должно быть», то здесь на основе существующего создается нечто новое. При этом бизнес-аналитик все же ограничен строгими рамками – правил, синтаксиса, логических ограничений.
Лично я сравниваю создание нового бизнес-процесса с балансированием на тонкой нити гармоничного сочетания творчества, искусства и строгой математики.
При этом нужно понимать, что ни один бизнес-процесс не может быть совершенным и на 100% соответствовать реальности. Всегда есть место каким-то упрощениям и допущениям, где-то при реализации даже самого строгого регламента свои коррективы вносит человеческий фактор.
Кроме того, как известно, в любой новой сущности всегда заложена возможность дальнейшего совершенствования. И создание бизнес-процессов также подтверждает этот философский тезис. Как бы вы ни старались описать бизнес-процесс идеально, все равно в нем найдется что-то такое, что также можно улучшить либо сейчас, либо – в будущем.
И здесь очень важно с одной стороны, вовремя остановиться самому, ведь обновленные бизнес-процессы будут реализовывать реальные люди, которые привыкли работать «по старинке», и нужно учитывать их косность мышления и степень обучаемости. Также и автоматизация, которая обычно входит в модернизацию бизнес-процессов, требует определенных вложений. И здесь нужно исходить из реальных возможностей заказчика.
Все это бизнес-консультант должен четко понимать сам, знать, где и на каком уровне допущений он упростил описание бизнес-процесса, а где решил отложить на будущее какие-то решения по объективным причинам (финансы, человеческий фактор). И все это нужно уметь просто и понятно объяснить руководителю бизнеса.
Главное отличие бизнес-процесса от технологического заключается в том, что в технологическом процессе на выходе предполагается один вполне определенный результат. Например, если речь идет о производстве, то на выходе должна получиться продукция с определенными параметрами.
Конечно, даже в технологическом процессе существует вероятность получения брака, но не один из закономерных вариантов, а последствия нарушения технологического процесса. В то время как в бизнес-процессе результат «на выходе» может отличаться в зависимости от выполнения тех или иных условий в «теле» бизнес-процесса, который выполнялся без нарушений и сбоев.
Для наглядности описание технологического процесса может выглядеть таким образом:
- Берем заготовку A;
- Соединяем ее с заготовкой B;
- Обрабатываем под параметры C;
- Получаем деталь.
В бизнес-процессе вполне нормальной считается следующая ситуация:
- Получаем вводные данные A:
- Если данные соответствуют условию B, переходим на последовательность действий C;
- Если данные соответствуют условию D, выполняем действия E.
- Полученный результат передается на выход.
История появления термина
Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.Например, когда я написал статью об IDEF0, некоторые читатели в качестве примеров нотаций приводили примеры каких-то инструкций из министерств и ведомств времен Первой Мировой или даже раньше, а в качестве графического отображения обсуждались схемы и наглядные изображения военных действий. Но все это не является описанием бизнес-процесса. Все вышеперечисленное можно назвать методиками, наглядной демонстрацией, инструкциями, но нельзя назвать нотациями.
Нотации – понятие современное, причем, нотациями называется нечто устоявшееся, стандартизированное, т.е. набор команд и обозначений, которыми пользуется много людей, а не одна или две организации. Можно придумать свой особый язык для описания бизнес-процессов или, например, программирования. Но пока он не получит «обкатку» в массовом использовании, не будут выявлены и устранены противоречия, неоднозначные трактовки, другие недочеты, пока он не стает устоявшимся и привычным для людей стандартом, называть его нотацией нельзя. Подробнее о нотациях я планирую написать позже. А сейчас вернемся к вопросу появления термина «бизнес-процесс».
На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.
Дело в том, что после начала применения информационных систем сложность организации работы людей в организациях увеличилась во много раз. Кроме того, машины не понимают абстракции, им требуется строгий алгоритм и определенный порядок введения и обработки информации. Если до начала автоматизации, когда информация переходила непосредственно от человека к человеку, проблема взаимопонимания находилась на уровне человеческих коммуникаций, то теперь появилась необходимость ее строго регламентировать.
В результате понадобилось создавать описания работы не только людей в организации, но также их взаимодействия с информационными системами. И здесь стало недостаточно текстовых нотаций (инструкций), где все описания были в свободной текстовой форме, они оказались не актуальны и неудобны. Появилась потребность в стандартизации, по сути, в создании особого языка команд и однозначной последовательности действий. Причем, в отличие от машинных языков, эти нотации должны были стать одинаково удобными для перевода в машинный код, и для восприятия человека.
Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.
***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.
Очень быстро методология и нотации завоевали огромную популярность в бизнес-среде.
Нотации позволили получить инструмент описания взаимодействия людей и цифровых информационных систем.
С их помощью оказалось возможным оптимизировать бизнес, т.е. получить более высокую производительность при тех же затратах.
Особенно заинтересовала бизнес возможность оптимизации. Как известно, чтобы что-то улучшить, нужно четко понимать, что вы имеете, и что из этого вы желаете изменить. И графические нотации наглядно показывали обе ситуации – отправная точка и желаемый результат, а также наиболее проблемные области. На основе этих данных выбрать оптимальный путь решения и смоделировать оптимальный вариант модернизации оказалось намного проще, чем без столь удобных инструментов.
Именно тогда появились понятия бизнес-процессов и нотаций бизнес-процессов, два неразрывно связанных понятия.
Очень важно понимать, что не существует, например, отдельного «бизнес-процесса продажи». Есть процесс продажи, который станет бизнес-процессом, если его описать при помощи нотации. Т.е. без описания в нотации бизнес-процесса вы занимаетесь продажами, это никто не оспаривает. Но пока нет определенного незыблемого и однозначного описания ваши продажи – явление, в чем-то, стихийное. А бизнес-процессом они станут только после их описания в рамках нотации и реализации этого описания на практике.
Продажи – это самый простой и наглядный пример. Каждый из нас в роли покупателя, а многие, и в роли продавца знакомы с этим процессом. И все мы знаем, что даже один и тот же человек в разных ситуациях (для разных товаров, разных покупателей, в разную погоду и вообще, в зависимости от настроения) будет продавать несколько по-разному. Но если описать и четко регламентировать определенный бизнес-процесс, то независимо от того, «с какой ноги встал утром продавец», процесс продажи будет определенным образом стандартизирован, ограничен определенными рамками, и, в результате, более стабилен.
Зачем моделировать (описывать) бизнес-процессы
Как я уже не единожды писал, я работаю преимущественно с малым и средним бизнесом, где предоставляю широкий комплекс услуг – от выявления проблем и «узких мест» в работе компании до внедрения предложенных мною решений на уровне программных продуктов и систем автоматизации.Моделирование бизнес-процессов помогает решить сразу две задачи:
- Изучение бизнеса. Графическое изображение в виде схем, т.е. моделирование бизнес-процессов позволяет быстрее понять особенности работы компании и выявить возможные «узкие места».
- Обеспечение наглядности. Как известно, «одна картинка стоит тысячи слов». А потому схематическое изображение работы компании помогает руководителю и владельцу бизнеса намного быстрее понять суть проблемы и оценить предложенные варианты решения. В работе бизнес-консультанта (кстати, как и специалиста по внедрению программных продуктов) очень важно, чтобы клиент понимал все преимущества решения. Не менее важна и обратная связь – руководитель на схеме сможет увидеть какие-то недочеты еще на этапе обсуждения проекта, и внедрение обойдется без дополнительных сложностей и внесения изменений в проект «на ходу».
Бизнес-процессы необходимы, чтобы представить сложную информацию в простой для восприятия форме для изучения и принятия решения.
Представьте себе обычную компанию, состоящую из разных подразделений: бухгалтерия, кадры, отдел продаж, склад, доставка, производство и т.д. Над всем этим стоит один человек – руководитель бизнеса. Он физически не может на экспертном уровне понимать все виды процессов в бизнесе. Именно потому и нанимают различных специалистов. Но ему необходимо эффективно всем этим управлять, а в определенных случаях – модернизировать.
И здесь на помощь приходят бизнес-процессы. При этом определенные виды человеческой деятельности в рамках компании описываются графическими нотациями и представляются в том виде, который помогает руководству понять, как именно происходит работа на каждом из этапов, и что здесь можно улучшить. При этом руководителю компании не обязательно обладать высокой квалификацией специалиста того или иного профиля.
Конечно, на этом уровне не обойтись без некоторых информационных потерь. Невозможно описать графической нотацией все нюансы и подробности работы каждого сотрудника. Но эти информационные потери оказываются несущественными для понимания процессов в общем и принятия решения.
Как описывать бизнес-процессы
Для того чтобы получить описание реально действующих бизнес-процессов, достаточно просто внимательно изучить последовательность действий каждого сотрудника. Т.е. необходимо получить информацию о входящих данных для запуска определенного процесса, исходящих – т.е. результата действий сотрудника, а также пошагово зафиксировать действия, которые потребовались.После того, как вся информация собрана, ее нужно перевести в графическую нотацию. Здесь стоит понимать, что именно графические нотации считаются «хорошим тоном» при составлении описаний бизнес-процессов. Для себя вы можете составлять нотацию как вам удобнее, текстовые варианты описаний также существуют и применяются, например, некоторыми разработчиками программного обеспечения. Но если вы составляете нотацию, которую будут читать другие люди, не важно, разработчик программы или руководитель компании, выбирайте графику.
Причина такого решения проста: в графическом виде информация лучше воспринимается. Если вы предложите человеку «стену текста», ему потребуется много времени и сил, чтобы разобраться, о чем вы вообще говорите. А охватить задачу целиком в этом случае – почти не реально. Другое дело графические схемы – здесь можно изучать бизнес-процессы на разных уровнях детализации, да и быстро «охватить взглядом в общем» графическую схему сможет любой человек.
- Собираем участников процесса (сотрудников);
- Собираем входящую информацию, необходимую и достаточную для запуска процесса;
- Собираем используемые системы. Это может быть учетная система,CRM, электронная почта, таблицы Excel и т.д. Все, что реально используется в работе, необходимо зафиксировать.
- Определяем ожидаемый результат – что будет в конце процесса.
- Собираем последовательность действий, которые выполняет человек.
- Вычленяем условия. В зависимости от разных входящих данных и промежуточных результатов действия могут быть разными.
- Описываем всю собранную информацию в графическом виде в удобной нотации (IDEF3, BPMN 2.0 и т.д.).
Правила описания бизнес-процесса
Выше я много сказал о творческом подходе, о возможностях включения условий и вариантов действий в описании бизнес-процессов. В результате может показаться, что любое описание действий человека «на работе» можно посчитать описанием бизнес-процесса. На самом деле, существуют строгие рамки и правила, которые определяют, можно ли назвать перечень действий описанием бизнес-процесса (в графической или текстовой форме) или нет:- Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
- Лаконичность.
Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» - если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.
Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.
Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений. - Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.0.
- Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
- Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.
Распространенные мифы и заблуждения
Не «изобретайте велосипед»! Не нужно придумывать свои нотации.Нередко люди вместо того, чтобы изучить особенности существующих нотаций, рисуют графики в произвольной форме в различных графических программах.
Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).
Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.
Во многих автоматизированных системах, например, 1С или Zoho CRM, существуют собственные сущности с названием «бизнес-процессы». Но к описываемым в этой статье бизнес-процессах эти сущности не имеют никакого отношения. Считайте их «омонимами», т.е. термины вроде звучат одинаково, но в нашем случае это – описание работы компании, а в IT системах – название группы функций и отчетов.
Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).
О том, что бизнес-процессы должны приносить прибыль, я слышал даже от известных спикеров. Более того, видел даже “разбор ошибок” при создании бизнес-процесса, в котором очень много внимания уделяется тому, что 70% действий не несут никакой ценности.
На самом деле, бизнес-процессы бывают разными. Результатом каких-то будет и правда получение прибыли, например, прямые продажи. В других случаях о приобретении ценности и вообще об оценке действий с этой точки зрения говорить сложно. Например, как можно оценить, какую ценность приносит бизнес-процесс отгрузки товара или формирования и отправки налоговой отчетности?
Я считаю, что бизнес-процесс совсем не обязательно приносит какую-то ценность, если понимать ее как непосредственную прибыль компании. Внедрение процессно-ориентированного подхода и реализация бизнес-процессов направлены больше на другое - на сохранность ценности, т.е. получению большей результативности при тех же затратах.
Возможно ли создать идеальный бизнес-процесс - когда следует остановиться?
Нет. Бизнес--процесс должен быть простым, понятным, удобным, читабельным. Но идеальным он не будет никогда.
Когда я начинал работать, мне и самому все время казалось, что я что-то недорабатываю, где-то можно было бы сделать лучше. А нередко и клиенты меня просили детализировать и описать подробнее тот или иной процесс. И я это также считал своим недочетом.
На самом деле, исходя из всего выше описанного, моделирование бизнес-процесса - это некоторое допущение, процесс творческий. С другой стороны, я в свое время не знал даже что ответить на просьбы описать еще “это” и “вон то”. Но со временем я понял, что бизнес-моделирование - это не просто творчество, но некий диалектический процесс. И уже само создание бизнес-процесса всегда будет нести в себе собственное отрицание. Здесь действительно стоит подходить к вопросу с философской точки зрения. И создавая бизнес-процесс, нужно помнить, что мы не можем охватить все и сразу, а потому он всегда будет несовершенен. Но при этом мы уже закладываем в него то, что будем совершенствовать в будущем. Стоит к этому подходить просто как к факту.
Ваш бизнес-процесс должен решать поставленную задачу, отвечать на тот вопрос, который рассматривается в рамках проекта. Все остальное - вопрос будущего возможного сотрудничества. Именно так и стоит пояснять заказчикам, почему вы не детализируете какие-то процессы или не рисуете еще какой-то бизнес-процесс, связанный с обсуждаемым.
