Роль ит-подразделения в описании бизнес-процессов компании.

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

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

Соединив систему широкополосной связи, интернет-технологии, соответствующее программное обеспечение, мобильные телефоны и PDA, ИТ-специалист создает новые возможности и решения, которые крайне востребованы компаниями и их клиентами. ИТ-отделы не могут больше заниматься исключительно удовлетворением потребностей внутренних клиентов. Их основной задачей должна стать разработка инноваций, которые принесут прибыль компании и привлекут новых внешних клиентов. Переход к сервисно-ориентированной архитектуре (Service-Oriented Architecture, SOA) усилит потенциальные возможности ИТ-отдела активно участвовать в инновационной деятельности, так как предполагает понимание ИТ-персоналом основ функционирования компании.

Основным принципом руководства ИТ-отделом станет внедрение сервисной модели предоставления услуг ИТ-руководители располагают множеством механизмов для управления инфраструктурой и отдельной продукцией. Существуют широко распространенные системы, позволяющие контролировать практически любой аспект деятельности ИТ-отдела, начиная с библиотеки ITIL и заканчивая такими комплексными программами по разработке приложений, как CMMI и проектный менеджмент - РМР-сертификация. Представлены также некоторые общие практики, которые лежат в основе стратегии управления ИТ-отделом большинства организаций. Например, последнее исследование Forrester показывает, что у 70% респондентов внутри компании есть формальный комитет управления ИТ.

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

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

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

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

лидер - ИТ-директорам скоро придется сделать выбор: либо взять на себя новые функции, либо уступить лидерство другому топ-менеджеру;

экономист - ИТ-директора должны исполнять сразу две роли - борца за снижение затрат и новатора, и возникает соблазн отказаться от одной;

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

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

Первое правило управления бизнес-процессами гласит: важно определить как роль управления информационными технологиями, так и то, как структурные подразделения могут взаимодействовать друг с другом.

Второе правило - сближение ИТ и бизнеса: руководители сферы ИТ должны быть вовлечены в координацию этапов процесса между разными департаментами, которым необходима поддержка со стороны ИТ.

Вывод: на место директора информационной службы (СIO) должен прийти директор по процессам (СРО).

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

на первом уровне, директорском (так называемый C-level management, включающий генерального директора - СЕО, директора по оперативному управлению - СОО, СIO, финансового директора - CFO и др.), принимаются решения о стратегически важной деятельности. В центре внимания здесь находятся ключевые компетенции, используемые компанией для производства продукции. Одна из главных обязанностей СРО - определять основной курс управления бизнес-процессами, создавать и внедрять необходимые методы, инструменты и платформы;

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

третий уровень вновь выводит на первоначальный этап: результаты исполнения бизнес-процессов собираются, оцениваются и подготавливаются для того, чтобы руководство могло принимать решения и вносить коррективы. Выявленные при этом потребности в технологическом усовершенствовании в сочетании со вторым и третьим уровнем ведут к формированию новых принципов построения организации и новой технологической архитектуре. Внутри процесса такие хорошо известные технологии, как системы управления потоками работ (workflow) и системы интеграции приложений предприятия (ЕAI-системы), объединяются и комбинируются с интеграционными платформами и платформами приложений.

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

Обязанности директора по процессам - СРО

1. Определять и описывать значимые бизнес-процессы и анализировать их на основе аспектов деятельности предприятия.

2. Выявлять и устранять «узкие» места (простои, ненужные задержки и т.п.), постоянно оптимизировать процессы.

3. Создавать интегрированные, общекорпоративные бизнес-процессы, которые пересекают границы структурных подразделений и сливаются в полную цепочку создания добавленной стоимости, включающую и внешних партнеров.

4. Организовывать управление бизнес-процессами таким образом, чтобы ответственные за процессы сотрудники отчитывались за отдельные процессы и подпроцессы.

5. Обеспечивать интеграцию внутренних и внешних программных приложений.

6. Разрабатывать и внедрять высокопроизводительные, ориентированные на работу в реальном времени ИТ-платформы, включая аппаратное и программное обеспечение.

7. Устанавливать систему непрерывного мониторинга производственных процессов, в том числе системы отчетности.

8. Развивать системы технологически и организационно.

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

коммуникационные навыки. Организационные изменения могут происходить только при поддержке со стороны внутренних и внешних партнеров. Следовательно, партнеров необходимо держать в курсе событий, ведь основополагающим фактором успешного внедрения изменений является взаимодействие;

процедурное мышление. Потенциальный СРО должен уметь анализировать цепочку создания добавленной стоимости, используя свою компетентность в области технологий, бизнеса и организационного управления, и понимать всю эту цепочку в тер­минах динамичных процессов;

социальные умения. Долгосрочный успех в управлении бизнес-процессами возможен только в том случае, когда сотрудники ощущают себя членами одной команды, особенно если СIO намерен ввергнуть их в процесс перемен. При формировании ко­манд и назначении ответственных за процессы (владельцев процессов) в ходе управления изменениями необходимо принимать во внимание личностные аспекты;

мотивация и настрой на инновации. В будущем ключевым навыком для СЮ станет умение создавать во всей организации, начиная от производственного подразделения и заканчивая отделом маркетинга и высшим звеном руководства, настрой на инновации и оптимизацию.

Новый уровень ответственности СIO диктуется сегодняшними требованиями бизнеса - CGO (Chief Governance Officer) - директор по корпоративному управлению. Он отвечает за организацию эффективного взаимодействия всех отделов друг с другом и развитие системы коммуникаций в организации. Поле деятельности для CGO не ИТ, а БТ - технологии для бизнеса. Внедрять нужно только те новые технологии, которые позволяют решать задачи, стоящие перед бизнесом. Для этого современный CIO (Chief Integration Officer) должен хорошо ориентироваться в бизнес-процессах и предлагать способы их оптимизации, повышающие отдачу от инвестиций в ИТ.

Журнал «Корпоративные системы», июль-август 2007г, Киев

Роль IT -подразделения в описании бизнес-процессов компании

Качественное описание бизнес-процессов основывается на графическом моделировании. Это бесспорно информационная технология и прогрессивные IT-подразделения могут и должны внедрять ее в своих компаниях. Сейчас перед IT-подразделениями стоит задача не только оказывать IT-услуги своим компаниям, но и участвовать в достижении бизнес-результатов. Эта идея уже лет 7 активно обсуждается и реализуется западными IT-менеджерами. Они уверены, что IT-специалисты могут не только моделировать бизнес-процессы компании, но и участвовать в их анализе и оптимизации, привнося свое уникальное видение в методы ведения бизнеса. IT и бизнес — одна команда, и чем слаженней они будут работать, тем лучше будут совместные результаты.

Идея и необходимость описания бизнес-процессов

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

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

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

Подготовка компании к проекту по описанию бизнес-процессов

Итак, вы IT-директор или скромный руководитель IT-подразделения и вы со своими подчиненными участвуете в проекте по описанию бизнес-процессов, который затеял один из топ-менеджеров компании, или вы сами. С чего начать и как подготовить компанию к такому проекту? Вот четыре составляющие, без которых проект начинать нельзя: цель, обучение, команда, план.

Цель

Возможные цели проекта по описанию бизнес-процессов — это структуризация и регламентация компании, тиражирование бизнеса, оптимизация бизнес-процессов, внедрение СМК ИСО, функционально-стоимостной анализ деятельности компании, проектирование и внедрение ИС и т. д. Однако это очень общие формулировки, чтобы в конце проекта оценить, насколько вы достигли своей цели. Например, если ваша цель описать бизнес-процессы для тиражирования бизнеса, то ее можно детализировать как выделение основных бизнес-процессов компании XXX и разработка процессных регламентов. Для тиражирования бизнеса надо разработать еще ряд документов, но вы ограничили свой проект с помощью цели и можете точно сказать, что когда процессные регламенты выделенных бизнес-процессов разработаны, ваш проект успешно завершен. Процессные регламенты включают в себя графическую модель бизнес-процесса, ее текстовое описание, перечень поставщиков и клиентов бизнес-процесса, входы, выходы и параметры бизнес-процесса и т. д. В своем проекте вы можете ограничиться только разработкой моделей бизнес-процессов, тогда именно это и запишите в цель проекта: выделение бизнес-процессов компании ХХХ и разработка графических моделей.

Еще одним хорошим вариантом конкретизации цели проекта является присутствие в формулировке цели название бизнес-процесса или бизнес-процессов для описания. Например, разработка модели и регламента бизнес-процесса закупки и поставки сырья на склад.

Обучение

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

Обучение помогает сформировать понимание проекта и его необходимость не только у инициаторов проекта, но и у всей компании. В ходе обучения вы можете уточнить цели проекта, найти сторонников и сформировать команду.

Команда

Формирование команды проекта — это еще один важный и необходимый шаг перед началом работ. Давайте обсудим, кто должен войти в рабочую группу проекта, и какие роли в этой группе могут выполнять IT-специалисты. (рис 2).

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

Возглавляет рабочую группу Руководитель проекта — он организует и координирует проект, работает с Заказчиком и отвечает за результаты проекта. Руководителем проекта должен быть один из топ-менеджеров компании. Если руководитель IT-подразделения имеет статус IT-директора и входит в топ-менежмент компании — то Руководителем проекта может быть он.

Работу по сбору информации, формированию моделей и разработке процессных регламентов выполняют Аналитики проекта. С этой функцией лучше всего справляются IT-специалисты или люди с подобного рода образованием, потому что они владеют Case-средствами (или могут быстро их освоить), а так же имеют опыт разработки алгоритмов и схем. Хорошими Аналитиками становятся и те сотрудники компании, которые в своей деятельности, так или иначе, сталкиваются с анализом или регламентацией деятельности компании — это сотрудники отделов планирования и анализа, менеджеры по качеству и т. д.

Когда в проекте работает несколько Аналитиков, то параллельно они могут описывать разные процессы и работать на разных уровнях декомпозиции описания. Для того чтобы модели Аналитиков не пересекались и имели одинаковую подробность в рабочей группе проекта должен присутствовать Интергатор. Он удерживает целостность бизнес-модели компании и координирует работу Аналитиков. Чаще всего функции Интегратора выполняет один из Аналитиков или сам Руководитель проекта, если он имеет соответствующие компетенции.

Секретарь рабочей группы — не очень большая, но ответственная роль. Он организует заседания рабочей группы, фиксирует принимаемые решения и контролирует их исполнения. Фактически он является помощником Руководителя проекта, его левой рукой и «контрольным» органом. В роли секретаря должен быть высокоорганизованный, ответственный, исполнительный человек и некоторые IT-специалисты обладают такими качествами.

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

Если вы не внедряете процессный подход к управлению в своей компании, то функция Владельца процесса сводится к ответственности за достоверность описания бизнес-процесса.

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

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

План

И последний шаг в подготовке проекта по описанию бизнес-процессов — это планирование. Сначала определяется структура работ, исполнители и необходимые трудозатраты. Затем делается календарная привязка и определяется длительность работ: в плане учитываются праздники, дни рождения боса, корпоративные выезды и командировки. К примеру, вам на согласование модели бизнес-процесса надо всего-то 3 часа. С этой целью вы запланировали 2 встречи с Владельцем и Экспертами этого бизнес-процесса с перерывом в два дня. Длительность работ по согласованию модели бизнес-процесса составит 4 дня, но если в этот период Владелец бизнес-процесса уедет в командировку или возьмет несколько отгулов на празднование своего дня рождения, то длительность работ может существенно увеличится. Конечно, помимо запланированных, бывают и «внезапные» командировки, а для этого между работами проекта оставляется временной лаг. Это означает, что если длительность работ по согласованию модели бизнес-процесса составляет 4 дня, то перед началом следующей работы по формирование структуры процессного регламента надо оставить 1 резервный день. (рис.3). Когда такие лаги выставлены по всему проекту, то даже незапланированное отсутствие кого-то из участников проекта не повлияет на суммарную длительность проекта.

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

Бизнес-результаты проекта по описанию процессов компании

«Если раньше IT оценивались исключительно по тому, насколько успешно они осуществляли технологические проекты, то в последующие пять лет они будут оцениваться по тому, насколько сами эти проекты помогают бизнесу в его деятельности». Это было написано в журнале CIO Magazine еще вначале 2000-х. Время оценивать работу IT-подразделений по бизнес-результатам пришло. Проект по описанию бизнес-процессов несомненно поможет бизнесу в его деятельности и будет способствовать:

• повышению прозрачности деятельности компании;
• закреплению зон ответственности сотрудников компании;
• улучшению взаимодействия подразделений;
• решению проблемы «незаменимых сотрудников».

И если проект по описанию бизнес-процессов компании инициирует IT-подразделение, то достичь перечисленных результатов оно может только в тесном сотрудничестве и взаимопонимании с бизнесом. По этому поводу хорошее выражение присутствовало в выступлении Эдуарда Савушкина (корпорация Инком) на съезде IT-директоров 2007 г в Киеве: не бывает IT-проектов, бывают бизнес-проекты с вовлечением IT.

11 марта 2009 г. 09:20

Вероника Климентионок, консультант по управлению, консультационная компания «Украинский Имидж» (г.Киев)

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

Качественное описание бизнес-процессов основывается на графическом моделировании. Это бесспорно информационная технология, и прогрессивные ИТ-подразделения могут и должны внедрять ее в своих компаниях.

Идея и необходимость описания бизнес-процессов

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

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

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

Подготовка компании к проекту по описанию бизнес-процессов

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

Цель

Возможные цели проекта по описанию бизнес-процессов - это структуризация и регламентация компании, тиражирование бизнеса, оптимизация бизнес-процессов, внедрение СМК ИСО, функционально-стоимостной анализ деятельности компании, проектирование и внедрение ИС и т. д. Однако это очень общие формулировки, чтобы в конце проекта оценить, насколько вы достигли своей цели.

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

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

В своем проекте вы можете ограничиться только разработкой моделей бизнес-процессов - тогда именно это и следует записать в цель проекта: выделение бизнес-процессов компании и разработка графических моделей.

Еще одним хорошим вариантом конкретизации цели проекта является присутствие в формулировке цели названия бизнес-процесса или бизнес-процессов для описания. Например, разработка модели и регламента бизнес-процесса закупки и поставки сырья на склад.

Обучение

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

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

Обучение помогает сформировать понимание проекта и его необходимость не только у инициаторов проекта, но и у всей компании. В ходе обучения можно уточнить цели проекта, найти сторонников и сформировать команду.

Команда

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

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

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

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

Когда в проекте работает несколько Аналитиков, они могут параллельно описывать различные процессы и работать на разных уровнях декомпозиции описания. Для того чтобы модели Аналитиков не пересекались и имели одинаковую подробность, в рабочей группе проекта должен присутствовать Интегратор . Он удерживает целостность бизнес-модели компании и координирует работу Аналитиков. Чаще всего функции Интегратора выполняет один из Аналитиков или сам Руководитель проекта, если он имеет соответствующие компетенции.

Секретарь рабочей группы - не очень большая, но ответственная роль. Он организует заседания рабочей группы, фиксирует принимаемые решения и контролирует их исполнение. Фактически он является помощником Руководителя проекта, его левой рукой и «контрольным» органом.

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

Несколько слов о тех ролях, которые ИТ-специалисты выполнять никак не могут (конечно, если мы не описываем бизнес-процессы ИТ-компании).

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

Если вы описываете бизнес-процесс в рамках одного подразделения компании, то руководитель этого подразделения, скорее всего, и будет Владельцем бизнес-процесса. Например, Владельцем бизнес-процесса закупки и поставки сырья на склад будет руководитель отдела закупок. Он должен отвечать за результат этого бизнес-процесса - а именно своевременную поставку необходимого сырья на склад.

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

Если вы не внедряете процессный подход к управлению в своей компании, то функция Владельца процесса сводится к ответственности за достоверность описания бизнес-процесса.

Для описания бизнес-процессов необходимо привлекать их участников и непосредственных исполнителей. Поэтому в рабочую группу проекта должны войти Эксперты - ключевые сотрудники компании, которые участвуют в бизнес-процессах. Например, ведущий специалист по продажам, мастер смены. Для Аналитиков Владельцы и Эксперты являются основным источником информации о бизнес-процессах, они проверяют модели бизнес-процессов на соответствие действительности и утверждают их.

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

План

Последний шаг в подготовке проекта по описанию бизнес-процессов - это планирование.

Сначала определяется структура работ, исполнители и необходимые трудозатраты. Затем делается календарная привязка и определяется длительность работ: в плане учитываются праздники, дни рождения босса, корпоративные выезды и командировки.

К примеру, на согласование модели бизнес-процесса надо всего-то 3 часа. С этой целью вы запланировали две встречи с Владельцем и Экспертами этого бизнес-процесса с перерывом в два дня. Длительность работ по согласованию модели бизнес-процесса составит 4 дня, но если в этот период Владелец бизнес-процесса уедет в командировку или возьмет несколько отгулов на празднование своего дня рождения, то длительность работ может существенно увеличиться. Конечно, помимо запланированных бывают и «внезапные» командировки, а для этого между работами проекта оставляется временной лаг. Это означает, что если длительность работ по согласованию модели бизнес-процесса составляет 4 дня, то перед началом следующей работы по формированию структуры процессного регламента надо оставить 1 резервный день. Когда такие лаги выставлены по всему проекту, то даже незапланированное отсутствие кого-то из участников проекта не повлияет на суммарную длительность проекта.

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

Бизнес-результаты проекта по описанию процессов компании

«Если раньше ИТ оценивались исключительно по тому, насколько успешно они осуществляли технологические проекты, то в последующие пять лет они будут оцениваться по тому, насколько сами эти проекты помогают бизнесу в его деятельности». Это было написано в журнале CIO Magazine еще в начале 2000-х. Время оценивать работу ИТ-подразделений по бизнес-результатам пришло. Проект по описанию бизнес-процессов, несомненно, поможет бизнесу в его деятельности и будет способствовать:

● повышению прозрачности деятельности компании;

● закреплению зон ответственности сотрудников компании;

● улучшению взаимодействия подразделений;

● решению проблемы «незаменимых сотрудников».

И если проект по описанию бизнес-процессов компании инициирует ИТ-подразделение, то достичь перечисленных результатов оно может только в тесном сотрудничестве и взаимопонимании с бизнесом. По этому поводу хорошее выражение прозвучало в выступлении Эдуарда Савушкина (корпорация «Инком») на съезде ИТ-директоров 2007 г. в Киеве: «Не бывает ИТ-проектов - бывают бизнес-проекты с вовлечением ИТ» .

Концепция управления качеством информационных услуг (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 начали с себя, реорганизовав работу собственного ИТ-подразделения в соответствии с концепцией управления качеством информационных услуг.

Документ разработан для руководителей отделов программирования, директоров компаний, занимающихся разработкой собственного программного обеспечения, директоров по качеству, директоров по развитию, аналитиков бизнес-процессов.

Описываются общие подходы к повышению качества выпускаемых программных продуктов. Описанные методы анализа также применимы и к разовым работам по улучшению программ, так называемым «кастомизациям» существующего программного обеспечения.

Бизнес-процессы организации

Любая организация, выполняя свои функции, представляет себе, какие из них являются основными, какие обеспечивающими или дополнительными. Начиная с 2000 года, большинство методических рекомендаций определяет так называемый процессный подход к деятельности любых организаций. Для того, чтобы понять, что обозначает этот термин, необходимо определить понятия Процесс, Функция.

Функция – это элементарное действие (совокупность действий), выполняемое группой сотрудников (одним сотрудником), предназначенное для переработки информации, материалов с целью получения новой информации или новых свойств материалов. Проще говоря, функция, это действие, преобразующее некоторый вход в выход.

Процесс – это конечная последовательность функций, в общем непрерывная, имеющая владельца процесса, цели процесса, регламент и ресурсы, входной и выходной поток информации, материалов.

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

Очевидно, что даже если в организации не определены процессы, они существуют в том или ином виде.

Задачей любого менеджера, в соответствии с современными представлениями об организации, является определение всех процессов (бизнес-процессов) организации в соответствии с определением процесса, а именно описать:

1. Цели и задачи бизнес-процесса (прагматические характеристики);

2. Владельца (хозяина) бизнес-процесса;

3. Последовательность выполняемых функций;

4. Поток входной/выходной информации (материалов);

5. Используемые ресурсы;

6. Регламент бизнес-процесса (руководящие, описательные документы, стандарты).

При анализе бизнес-процессов менеджер (аналитик) должен определить основные производственные бизнес-процессы и вспомогательные. Например, основными производственными процессами являются: сборка автомобилей для сборочного завода, процесс разработки ПО для программистской организации, прокачка газа для газотранспортного предприятия. Вспомогательные (обеспечивающие) процессы, как правило, очень похожи во всех организациях и описаны в стандарте ИСО 9001:2008. Это такие процессы как: управление (включающее управление персоналом), закупки, продажи, складское хранение, контроль (обеспечение) качества продукции и др.

Общность процессов

Все бизнес-процессы организаций известны и определены стандартом ISO 9001:2008.

Список бизнес-процессов включает в себя:

1. Производство;

2. Управление;

3. Документирование;

4. Управление закупками;

6. Корректирующие и предупреждающие действия;

7. Управление качеством;

8. Управление жалобами клиентов.

Уникальность программистских организаций

Описанные выше требования к бизнес-процессам относятся к любой организации. Однако, у компаний, занимающихся разработкой программного обеспечения, основным производственным процессом является именно процесс разработки программного обеспечения. Уникален не только основной процесс (как, впрочем, и в любом другом производстве), но и обеспечивающие процессы, в частности процесс контроля качества продукции (в том числе тестирование).

Известные программистские организации (Микрософт, Моторола, IBM, ORACLE) уделяют вопросам качества программного кода огромное значение. Как правило, на проверку правильности программ уходит в 5-10 раз больше ресурсов, чем на их производство. В этом как раз и заключается уникальность таких организаций. Трудно себе представить, чтобы измерение детали после токарной обработки занимало в 10 раз больше времени, чем сама обточка этой детали.

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

Уникальность процесса производства

Руководителям различных уровней организаций известно, что главный метод повышения рентабельности предприятия заключается во всемерном увеличении производительности труда. На машиностроительных предприятиях приветствуется изобретательская и инновационная деятельность, позволяющая резко увеличивать производительность труда. Например, на заводах ручные операции заменяют роботизированными, производство новых изделий после их ручной обработки в начале производства стараются производить с использованием новых инструментов и технологий (иногда мотивируя рабочих простым уменьшением норм времени и материалов).

Как поступить с производством ПО? Ведь программа – это не кусок железной заготовки, которую можно обрабатывать сначала напильником, потом токарным резцом вручную, а потом с помощью робота. В институтах преподаватели часто учат программистов именно искусству программирования (с точки зрения надежности, оптимальности, быстродействия кода, например). В результате на производство приходят единичные «люди искусства», которые программируют быстро и даже корректно, но на которых нельзя положиться в критических производственных ситуациях, потому что их максимум производительности никак не совпадает с максимумом потребностей клиентов.

Большая часть оставшихся выпускников производит «сырой» продукт, который подчас страшно отдавать клиенту. Развивать бизнес, основываясь на тех или других типах программистов нереально и все чаще российские руководители программистских организаций задумываются над вопросами технологичности производства ПО.

Первые шаги в этом направлении, как правило, натыкаются на полное отсутствие российских методик и технологий, непонятность западных методологий, большую ресурсоемкость подобных работ. Данная статья предназначена как раз для помощи руководителям программистских коллективов в выборе стратегии инновации через увеличение технологичности программистского труда.

Итак, как уже было определено выше, существуют и иностранные, и локализованные стандарты, позволяющие даже при прямом их использовании существенно повысить производительность труда. А при известных затратах на разработку собственной методики удается повысить производительность (а вместе с ней и надежность, и эффективность, и безопасность, и стоимость ПО) на порядок. Эти стандарты перечислены в Источниках, в начале статьи.

С чего начать разработку собственной фирменной методики производства ПО?

Естественно с целей, которые должны достигаться применением данной методики. В настоящей статье мы делаем упор на качество программного кода, поэтому рассмотрим только те цели, которые связаны с увеличением качественных характеристик ПО, остальные цели мы рассмотрим в следующих публикациях.

В области качества программного продукта цели ставятся достаточно стандартные. Это:

1. Уменьшение сроков и стоимости разработки;

2. Корректность кода;

3. Исключение ошибок;

4. Повышение надежности;

5. Повышение эффективности автоматизируемых функций;

Все эти цели (или подцели) полностью соответствуют целям более высокого уровня:

1. Уменьшение издержек производства и технической поддержки;

2. Увеличение прибыли;

3. Увеличение производительности труда;

4. Захват большей доли рынка;

5. А также различных социальных целей, как работников предприятия, так и клиентов.

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

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

1. Определение требований клиента (клиентом могут быть и внутренние структуры организации);

2. Системное проектирование (разработка требований, спецификаций, анализ и синтез будущей системы с точки зрения элементного состава, межэлементных и внешних связей, границ системы, функциональных требований и т.п.);

3. Техническое проектирование (детализация требований, спецификаций, проектирование и разработка отдельных элементов и т.д.);

4. Разработка системы;

5. Верификация (тестирование, опытная эксплуатация и т.п.);

6. Выпуск системы (релиз, версия);

7. Сопровождение системы.

Параллельно с процессом производства ПО выполняются следующие процессы:

Общие для любого производства:

1. Управление;
2. Управление качеством;
3. Документирование;
4. Управление закупками/продажами;
5. Управление маркетингом;

Специфические для производства ПО:

1. Управление конфигурацией;
2. Управление требованиями;
3. Тестирование (модульное, интегральное, нагрузочное и т.п.).

Эти, последние процессы определяются достаточно подробно стандартами. Именно эти процессы и их взаимодействие мы и будем рассматривать далее.

Управление конфигурацией

Основы процесса Управление конфигурацией определены локализованным в России стандартом: ГОСТ Р ИСО 10007-2007. К сожалению, локализованный стандарт в силу языкового (и процессного) барьера нетривиален в своем применении, поэтому мы попытаемся в упрощенной форме изложить его требования. Благодаря такому изложению любая компания может построить процесс управления конфигурацией в течение 2-3 месяцев.

Начнем с терминологии, причем приведем термин конфигурация в контексте действующих российских компаний, не противореча в то же время стандарту.

Базовая конфигурация - целостная совокупность данных о продукте, прошедшая процедуру утверждения и принятая в качестве базового описания конфигурации (эталона). Базовые конфигурации периодически обновляются, образуя новую базовую линию в последующий момент времени путем учета истории авторизуемых изменений. Например, часто программистские компании выпускают версии своих продуктов под номерами 3.02, 3.03, … 3.10… 4.00. При этом подразумевается, что целая часть числа обозначает базовую конфигурацию программного продукта, десятые и сотые части – обозначают промежуточные версии программного продукта, отличающиеся от базовой конфигурации исправленным кодом (вследствие устранения ошибок), добавлением небольших модификаций для конкретного предприятия-клиента или для группы предприятий.

Управление конфигурацией – действия, направленные на формирование базовой конфигурации и контроль над изменениями конфигурации (версии).

Как и все процессы, процесс Управления конфигурацией состоит из следующих подпроцессов:

1. Планирование;

2. Идентификация конфигурации;

3. Управление изменениями;

4. Аудит конфигурации.

Нет смысла в такой небольшой статье описывать подробно действия, выполняемые в каждом из подпроцессов. Все они описаны подробно в указанном стандарте.

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

Управление требованиями

Целями процесса Управления требованиями является получение окончательного продукта, соответствующего актуальным требованиям заказчика на момент выпуска этого продукта. Если говорить проще, то процесс Управления требованиями предназначен для отслеживания постоянных изменений требований заказчика, учета новых требований в производимом продукте и выпуске соответствующего продукта.

Большинство специалистов любого производства скажут, что такое невозможно, ведь требования к продукту могут меняться на противоположные уже по ходу производства, что исключит выполнение таких критериев качества, как стоимость и сроки разработки продукта. Но в том и заключается окончательный результат процесса Управления требованиями – ведь если требования изменились на противоположные относительно начала работ, следовательно, заказчику уже не нужен продукт с начальными характеристиками и требованиями. Какой смысл производить то, что уже не нужно?

В процесс Управления требованиями входят следующие подпроцессы:

1. Планирование;

2. Определение начальных требований;

3. Выявление пропущенных требований (например, тех, которые заказчик предполагал в силу своего собственного контекста);

4. Проверка требований на: выполнимость (принципиальную возможность или в рамках заданных бюджетов), корректность, непротиворечивость (в общем случае в списке требований всегда присутствуют противоречивые требования, которые необходимо или исключить или выбрать оптимальное соотношение между ними), тестируемость (возможно ли в результате работы доказать, что требования выполнены, в случае если протестировать требования невозможно, их детализируют до уровня когда возможность тестирования появляется);

5. Отслеживание требований. В случае изменения требований, проводится специальная процедура изменения требований, в результате которой, как правило, часть работ по идентификации требований необходимо выполнить повторно;

6. Проверка выполнения требований в продукте (верификация, валидация).

Процесс Управления требованиями подробно описан в стандарте SW CMM, Уровень 2.

Тестирование

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

Процесс тестирование также состоит из подпроцессов:

1. Планирование;

2. Разработка отдельных тестов для каждого требования, подсистемы, модуля и т.п.;

3. Управление изменениями тестовых процедур и тестов по мере изменения требований;

4. Тестирование отдельных элементов (требований) системы;

5. Интегральное тестирование, нагрузочное тестирование (если предусмотрено техническим заданием).

На первый взгляд, это нетрудоемкий процесс, однако, необходимо понимать, что перед реализацией элементов системы сначала разрабатываются сами тесты с целью доказательства правильности реализации требований, затем тесты модифицируются с модификацией требований, затем проводятся тесты по подсистемам и только потом интегральное тестирование.

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

1. Разработчика (программист проверяет собственный код);

2. Независимого разработчика (проверку исполнения алгоритмов проводит программист, не занимающийся данной реализацией);

3. QA (Quality Assurance) – проверку кода осуществляет специальная тестовая группа в соответствии со стандартными правилами;

4. Пользовательский (до выпуска продукции необходимо, чтобы тестирование провел специалист предметной области, например, бухгалтер).

По оценкам специалистов Motorola, ORACLe трудоемкость (затраты) тестирования должны составлять не менее 100% от трудоемкости (затрат) на собственно кодирование.

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

Выводы

Таким образом, если процессы управления требованиями и конфигурацией являются для некоторых специалистов чем-то новым, то, как тестировать, вроде бы все знают. На практике же получается совершенно обратное: после реализации стандартных процессов и процедур в рамках Управления требованиями и конфигурацией, затраты на эти процессы становятся минимальны (хотя их исполнение предотвращает появление серьезных ошибок на 80-90%), а на тестирование тратится совершенно недостаточно ресурсов, что приводит к тому, что оставшиеся 10-20% ошибок не выявляются процедурами тестирования и продукт выпускается «сырой». Это, в свою очередь, приводит к тому, что продукт не устраивает потребителя, исправление ошибок в «чужом» коде превосходит все разумные затраты и в конечном итоге предприятие откладывает большую часть этих ошибок до реализации новой базовой конфигурации продукта.

Очевидно, что это приводит уже к потере качества продукта, потере клиентской базы и, как следствие, к потере прибылей компании.