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

Почему хорошая формализация бизнес-процесса важна?

1. Она позволяет сделать наши мысли предметом широкого обсуждения.
2. Она дает возможность донести новые правила работы до тех сотрудников, которые будут их выполнять.
3. Формализованные бизнес-процессы легче изменять и модернизировать.
4. Формализация бизнес-процессов является хорошей основой для последующей автоматизации бизнеса в компании: создания/настройки различных информационных систем и стандартных пакетов автоматизации.

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

Пример бизнес-процесса

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

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

Выделим следующие действия бизнес-процесса.

1. "Оформление заказа". Сначала клиент оформляет заказ. Предполагается, что перед этим он определился в главном - что ему нужно. Например, кухонный гарнитур. Тогда в отделе по торговле кухонной мебелью он, вместе с одним из менеджеров этого отдела, составляет дизайн-проект для своей покупки (в соответствии с размерами его кухни и своими пожеланиями), уточняет параметры своего заказа и точно определяется с комплектующими и материалами.
2. "Получение товаров". Клиент идет на склад и сам выбирает все составные части своего заказа, имея точный перечень того, что ему нужно. При этом ему помогают работники склада.
3. "Оплата товаров и оформление доставки". Клиент вместе со своими выбранными товарами (он везет их на тележке) следует к кассе и оплачивает то, что он выбрал. Далее, с оплаченными товарами, он переходит в отдел доставки, где оформляет и оплачивает доставку своей мебели, а также ее сборку (если ему это нужно); после этого он уезжает домой.
4. "Доставка". Оплаченные товары клиенту доставляют в течение трех дней.
5. "Сборка". После этого, если клиент оформил сборку, то к нему приезжает мастер-сборщик и собирает доставленную мебель.

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

Декомпозиция бизнес-процессов

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

Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее – ПО).

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

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

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

Стратегический анализ деятельности компании;

Описание текущего положения и штатной структуры компании;

Описание существующих бизнес-процессов;

Анализ и оптимизация бизнес-процессов, выработка рекомендаций по их изменению, регламентирование деятельности;

Оптимизация штатной структуры компании;

Анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

Создание образцов типовых документов;

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

1.Стратегический анализ деятельности компании

1.1 Обоснование выбора организации

ВкачествеисследуемойорганизациивыбранаООО«Кварта».

Основными направлениями деятельности компании являются:

Разработка программного обеспечения (ПО);

Внедрение и сопровождение программного обеспечения;

Поставка аппаратного обеспечения;

Техническая поддержка.

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

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

Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

Описание организации приведено в Таблице 1.

Таблица 1.Описание организации как объекта управления

Параметр описания	Характеристика
Название, местонахождение	ООО «Кварта», г. Москва
Назначение	Оказание услуг автоматизации для федеральных и территориальных органов государственной власти, бюджетных учреждений, а также для малых и средних предприятий (разработчик и поставщик услуг по внедрению и сопровождению автоматизированных информационных систем (АИС), системная интеграция)
Отраслевая принадлежность	Отрасли третичного цикла Частная фирма Информационные технологии
Правовая форма и вид собственности	Коммерческое предприятие, общество с ограниченной ответственностью, частное
Историческая справка	Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений деятельности, которые впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Непосредственно сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной и исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм собственности. Список предоставляемых услуг постоянно растёт, появляются новые продукты. В планах компании расширить влияние в секторе муниципальных образований и продвижение в регионы. Также компания постепенно расширяет деятельность в секторе коммерческих предприятий.
Организационная структура	См. ниже (Модель «Цепочки ценностей»)
Структура управления	В данный момент компания использует вертикальную систему управления от генерального директора к руководителям структурных подразделений (департаментов), часть из которых выполняет функции заместителей, далее к начальникам отделов и групп. Подразделения поделены по функциональному признаку. В последнее время в связи с большим количеством разнородных проектов, требующих специалистов разных направлений, постепенно вводится практика назначения руководителей проектов (как правило руководители отделов) и планируется серьёзная структурная реорганизация.
Параметр описания	Характеристика
Ресурсы	Основной ресурс – сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению. Репутация в секторе разработки ПО для федеральных органов, рекомендации клиентов. Накопленный опыт, знание до тонкостей специфики работы в данном секторе. Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы. Технические ресурсы: помещения, коммуникации (телефония, широкополосный доступ в Интернет), вычислительная техника, транспорт.
Культура	Высокая мотивация сотрудников, преданность фирме, устоявшийся коллектив, дружественные отношения в коллективе, знание целей и перспектив.
Ключевые факторы внешней среды	Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений. Заказчики: Специфика данного рынка (федеральные органы власти) в том, что на процесс разработки / внедрения дается очень мало времени. Часто через несколько дней после подписания контракта система должна полностью функционировать и быть наполненной информацией. Многое делается по принципу «надо вчера». Как правило, отсутствие единых стандартов, руководство заказчиков часто дает противоречивые указания, диктует собственные условия, часто расходящиеся с реальностью. Ограниченное, часто запаздывающее финансирование. Как правило, платформы для приложений определены заранее, поэтому необходим большой арсенал версий под разные платформы. Конкуренция: Конкуренция высокая, как правило, выигрывает не лучший продукт или предложение, а лучшая протекция со стороны заказчика. Каждый руководитель имеет свои устоявшиеся связи и поставщиков, поэтому часто борьба идет не за конкурентные преимущества, а за протекцию. Новые игроки как правило отсутствуют, конкурируют как правило компании с устоявшейся клиентской базой, по причине того, что в данном сегменте требуется большой опыт и специфическое отношение к заказчикам. Технологии: сильная зависимость от тенденций развития технологий, необходимость следовать за тенденциями рынка, плюс необходимость поддержки большинства актуальных технологий.
Руководство	Генеральный директор, он же собственник: оперативное управление деятельностью компании, консолидированная стратегия, участие в переговорах с ключевыми заказчиками. Также в данный момент есть 3 заместителя, они же являются руководителями основных департаментов компании. Каждый ведет свой круг вопросов в рамках департамента, выработку стратегии своего направления, переговоры и пр. и осуществляет координацию с другими подразделениями.
Параметр описания	Характеристика
Модель «Цепочки ценностей»	Процессы основной деятельности: Разработка: выпуск качественных и функциональных продуктов с максимальным функционалом, необходимым заказчику. Следование новым технологиям и поддержка большого количества платформ. Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов Сопровождение: ключевой особенностью является постоянная поддержка систем у заказчика. Компания никогда не оставляет заказчиков один на один с информационной системой. Как правило при необходимости у заказчика присутствуют сотрудники компании, часто выделяются постоянные представители. Это позволяет существенно улучшить быстроту и качество обслуживания. Поставки: поставка любых аппаратно-программных продуктов различных производителей, настройка, адаптация, ввод в эксплуатацию. Широкие партнёрские отношения с производителями. Предоставление услуг: также компания специализируется на предоставлении услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты. Поиск заказчиков: мониторинг проводимых конкурсов, выбор оптимальных предложений, подготовка конкурсной документации, участие в конкурсах, итоговая документация Процессы вспомогательной деятельности: Разработка систем для внутреннего пользования Поддержка программно-аппаратной части компании Управление персоналом (мотивация, обучение и пр.) Снабжение Внутренний финансово-бухгалтерский учёт Технологические исследования Делопроизводство

1.2 Организационно-штатная структура

Существующая штатная структура организации приведена на Рисунке 1.

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

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

Кадровая служба не существует в виде отдельного подразделения.

Рисунок 1. Существующая штатная структура.

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

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

1.3 Основные проблемы управления

В рассматриваемой организации существует ряд нижеперечисленных проблем управления.

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

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

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

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

Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

Слаборазвитая система отчётов и документирования проектов. Это влечёт за собой недостаточную информированность, а иногда даже частичную незаменимость сотрудника, участвовавшего в конкретном проекте

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

1.4 Постановка стратегических целей

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

Миссия

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

Стратегический профиль

Текущую стратегию я бы сформулировал следующим образом:

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

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

Видение (стратегическое намерение)

1. Какой мы хотим видеть свою организацию в будущем?

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

2. Что из себя представляет наш бизнес сейчас и каким он будет в будущем?

В последнее время бизнес начал быстро развиваться. Количество заказов растет. Но четкого представления о планах и объемах работ нет практически не у кого. 80% времени персонал работает в авральном режиме. Рост внутри компании скорее носит экстенсивный характер (рост объема заказов – существенный рост штата), что не всегда оправдано. Приход новых клиентов часто происходит по принципу - мы слышали от тех-то, что есть такая компания, что у вас хорошие продукты и вас нашли. Маркетинговая политика отсутствует практически полностью.

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

3. Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

Следовать последним тенденциям в области разработки. Провести реинжиниринг в соответствии с требованиями ISO9001 и пройти сертификацию. Повысить качество продукта путем улучшения качества проектирования и ввода многоуровневой системы тестирования. Уделять больше внимания вопросам информационной безопасности. Создать консолидированную систему отчётности и базу знаний. Улучшить качество управления персоналом для повышения эффективности.

Стратегические цели

1. Сроки стратегического планирования.

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

2. Генеральная цель.

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

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

Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

Выделение в отдельную структуру аналитиков и проектировщиков.

Создание единого подразделения разработки программных продуктов с чётким разделением на разработчиков единой интегрированной платформы и структурные единицы по принадлежности к технологическим платформам.

Повысить профессиональный уровень сотрудников

Создать систему обучения вновь принятых сотрудников

Внедрить систему аттестации сотрудников

Организовать процесс повышения профессиональной подготовки кадров

Проведение тематических семинаров

Формализовать процессы.

Разработать должностные инструкции, ввести четкое разграничение полномочий

Перейти к грамотной, качественной и формализованной постановке задач

Организовать процесс документирования производимых работ

Стандартизировать процессы планирования и отчётности

1.5 Анализ и выбор стратегии

Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

Таблица 2.Анализ факторов, воздействующих на достижение стратегических целей

Факторы	Шифр	Содержание	Оценка
Сильные стороны организации	S1		7
	S2		6
	S3		8
	S4		9
Итого	30
Слабые стороны организации	W1		7
	W2	Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям	8
	W3		6
Итого	21
Возможности окружающей среды	O1		7
	O2		9
	O3	Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом	8
Итого	24
Угрозы окружающей среды	T1		4
	T2		6
	T3		8
Итого	18

Таблица 3.Итоговая стратегическая матрица

Сильные стороны организации				Слабые стороны организации
S1	S2	S3	S4	W1	W2	W3
Возможности	S3-O2 Увеличение объемов поставок решений заказчикам S4-O3 Рост количества клиентов S1-O3 Расширение линейки продуктов S3-O1 Практически монополия по ряду поставляемых задач S2-O2 Возможность работы в кредит S4-O1 Возможность получения дополнительных разрешений S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями				W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии W3-O2 Возможность планирования работ заранее, оптимальное использование ресурсов W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий W2-O3 Реорганизация системы управления, поиск профессиональных кадров
O1
O2
O3
Угрозы	S1-T1 Возможность текучки кадров. Повышать заинтересованность, постоянный мониторинг. S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками. S2-T2 выпускать новый продукт раньше, чем конкуренты				W1-T3(Т1) Как можно скорее перейти на более совершенную платформу W3-T1(Т2) Отслеживать состояние рынка, тщательно планировать деятельность W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров
T1
T2
T3
T4

Граф типовых стратегий организации приведен на рисунке 2.

Рисунок 2. Граф типовых стратегий

Выбор и обоснование стратегии

В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

Таблица 4.Выбор и оценка факторов, задействованных в трёх базовых стратегиях

Факторы	Оценка	Реструктуризация (лидерство по издержкам)		Дифференциация		Комбинированная стратегия
		Удельный вес фактора		Удельный вес фактора	Средне-взвешенная оценка фактора	Удельный вес фактора	Средне-взвешенная оценка фактора
S1	7	0,1	0,7	0,1	0,7	0,1	0,7
S2	6	0,15	0,9	0,2	1,2	0,18	1,08
S3	8	0,1	0,8	0,25	2	0,17	1,36
S4	9	0,15	1,35	0,25	2,25	0,2	1,8
W1	7	0,15	1,05	0,05	0,35	0,1	0,7
W2	8	0,15	1,3	0,1	0,8	0,12	0,96
W3	6	0,2	1,2	0,05	0,3	0,13	0,78
Итого	1	7,3	1	7,6	1	7,38
O1	7	0,15	1,05	0,2	1,4	0,17	1,19
O2	9	0,15	1,35	0,2	1,8	0,17	1,53
O3	8	0,15	1,2	0,25	2	0,2	1,6
T1	4	0,2	0,8	0,05	0,2	0,13	0,52
17T2	6	0,2	1,2	0,15	0,9	0,18	1,08
T3	8	0,15	1,2	0,15	1,2	0,15	1,2
Итого	1	6,8	1	7,5	1	7,12

По сумме оценок:

По сумме оценок наилучшей стратегией является стратегия дифференциации.

По реальности задействованных факторов:

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

Выбранная стратегия

Возможные действия в рамках реализации стратегии:

Совершенствование и расширение линейки продуктов

Повышение профессионального уровня сотрудников

Повышение значимости планирования.

Агрессивная маркетинговая политика расширение партнёрских отношений.

Возможные последствия реализации выбранной стратегии

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

К недостаткам можно отнести следующее:

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

Надо очень серьёзно прорабатывать данные вопросы во избежание негативного влияния.

Реализация системы планов. Эффективность изменений

Определение необходимых изменений приводится в таблице 5.

Таблица 5.Определение необходимых изменений

Шифр	Наименование	Вес	7S	Реакция
S1	Сплоченный, высокопрофессиональный коллектив.	0,8	Shared Values	Держать уровень оплаты труда на рыночном уровне, предоставлять бонусы и гарантии. Разработать программы мотивации и повышения квалификации персонала, ввести аттестацию.
S2	Хорошая технологическая база, финансовая независимость	0,7	Skills	Технологическая база должна соответствовать современному уровню, обновлять при необходимости, использовать имеющиеся возможности для привлечения перспективных клиентов (кредит…)
S3	Актуальные инновационные разработки, учитывающие специфику рынка	1,4	Skills	Поддерживать высокое качество продуктов, уделять больше внимания заказчикам. Донести до потенциальных заказчиков преимущества (маркетинговая программа), всегда быть в курсе последних изменений, выводить на рынок продукты раньше конкурентов.
S4	Отличная репутация и долгов время пребывания на рынке	1,7
W1	Две линейки однородных продуктов, одна из которых использует устаревшую платформу	0,7		Отказаться от разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным. Постоянно проводить инновационные исследования и создать непрерывный цикл периодических обновлений.
W2	Низкий уровень менеджмента организации, структура не отвечающая текущим требований	1,2		Реорганизация структуры компании, формализация процессов, ввод в эксплуатацию внутренней информационной системы и рамках неё систем планирования, отчётности и пр. Обучение руководящего состава, привлечение новых кадров.
W3	Отсутствие маркетинговой политики и долгосрочного планирования	1		Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.
O1	Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО	1,4	Skills	Развивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.
O2	Наличие действующих контрактов, необходимых связей, владение необходимой информацией	1,7		Обеспечивать качественное выполнение контрактов с целью их продления, расширения услуг и повышения репутации. Расширять связи с целью своевременного получения информации.
O3	Увеличение финансирования по программе «Электронная Россия», рост ИТ рынка в целом	1,6		Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты
T1	Снижение финансирования госсектора, финансовые потрясения	1,2		Иметь резервные фонды и возможность предоставления услуг в кредит, широкий спектр продуктов и услуг. Поддерживать коллективный дух и корпоративные ценности.
T2	Риск активизации текущих игроков рынка	0,7	Strategy	Вести активный мониторинг рынка. Владеть информацией. Иметь широкую продуктовую линейку с сильными конкурентными преимуществами.
T3	Зависимость от тенденций рынка в области платформ разработки	1		Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

Разработка мероприятий, программ и планов

Планирование

1. Создание плана реорганизации.

2. Планирование рабочего времени сотрудников.

3. Создание маркетингового плана

4. Создание плана обучения и переподготовки персонала

Организация

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

1. Реорганизация имеющихся департаментов и отделов, создание новых функциональных единиц, модернизация нового штатного расписания.

2. Разработка всех технических регламентов и формализация процессов.

3. Написание детальных должностных инструкций

4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

Мотивация

В таблице 6 приводятся показатели качества трудовой жизни.

Таблица 6.Показатели качества трудовой жизни

Показатель	Положение в данный момент
Справедливая заработная плата
Рыночная оплата труда	Присутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, но носит субъективный характер.
Обоснованная дифференциация оплаты труда	В зависимости от должности
Индивидуальная ответственность за результаты общего труда	Присутствует, начиная со среднего уровня, но никоим образом не отражается в оплате труда
Доп. вознаграждение за длительный стаж работы в компании	Фактически отсутствует
Программа дополнительных выплат
Выплата работнику и его семье в случае болезни	да, по базовой ставке оплаты труда
Оплачиваемое время отпуска в связи с праздниками и отпусками	да, в соответствии с КЗОТ
Оплачиваемые отпуска для дополнительного образования	Оплачиваются в случае, если обучение происходит по направлению фирмы
Условия безопасности труда и охраны здоровья	на уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных санитарных норм.
Гарантия занятости
Обеспечение непрерывности трудового стажа	да, в соответствии с КЗОТ
Уверенность работников в своем будущем	Да, стабильная компания, 15 лет на рыке.
Развитие способностей работников	Обучение происходит стихийно или по необходимости.
Социальная интеграция
Социально-психологический микроклимат в организации	Нейтральный. Много как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.
Отношение руководства и подчиненных	Между руководителями подразделений и подчиненными- ближе к демократическому.
Участие работников в управлении производством и собственностью, поощрение инициатив и новых идей	1. Поощрение инициативности сотрудников и внедрение их идей зависит в большинстве случаев от руководителей структурных единиц и их видения ситуации. Т.е. в некоторых подразделениях это поощряется, в некоторых игнорируется и исключается. 2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

Исходя из перечисленных проблем в модели 7S и описания качества трудовой жизни – отсутствует формализованная система мотивации. Введен учёт по времени прихода на работу, но отсутствует фиксация отработанного времени (сотрудники часто работают по 12 часов - но это не учитывается). Отсутствует система определения квалификации сотрудников. Определение вклада в общее дело носит субъективный характер и иногда зависит от личных симпатий. Соответственно, необходимо разработать данную систему и утвердить ее на коллективном собрании сотрудников и учредителей.

Контроль

1. Внедрить в компании стандарты ISO9001, при необходимости разработать собственные стандарты качества. Ввести многоуровневые системы тестирования и контроля качества продуктов и услуг.

2. Разработать систему аттестации сотрудников. Проводить ей с установленной периодичностью. По результатам принимать решение об обучении, премировании, повышении в должности, расширении полномочий.

3. Доработка внутренней ИС компании. Ведение отчетности, контроль выполнения и занятости, сравнительный анализ.

Оценка эффективности предлагаемых изменений

Реорганизация структуры на данном этапе является очень важным шагом к совершенствованию деятельности компании. Реорганизация структурных подразделений позволит существенно улучшить качество выпускаемых продуктов и предоставляемых услуг. Благодаря созданию узкоспециализированных подразделений и четко распределённых между ними полномочий повысится эффективность труда и исключается дублирование функций. Это позволит исключить неэффективное использование времени сотрудников. Внедрение системы управления проектами позволит всегда иметь качественную и своевременную информацию, появится ответственный за результат. В целом при тех же кадровых ресурсах компания сможет выполнять больший объем работ и улучшить качество продуктов и услуг.

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

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

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

2.Анализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

Бизнес-процессы в компании совершенно не формализованы. Для начального описания текущего состояния бизнес-процессов приводятся диаграммы вариантов использования (use-case) в нотации UML. В случае, если деятельность является хотя бы отчасти формализованной, приводятся также диаграммы деятельности в нотации UML, отражающие входную и выходную информацию для процессов, деятельность и роли исполнителей, участвующих в процессе.

Разработка

Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

Постановка задачи;

Разработка;

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

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

Процесс перехода между итерациями

После завершения каждой итерации должен обеспечиваться выпуск очередной версии продукта с определенным объемом функциональности. Достигнутый объем функциональности определяется в соответствии с выполненными работами из первоначального плана.

В результате завершения итерации в хранилище данных по проекту, доступном всем заинтересованным лицам, должны находиться следующие данные:

Пронумерованная версия продукта (библиотеки, исполняемые файлы, база данных и пр.);

Описание функциональности, добавленной по сравнению с предыдущей версией;

Пронумерованные версии всех проектных документов на момент завершения итерации.

Желательно обеспечить сбор статистических данных по количеству взаимодействий на различных стадиях итерации и в различных зонах для последующей оценки результатов.

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

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

Ознакомление с проектной документацией;

Демонстрация программного продукта;

Обучение сотрудников внедрения работе с продуктом.

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

Оценка деятельности

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

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

Документ «Ведомость замечаний» свидетельствует о наличии вопросов и замечаний со стороны исполнителей какой-либо стадии к результатам предыдущей стадии. Чаще всего это также свидетельствует о низком качестве результатов, реже – о недостаточной квалификации исполнителей текущей стадии.

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

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

3.2 Изменения в организационно-штатной структуре

Изменения в организационно-штатной структуре представлены на рисунке 14.

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

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

Все структурные подразделения, занимающиеся разработкой, объединяются в Центр разработки. В том числе выделяется Управление развития инструментальных средств и Управление разработки прикладных систем. Первое подразделение занимается инструментарием для разработки прикладных систем, второе же – непосредственно разработкой прикладных систем. В состав Центра также входит Управление проектирования.

Все подразделения, ответственные за внедрение и сопровождение, объединяются в Департамент сопровождения.

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

Также отдельно выделен Департамент профессионального развития персонала.

Рисунок 14. Новая организационно-штатная структура

3.3 Регламентирование деятельности

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

Регламентированию подверглись в первую очередь следующие процессы:

Оперативный мониторинг и информационная поддержка хода исполнения контрактных обязательств (Регламент приведен в Приложении 2);

Разработка программного обеспечения и выпуск дистрибутивов (Регламент приведен в Приложении 3);

Исполнение заявок на обслуживание и сопровождение (Регламент приведен в Приложении 4).

Регламенты являются определяющими документами при выполнении указанных процессов.

Помимо регламентов, были разработаны типовые должностные инструкции (образец приведен в Приложении 5), а также квалификационные требования к сотрудникам компании (образец приведен в Приложении 6), что позволит упорядочить и организовать процессы, связанные с движением кадров в компании.

3.4 Перспективные направления автоматизации

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

Приоритетными являются нижеуказанные направления.

Информационная поддержка исполнения контрактных обязательств:

Учетные сведения о клиентах;

Реестр контрактов;

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

Кадровый учет:

Штатная структура компании;

Личные карточки сотрудников;

Приказы о назначении, увольнении, отпусках и пр.;

Табельный учет.

Делопроизводство и документооборот:

Входящая и исходящая корреспонденция;

Создание, согласование и утверждение внутренней документации;

Поддержка управления версиями документов.

Информационная поддержка процессов выпуска дистрибутивов и обновлений:

Учет дистрибутивов и стадий их выпуска;

Учет замечаний, реализованных в дистрибутиве;

Учет разовых обновлений;

Учет установленных у клиентов версий дистрибутивов.

Информационная поддержка процессов разработки, внедрения, сопровождения, технической поддержки:

Планирование деятельности;

Учет и отслеживание хода выполнения задач и заявок пользователей, оперативных поручений руководства.

З аключение

Поставленная задача оптимизации бизнес-процессов была решена в полном объеме; оптимизации подверглись основные процессы деятельности организации, а именно разработка, внедрение и сопровождение программного обеспечения.

Осуществлен переход от функционально-ориентированной к проектно-ориентированной штатной структуре компании.

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

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

Разработаны регламенты ключевых процессов: разработки, сопровождения, контроля.

Сформирован комплект образцов документации, создаваемой во время жизненного цикла проекта.

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

Определен ряд направлений, перспективных для последующей комплексной автоматизации с помощью системы управления предприятием.

Список использованной литературы

1.Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. СПб.: Питер, 2005.

2.Бек К. Экстремальное программирование. СПб.: Питер, 2002.

3.Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.

4.Даешь инжиниринг! М.: Издательство Эксмо, 2005.

5.Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

6.Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2002.

7.Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2004.

8.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2003.

9.Хэлдман Ким. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.

П риложение 1

Образцы внутренних документов

Структура документа «Постановка задачи»

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

1. Основные сведения

Название проекта, модуль

Название функциональности

Основания для разработки (контракт, пользователь, законодательство, и пр.)

Необходимость распространения на другие проекты

2. Описание назначения

3. Варианты использования

a. Название варианта использования, текстовое описание, UML-схема

b. Название варианта использования, текстовое описание, UML-схема

4. Диаграммы потоков данных

при необходимости

5. Диаграммы переходов состояний

при необходимости

6. Диаграммы классов

при необходимости

7. Проект пользовательского интерфейса

8. Ограничения

требования к аппаратному обеспечению, производительности и пр.

Структура документа «Заявка»

1. Основные сведения

Название проекта, модуль

Основания для разработки

2. Описание заявки

Текстовое описание содержания заявки, при необходимости – ссылки на скриншоты (для ошибок – обязательно)

3. Скриншоты

Копии экранов с выделенными и пронумерованными блоками (для ссылок в текстовом описании)

Структура документа «Тестовый пример»

1. Основные сведения

Номер заявки (из внутренней системы)

Название проекта, модуль

Название функциональности

2. Тестовые примеры

o Входные параметры: «название» = «значение»

o Последовательность действий пользователя

o Выходные параметры: «название» = «значение»

Структура документа «Описание реализации»

1. Основные сведения

Название проекта, модуль

Название функциональности

2. Описание алгоритма

Общее описание выбранных методов решения задачи

3. Реализация вариантов использования (если были указаны в «Постановке задачи»)

a. Название варианта использования, алгоритм реализации

4. Описание системных изменений

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

o все входные и выходные параметры, а также используемые внутри переменные должны иметь описание назначения;

o код должен быть разбит на логические блоки (при их наличии), снабженные комментариями об их назначении;

o при каждом изменении в начале после описания назначения должен вставляться комментарий с датой, автором и описанием изменения.

b. видимо, в основном для ИИС – перечень измененных классов, гридов, и пр.

5. Описание интерфейсных изменений

при изменении форм – скриншоты «что было» - «что стало» с выделением изменений

при добавлении форм – скриншоты этих форм

6. Диаграммы классов

при необходимости, видимо, в основном для ИИС

Структура документа «Краткое руководство»

Документ «Краткое руководство» составляется в свободном стиле, при этом он должен отражать описание всех вариантов использования, реализованных для требования.

Структура документа «Отчет о тестировании»

Данный документ составляется на основании «Программы и методики испытаний» либо «Тестового примера».

1. Основные сведения

Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

Название проекта, модуль

Название функциональности

Дата тестирования, номер цикла тестирования

Суммарные данные (% успешно пройденных тестов)

2. Тест 1: пройден/не пройден

Должно быть:

o Входные параметры: «название» = «значение»

o Последовательность действий пользователя

o Выходные параметры: «название» = «значение»

Получено:

o Выходные параметры: «название» = «значение»

Комментарии

3. Тест 2: пройден/не пройден

Структура документа «Ведомость замечаний»

«Ведомость замечаний» составляется в двух случаях:

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

2. При внедрении и сопровождении системы.

Структура документа является следующей:

1. Основные сведения

Название проекта

Дата составления, последовательный номер, автор

2. Таблица замечаний

№ п/п

Замечание

Правильно устроенные бизнес-процессы повышают эффективность работы организации. Рассмотрим на примерах, как их анализировать, описывать и оптимизировать.

Определение

Бизнес-процессы (БП) – это последовательность определенных действий, отвечающая следующим условиям:

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

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

Владелец процесса – то самое звено, которое отличает процессное управление от функционального. Функциональные задачи отдельно взятого подразделения часто противоречат задачам другого подразделения или компании в целом.

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

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

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

Группы бизнес-процессов

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

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

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

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

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

Описание и анализ бизнес-процессов в организации: пример

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

Этапы анализа и описания бизнес-процесса выглядят следующим образом:

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

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

В качестве примера регламентированного процесса прилагаем два разных регламента, принятых в малой компании «Альфа».

При описании бизнес-процесса в организации целесообразно придерживаться следующих правил и принципов:

• Ответственным за написание и утверждение БП должен быть его владелец . Это позволит снизить вероятность «саботажа» основными исполнителями, если они не принимали участия в составлении соответствующего регламента.
• Результаты, которые получаются на выходе процесса, должны быть четко сформулированы, измеримы и понятны . Если на объяснение положений регламента сотрудникам уходит много времени, то следует поработать над изменением формулировок в регламентирующем документе.
• Используйте простые схемы . Правила описания алгоритма представлены в любом учебнике информатики для старших классов. Это простой и интуитивно понятный язык. Выбор программы для визуализации процессов не принципиален: можно успешно обойтись стандартными программами пакета MS Office.
• Основное внимание следует уделять наиболее критичным для развития бизнеса процессам. Наука, производство и продажи – это три столпа добавленной стоимости. Нет большого смысла вкладывать ресурсы в контроль работы бэк-офиса, если продажи и производство никак не контролируются.
• Все участники процесса должны быть учтены и прямо указаны . Каждый из них должен знать:
  • что от него требуется,
  • в какие сроки следует выполнять поставленные задачи,
  • как будет измеряться результат его работы,
  • каким будет вознаграждение в случае успешного исполнения
• Используйте простые и стандартные термины и определения. Процесс описывается для сотрудников компании, а не для самовыражения.
• Акцентируйте внимание руководства компании, что самым дисциплинированным исполнителем принятых регламентов должны стать генеральный директор и топ-менеджмент компании. Процесс перестанет генерировать добавочную стоимость, если будет периодически нарушаться руководством компании.
• Контролируйте исполнение положений принятого документа и применяйте дисциплинарные взыскания за необоснованные нарушения.
• Акцентируйте работу на поиске узких мест . На практике приходится сталкиваться с удивительными вещами. Например, новое современное производство не оснастили линией розлива достаточной мощности. В итоге качественные препараты были произведены, но розлив в тару существенно замедлил весь процесс и свел на нет большую часть работы коммерческого департамента.
• Привлечение консультанта для описания и утверждения БП сопоставимо с привлечением высоко классифицированного модератора, но не более. Никто не знает ваш бизнес лучше вас и вашей команды. Бизнес-процесс в организации эффективнее описывать совместно с командой.
• Если процесс «не работает», то уделяйте время анализу причин и внесению необходимых изменений. Методы оптимизации БП хорошо известны:
  • Упрощение (например, когда из процесса исключаются не влияющие на результат звенья);
  • Объединение (исключение дублирующих частей БП);
  • Аутсорсинг (передача исполнения дискретных задач сторонним компаниям);
  • Оптимизация сроков (сокращение или увеличение сроков для регламентированных задач);
  • Стандартизация (например, подготовка шаблонов документов или ввод дополнительных инструкций).

Введение

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

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

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

процессов составила методология SADT. В настоящее время наиболее широко используемая методология описания бизнес-процессов – стандарт США IDEF.

Главное достоинство идеи анализа бизнес-процессов предприятия посредством создания его модели - ее универсальность. Во-первых,

моделирование бизнес-процессов это ответ практически на все вопросы,

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

1 Сущность и значение моделирования бизнес-процессов

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

Существует несколько подходов к определению понятия

«моделирование бизнес-процессов»:

1) моделирование бизнес-процессов - это описание бизнес-

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

2) моделирование бизнес-процессов - это эффективное средство поиска возможностей улучшения деятельности предприятия;

3) моделирование бизнес-процессов - это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;

4) моделирование бизнес-процессов - это метод, позволяющий дать оценку текущей деятельности предприятия по отношению к требованиям,

предъявляемым к его функционированию, управлению, эффективности,

конечным результатам деятельности и степени удовлетворенности клиента

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

6) моделирование бизнес-процессов - это всегда верный способ выявления текущих проблем на предприятии и предвидения будущих.

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

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

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

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

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

Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.

Рисунок 1 - Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты

деятельности компании:

 изменение организационной структуры;

 оптимизацию функций подразделений и сотрудников;

 перераспределение прав и обязанностей руководителей;

 изменение внутренних нормативных документов и технологии проведения операций;

 новые требования к автоматизации выполняемых процессов и т.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

1) существующая организационная структура;

2) документы и иные сущности, используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла;

3) структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

4) диаграммы взаимодействия для конечных бизнес-процессов,

отражающие последовательность создания и перемещения документов

(данных, материалов, ресурсов и т.п.) между действующими лицами.

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

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

Детальная модель бизнес-процесса должна включать:

1) набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

2) диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

3) диаграммы взаимодействия, отражающие схемы документооборота.

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

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

2 Методика проведения моделирования бизнес-процессов

Под методологией (нотацией) создания модели (описания) бизнес-

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

– теоретическая база;

–описание шагов, необходимых для получения заданного результата;

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

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

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

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

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

инструментом реорганизации бизнес-процессов в рамках создания системы автоматизации.

Необходимо учитывать важные характеристики моделирования бизнес-

процессов. В частности, к преимуществам моделирования бизнес-процессов относят: повышение качества и скорости производства продукции с одновременным снижением издержек; рост профессионализма сотрудников;

повышение конкурентоспособности компании. Недостатки, в свою очередь:

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

3 История развития методологий моделирования бизнес-процессов

Основу многих современных методологий моделирования бизнес-

процессов составила методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и

алгоритмические языки, применяемые для разработки программного обеспечения.

В сжатом виде история развития методологий моделирования бизнес-

процессов представлена на рисунке 2. Для наглядности параллельно приведена история развития подходов к управлению качеством .

Рисунок 2 - История развития методологий моделирования бизнес-

процессов

В настоящее время для описания, моделирования и анализа бизнес-

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

 моделирования бизнес-процессов (Business Process Modeling);

 описания потоков работ (Work Flow Modeling);

 описания потоков данных (Data Flow Modeling).

Методологии моделирования бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-

процессов – стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-

процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.).

Методология IDEF0 предоставляет аналитику широкие возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи

различного типа – по информации, управлению, движению материальных ресурсов .

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

настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

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

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий ―Сущность-взаимосвязь‖

(ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных;

IDEF2 – методология динамического моделирования развития систем.

В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе;

IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3

описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая

функция может быть представлена в виде отдельного процесса средствами

IDEF4 – методология построения объектно-ориентированных систем.

Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 – методология исследования сложных систем .

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

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

организационные модели, представляющие структуру системы -

иерархию организационных подразделений, должностей и конкретных лиц,

связи между ними, а также территориальную привязку структурных подразделений;

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

необходимых для достижения поставленных целей;

информационные модели, отражающие структуру информации,

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

модели управления, представляющие комплексный взгляд на

реализацию бизнес-процессов в рамках системы.

Мы рассмотрели основные понятия бизнес-процессов. В данной части мы рассмотрим моделирование бизнес-процессов и приведем пример моделирования.

Моделирование бизнес-процессов

Моделирование – процесс исследования деятельности организации с целью построения формализованного (графического, табличного, текстового) описания бизнес-процессов организации.

• интервьюирование;
• работа с законодательством, документами организации;
• методы мозгового штурма и т.д.

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

Ниже мы рассмотрим пример алгоритма моделирования бизнес-процессов. Итак, для моделирования бизнес-процесса необходимо:

1. Определить результат и владельца бизнес-процесса.
2. Определить набор и порядок действий, составляющих бизнес-процесс.
3. Определить исполнителей бизнес-процесса: на данном шаге необходимо произвести разделение зон ответственности, выделить какие сотрудники каких подразделений несут ответственность за выполнение действий процесса, привязать исполнителей к действиям.
4. Определить события бизнес-процесса. Определить типы событий: начальное, конечное, промежуточное. Привязать промежуточные события к действиям.
5. Определить ресурсы: документы, информацию, и др. потребляемые действиями бизнес-процессов. Привязать ресурсы к действиям.

Схема, иллюстрирующая алгоритм моделирования показана на рисунке ниже:

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

• дополнить существующую модель ответвлениями;
• предусмотреть отдельно действия «альтернативного» процесса.

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

Не рекомендуется анализировать все возможные и невозможные случаи процесса. Ситуациями, не предусмотренными процессом, как правило, занимается функциональный руководитель подразделения (в зоне ответственности которого возникла ситуация).

Для фиксации бизнес-процессов в графическом виде используется система условных обозначений элементов (нотация). Наиболее известные нотации: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. Рассмотрение и сравнительный анализ нотации не входит в предмет обсуждения данной статьи; интересующимся в интернете можно найти массу статей на темы сравнения нотаций, например «IDEF vs ARIS».

Пример описания бизнес-процесса

Приведем пример описания бизнес-процесса. В качестве примера возьмем процесс предоставления неоплаченного отпуска. Рассмотрим порядок и документооборот, возникающий при указанном выше процессе. Метод сбора информации: законодательство РФ как предварительный материал перед интервью с экспертами предметной области и Владельцем процесса. Нотация описания: ARIS eEPC.

1. Сбор исходного материала.

1.1 Предоставление отпуска регламентируется Трудовым Кодексом (при сборе материала необходимо опираться на последнюю редакцию, на момент написания статьи – с изменениями от 30 декабря 2015 г. № 434-ФЗ), статьей 128 Отпуск без сохранения заработной платы

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

Работодатель обязан на основании письменного заявления работника предоставить отпуск без сохранения заработной платы:

• участникам Великой Отечественной войны — до 35 календарных дней в году;
• работающим пенсионерам по старости (по возрасту) — до 14 календарных дней в году;
• родителям и женам (мужьям) военнослужащих, сотрудников органов внутренних дел, федеральной противопожарной службы, органов по контролю за оборотом наркотических средств и психотропных веществ, таможенных органов, сотрудников учреждений и органов уголовно-исполнительной системы, погибших или умерших вследствие ранения, контузии или увечья, полученных при исполнении обязанностей военной службы (службы), либо вследствие заболевания, связанного с прохождением военной службы (службы), — до 14 календарных дней в году;
• работающим инвалидам — до 60 календарных дней в году;
• работникам в случаях рождения ребенка, регистрации брака, смерти близких родственников — до пяти календарных дней;

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

1.2. Документооборот при оформлении отпуска регламентируется постановлением Госкомстата РФ от 05.01.2004 N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты», раздел «Приказ (распоряжение) о предоставлении отпуска работнику».

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

Составляются работником кадровой службы или уполномоченным им на это лицом, подписываются руководителем организации или уполномоченным им на это лицом, объявляются работнику под расписку. На основании приказа (распоряжения) о предоставлении отпуска делаются отметки в личной карточке (форма N Т-2 или N Т-2ГС(МС)), лицевом счете (форма N Т-54 или N Т-54а) и производится расчет заработной платы, причитающейся за отпуск, по форме N T-60 »Записка-расчет о предоставлении отпуска работнику».

Приводим данные, необходимые для моделирования бизнес-процесса (действуем согласно описанной ранее схеме):

1. Результат бизнес-процесса - оформленные согласно законодательству РФ и стандартам организации документы .

2. Владелец бизнес-процесса : руководитель кадровой службы. Как определить владельца? Владелец – это сотрудник, обладающий ресурсами для осуществления бизнес-процесса (в данном случае ресурсы – сотрудники кадровой службы) и несущий ответственность за результат бизнес-процесса.

3. Набор и порядок действий :

написание заявления -> составление приказа -> -> –> .

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

4. Исполнители бизнес-процесса. . Для более наглядного предоставления информации приведем последовательность шагов и исполнителей в таблице:

5. События . Дополним вышеуказанную таблицу информацией о событиях:

№ действия	Входящее событие	Наименование действия	Исполнитель	Исходящее событие	№ след. действия
		Написание заявления	Инициатор
	Составлено заявление на отпуск за свой счет	Составление приказа	Сотрудник кадровой службы	Составлен приказ об отпуске
	Составлен приказ об отпуске	Подписание приказа у руководителя инициатора	Сотрудник кадровой службы
	Приказ об отпуске подписан руководителем инициатора	Подписание приказа у инициатора	Сотрудник кадровой службы
	Приказ об отпуске подписан инициатором	Оформление кадровых документов	Сотрудник кадровой службы

6. Ресурсы, документы и информация . В данном примере мы не учитываем такие ресурсы, как время исполнителей, материалы и оборудование, т.к. нам важны документы, оформленные согласно законодательству РФ и стандартам организации (см. результата процесса). Нам надо проанализировать, какие документы принимают участие в процессе. Дополним существующую таблицу информацией:

№ действия	Входящее событие	Наименование действия	Документ, информация	Исполнитель	Исходящее событие	№ след. действия
	Инициатору необходим отпуск за свой счет	Написание заявления	Заявление на отпуск за свой счет	Инициатор	Составлено заявление на отпуск за свой счет
	Составлено заявление на отпуск за свой счет	Составление приказа	Приказ на отпуск	Сотрудник кадровой службы	Составлен приказ об отпуске
	Составлен приказ об отпуске	Подписание приказа у руководителя инициатора	Приказ на отпуск	Сотрудник кадровой службы	Приказ об отпуске подписан руководителем инициатора
	Приказ об отпуске подписан руководителем инициатора	Подписание приказа у инициатора	Приказ на отпуск	Сотрудник кадровой службы	Приказ об отпуске подписан инициатором
	Приказ об отпуске подписан инициатором	Оформление кадровых документов		Сотрудник кадровой службы	Оформлены кадровые документы на отпуск

7. Проведем анализ «что если».

• Что если заявление будет содержать ошибки (начиная от грамматических, заканчивая неправильным указанием реквизитов)? Инициатор заявления не обязан иметь достаточную квалификацию для безошибочного заполнения заявления (а обязан уметь грамотно выполнять свои непосредственные обязанности). Для устранения случая неправильного заполнения заявления добавим действие проверки заявления в основной процесс, т.к. нам важно предотвратить наличие ошибочного документа в процессе.
• Что если приказ на отпуск будет неправильно составлен? Т.к. в обязанности специалиста кадровой службы входит составление кадровых документов, то мы предполагаем, что в большом количестве случаев приказ составляется правильно. Это не отменяет проверку квалификации специалиста кадровой службы (процессы приема на работу и аттестации) и проведение периодической проверки документов (процесс аудита кадровых документов).
• Что если руководитель не подпишет приказ и инициатор:
  • имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос запишем в открытые вопросы по данному процессу и зададим его Владельцу процесса при согласовании процесса. Всю ответственность за исполнение процесса несет Владелец процесса, именно он определяет правила выполнения работы во вверенном ему подразделении;
  • не имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос также запишем в открытые вопросы.

• Что если инициатор откажется подписывать приказ (например, у него изменились обстоятельства, согласно которым он брал отпуск)? Мы прекращаем процесс.
• Что если внесение отметок в кадровые документы Т-2 и Т-54а будет некорректным? Данный вопрос аналогичен вопросу, рассматриваемому в п. 3.2.

Дополним существующую таблицу полученной информацией. Фактически мы получили предварительное описание процесса в табличном виде:

Открытые вопросы

• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор имеет право на отпуск, согласно 128 статье Трудового кодекса
• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор не имеет право на отпуск, согласно 128 статье Трудового кодекса

Краткое обозначение элементов нотации ARIS eEPC приведено в таблице ниже (описаны не все элементы нотации, а используемые. Графическое обозначение элементов взято из пакета MS Visio):

Схема, отображающая взаимодействие элементов показана ниже:

Графическое отображение процесса предоставлено выглядит следующим образом:

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

Вместо заключения

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

- Не сомневаюсь, ты написал интересную статью. Но к чему такие сложности? Зачем нужны бизнес-процессы, неужели без них нельзя?

- Смотри, бизнес-процессы снижают вариабельность результатов за счет стандартизации операций. Вариабельность означает снижение разброса допустимых вариантов результатов процесса. Я описал простой пример, бизнес-процессы применимы не только к кадровому делу, но и к деятельности организации. Представь себе, что организация, специализирующая на поставке запчастей, будет производить детали с разным уровнем качества (мы помним, что качество – это соблюдение характеристик изделия). Далее автозапчасти будут ставиться на автомобили, и мы получим… продукцию АвтоВАЗа. Продукция АвтоВАЗа находит своего покупателя, но мы в последнее время предпочитаем автомобили качественной сборки.

- Я думаю, все дело в исполнителях. Достаточно найти грамотных исполнителей и мы получим хороший результат. Как в твоем примере – надо найти грамотного кадровика, только и всего.

- Хорошие исполнители, уже обеспечены работой, их труд стоит дорого. Ты не думаешь об оптимизации расходов организации, найма толковых специалистов, и обеспечения специалистов методической поддержкой. Еще один фактор – масштабирование работы. Представим, что в нашей организации работает 2 000 сотрудников. В данном случае у нас будет несколько специалистов кадровой службы и у них будет разный опыт. Наша задача в данном случае – предоставить инструмент обучения, осуществления операций и контроля операций со стороны руководителя подразделения.

- Даже если 2 000 человек и даже если специалисты будут ошибаться. Какова цена ошибки – всего-лишь неправильно оформленные кадровые документы, эти бумажки.

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

Спасибо читателям, что дошли до этого места. Можно было бы многое сказать дополнительно: рассказать про инструменты, используемые при описании бизнес-процессов, подробнее коснуться нотаций… Но это всё продолжение введения в бизнес-процессы.

Евгений Пономарёв

Справочники