Вначале был ГОСТ 34
Наверное, самая устойчивая ассоциация, которая возникает, когда говорят об управлении ИТ, — это ГОСТ 34. Вот уже двадцать лет этот стандарт верой и правдой служит надежным источником управленческих практик при разработке и внедрении информационных систем. Требование придерживаться положений ГОСТ 34 при выполнении ИТ-проектов является обязательным для большинства государственных заказчиков и крупных коммерческих компаний.
Тем не менее каждый, кто сталкивался с применением ГОСТ 34 на практике, знает, что при его использовании часто возникает ряд негативных эффектов. Вот лишь несколько из них:
- появление бессодержательных технических заданий, формально полностью отвечающих требованиям стандарта, но абсолютно непригодных для использования;
- разработка искусственных «технико-экономических обоснований» ИТ-проектов, манипулирующих надуманными показателями эффективности и затрат;
- изобретение противоестественных моделей организации работ в проектах, позволяющих уложить эти проекты в «прокрустово ложе» единственной предусмотренной ГОСТом каскадной модели жизненного цикла системы.
Важно понять, что причина не в мелких недоработках, а в самой сути ГОСТ 34.
Примерно в то же время, когда разрабатывался ГОСТ 34, за рубежом окончательно сложился и стал быстро развиваться новый взгляд на управление бизнесом, основанный на процессной парадигме. Коротко смысл этой парадигмы можно выразить в виде следующей причинно-следственной связи:
- важнейшей целью управления бизнесом является повышение качества продуктов и услуг;
- высокое качество является следствием высокого уровня результативности, стабильности и эффективности бизнес-процессов создания продуктов и услуг;
- из первых двух пунктов вытекает, что именно бизнес-процессы являются теми объектами, на которые должны быть направлены управленческие решения и на которых должна основываться вся логика управления бизнесом.
Это означает, что невозможно организовать управление качеством без анализа бизнес-процессов. Отсюда возникают принципиальные вопросы. Как добиться того, чтобы бизнес-процессы были устроены «правильно»? Что нужно изменить в существующих процессах для достижения поставленной цели? Как управлять изменениями?
Довольно быстро были разработаны и продолжают разрабатываться до сих пор так называемые эталонные модели бизнес-процессов, аккумулирующие лучшие управленческие практики. Эти модели могут быть универсальными (как, например, модель, описанная в стандарте MRP II) и отраслевыми (модель еTOM), они могут выражаться схемами на бумаге или быть реализованными в виде программно-аппаратных комплексов (например, в форме ERP-систем).
Есть такие эталонные модели и для некоторых процессов управления ИТ — например, модель процессов управления ИТ-услугами, представленная в ITIL. Как правило, именно о ней вспоминают в первую очередь, когда разговор заходит о процессах
управления ИТ-поддержкой бизнеса. Разумеется, сюда же нужно отнести процессы управления ИТ-проектами. Самые продвинутые управленцы вспоминают
еще Rational Unified Process (RUP) и UML, применяемые при разработке систем. Приведенные примеры далеко не исчерпывают всего разнообразия процессов управления ИТ-поддержкой бизнеса. В самом деле, ИТ-руководители разных уровней решают массу управленческих задач: разрабатывают и утверждают ИТ-бюджеты, стратегии и планы, управляют кадрами, ИТ-инфраструктурой, занимаются закупкой оборудования и программного обеспечения, привлекают субподрядчиков и поставщиков, совершенствуют организационную структуру и выполняют еще множество функций. Неужели все, что им может предложить современная теория, исчерпывается тремя-четырьмя эталонными моделями процессов?
Цепь добавленной стоимости. Просто о сложном
Цепь добавленной стоимости (ЦДС) — замечательная по простоте и элегантности модель бизнес-процессов предприятия (компании, организации), основы которой были заложены Майклом Портером в 80-х годах прошлого века. В основе современного варианта этой концепции лежит идея разделения бизнес-процессов на две категории: основные процессы, добавляющие потребительскую стоимость к продукту или услуге предприятия, и вспомогательные процессы, не добавляющие ее, а лишь увеличивающие себестоимость продукта или услуги. Графически последовательность основных процессов по возможности отражает жизненный цикл продукта или услуги.
Однако не всегда удается изобразить основные процессы в виде линейно упорядоченной последовательности, точно отражающей жизненный цикл продукта или услуги. На протяжении жизненного цикла эти процессы могут повторяться, выполняться параллельно и т. п. Группа процессов «Маркетинг» относится к основным, поскольку эти процессы, в частности, помогают учесть требования и предпочтения потенциальных потребителей и отразить их в будущем продукте. Аналогично, к основным относятся группы процессов «Производство», «Входная логистика», так как они явно добавляют потребительскую стоимость к будущему продукту, в отличие, скажем, от процессов «Управление кадрами» или «Управление финансами», не добавляющих стоимости, но генерирующих затраты. Хотя у каждого предприятия бизнес-процессы могут быть строго индивидуальны, разделение на основные и вспомогательные присутствует всегда и является принципиальным.
Важнейшим свойством ЦДС является то, что эту концепцию можно применять для анализа процессов не только организации в целом, но и отдельных ее бизнес-единиц или даже структурных подразделений. Конечно, нас в первую очередь интересует, как выглядит ЦДС ИТ-службы. Чтобы отвлечься от конкретной организационной формы ИТ-службы (отдел, дирекция, департамент, дочерняя компания и т. п.), мы будем применять для нее общий термин «ИТ-организация». Собирательный пример ЦДС ИТ-организации показан на рисунке.
.jpg) |
| Рисунок. Собирательный пример цепи добавленной стоимости ИТ-организации. Пунктирной линией обозначены вспомогательные процессы, для которых ИТ-организация не является владельцем. |
Данная ЦДС не является ни эталонной, ни даже типовой, поскольку все ИТ-организации строго индивидуальны. В этом примере ИТ-организация для бизнес-заказчика разрабатывает, оказывает и сопровождает определенные услуги. Для этого ИТ-организация анализирует требования своего клиента, а также определяет, какое программное и аппаратное обеспечение необходимо приобрести. После того как клиенту предоставлен доступ к услуге,
ИТ-организация продолжает наблюдать за ее использованием и совершенствовать услугу. Это отражено в описании основных процессов.
Вопрос о том, что представляют собой услуги ИТ-организации, относится к числу наиболее сложных в теории управления ИТ и заслуживает отдельного разговора. Поэтому пока не будем уточнять, что это за услуги и, соответственно, как в деталях устроены основные процессы ЦДС ИТ-организации.
Рассмотрим вкратце некоторые вспомогательные процессы.
- Стратегическое планирование. Это все процессы, которые имеют своим общим результатом ИТ-стратегию предприятия. Обычно сюда входят процессы управления инвестициями, рисками, собственно планирования, бюджетирования, стратегического управления сорсингом и другие.
- Управление ИТ-инфраструктурой. Сюда относится хранение описаний компонентов инфраструктуры, мониторинг и контроль функционирования инфраструктуры, организация надежного функционирования инфраструктуры, организация закупок, ремонтов, списаний, замен и апгрейдов и т. п.
- Управление жизненным циклом систем. Все процессы, относящиеся к созданию информационных систем, включая и процессы управления партнерами и субподрядчиками.
- Управление поставщиками, субподрядчиками и аутсорсерами. Выбор контрагентов и установление долгосрочных стратегических отношений с ними.
- Управление взаимодействием с заказчиком. Один из важнейших для ИТ-организации процесс, направленный на развитие ее основной ключевой компетенции — способности эффективно взаимодействовать с клиентом и управлять его ожиданиями.
- Управление процессами. ИТ-организация должна постоянно улучшать свои процессы. Эта деятельность, в свою очередь, представляет собой процесс, изучению которого уделяется сейчас самое серьезное внимание Существует несколько подходов к организации этого процесса, но говорить о единой методике улучшения процессов пока рано.
- Управление проектами и управление изменениями. Если предприятие занимается проектным бизнесом, например разработкой сложных технических изделий, владельцем процесса управления проектами будет отдельное структурное подразделение или кто-то из высших менеджеров предприятия. Другими словами, управление ИТ-проектами должно будет следовать принятым в организации требованиям к управлению проектами. Если предприятие не занимается проектным бизнесом, выстраивание этой группы процессов — прерогатива ИТ-организации.
Чрезвычайно полезное и поучительное упражнение — нарисовать ЦДС своей ИТ-организации и попытаться понять, как в реальности организованы те или иные процессы. Как правило, при этом возникают вопросы, до сих пор остававшиеся в тени и, возможно, заслуживающие более серьезного внимания со стороны ИТ-руководства.
Самое интересное только начинается...
Разработка ЦДС для конкретной ИТ-организации — начало длинного пути совершенствования ее процессов. ЦДС позволяет структурировать наши представления о процессах ИТ-организации, а значит, и методах управления ею. С практической точки зрения ЦДС может помочь правильно сформулировать вопросы о том, как подойти к реинжинирингу бизнес-процессов управления ИТ. Прежде всего, конечно, стоит задаться вопросом, насколько оправданно внедрение процессного управления ИТ в конкретной ИТ-организации. Например, имеет ли это смысл для средних и малых ИТ-организаций, практикующих (и часто вполне успешно) неформальные методы управления? Вряд ли можно дать универсальный ответ на этот вопрос. Можно лишь утверждать, что размер ИТ-организации — не единственный критерий при поиске правильного ответа. Нужно принимать во внимание и бизнес-риски, и стратегию ИТ-организации, и многое другое. Представляется тем не менее, что в ряде случаев процессный подход заведомо не будет правильным выбором.
После того как принято решение о внедрении процессного подхода к управлению ИТ, стоит поставить вопрос о том, как должны быть организованы перечисленные в ЦДС процессы. Например, можно ли использовать для этого какие-нибудь эталонные модели?
Хорошая новость состоит в том, что для большинства приведенных на рисунке процессов существуют эталонные модели той или иной степени детальности. Нет возможности привести здесь ссылки на все источники таких моделей. Можно воспользоваться книгой (Бирюков А. Н. Лекции о процессах управления информационными технологиями. М. – СПб.: Бином, 2010.), где приводится достаточно полный список литературы на эту тему.
Из первого вопроса вытекают вопросы о том, как внедрять эти эталонные модели и есть ли для этого готовые методики. И на эти вопросы нужно дать положительный ответ. Таких методик существует несколько, и число их растет. Нет смысла перечислять здесь все стандарты и методические руководства, посвященные этой теме. Часть их проанализирована в упомянутой выше книге. Важно подчеркнуть, что, помимо внедрения эталонных моделей, существует и другой подход к совершенствованию процессов — постепенное улучшение. Первые используемые на практике методы постепенного улучшения появились почти двадцать лет назад и продолжают развиваться.
Часто спрашивают, какую роль играет описание бизнес-процессов и инструмент их описания? Какой инструмент предпочтителен? Из сказанного выше вытекает, что все зависит от поставленной задачи. Например, если решено внедрить готовую референтную модель, описание существующих бизнес-процессов не нужно. Если же их предполагается дорабатывать и улучшать, то стоит сначала их описать, чтобы понять, что с ними не так. Предпочтительнее тот инструмент, который прост в использовании и понятен участникам проекта и руководству. Обычно достаточно Visio или Microsoft Word.
Александр Бирюков — доцент Государственного университета — Высшей школы экономики; abiryukov@hse.ru