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

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

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

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

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

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

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

 

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

 

Как выделить ключевые бизнес-процессы?

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

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

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

Прежде, чем говорить о выделении ключевых процессов, давайте рассмотрим пример. Возьмем распространенный случай – обработка заказов торговой компании.  С одной стороны, он сквозной. С точки зрения собственника компании, клиент обратился в компанию – он должен получить свой заказ. С его позиции это один процесс. Но наша российская действительность сложилась так (да и не только наша), что предприятия в большинстве своем имеют функциональную структуру. Предположим, в нашем примере заявка от клиента поступает в отдел продаж, затем происходит сборка заказа на складе, после чего служба доставки его доставляет. В каждом таком отделе есть свой руководитель. А это означает, что он полномочен влиять только на процессы своего подразделения.  Он не может нести ответственность за плохую работу другого подразделения. Ведь если служба доставки не успевает вовремя доставлять заказы, нельзя наказывать начальника склада, когда он все делает вовремя и к его отделу претензий нет. Кроме того, система мотивации или показатели эффективности (KPI), как правило, построена именно на качестве работы отдельной службы. И в этом есть логика, согласитесь. Но тогда выходит, что процесс обработки заказа в рассматриваемом примере будет состоять из трех частей: приёмка заказа, сборка заказа и доставка заказа. И в каждом таком процессе будут свои функции. Есть и такой момент: в большинстве IT-проектов Заказчик не станет менять оргструктуру компании, если по мнению консультантов она не является оптимальной.

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

Предполагаю, что на меня сейчас обрушаться критики, пропагандирующие использовать сквозные процессы. Я отвечаю просто: сколько успешных IT-проектов они лично выполнили? Диссертацию одну знаю, в интернете сторонники  такого подхода ее часто цитируют. А примеры проектов? На этом дискуссия обычно заканчивается. Радует, что я не одинок в подходе изучения бизнес-процессов в рамках функциональной модели. К сожалению, данный вопрос выходит за рамки книги. Если интересно, можно прочесть об этом в книге «Бизнес-процессы: Регламентация и управление. Елиферов В.Г., Репин В.В.». где проблематика  раскрывается весьма подробно.

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

Затем каждый бизнес-процесс можно описать детально по функциям. Это можно сделать как графически, так и в текстовом формате. Методика графического описания бизнес-процессов в данной статье не рассматривается. Если интересно, можно кратко ознакомиться в статье «Использование нотации eEPC для описания бизнес-процессов» (в практике IT-проектов графически процессы описывают гораздо реже, чем в консалтинговых проектах, связанных с оптимизацией процессов, организационном проектировании и т.п.).

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

ОЕ	КФ	БП	Наименование  ключевой функции / бизнес-процесса
090			Отдел закупок и логистики
	ОЗ		Обработка заказов
		РЗ	Регистрация заказов
		КЗ	Комплектация заказов
		….	………………..

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

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

Таким образом, в результате предварительной обработке информации раздела «Описание выполняемых функций» мы получим еще 2 полезных документа:

• Классификатор бизнес-процессов (предварительный)
• Перечень вопросов для устного опроса (иногда называют «план опроса»).

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

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

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

 

Первоисточник здесь

Также читайте по этой теме

• Клиентов в баню
• О проектах и процессах
• От саботажа – к проактивности. 13 волшебных вопросов «удачника»