Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Бизнес-философия" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
| ← Февраль 2013 → | ||||||
|
1
|
2
|
3
|
||||
|---|---|---|---|---|---|---|
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
|
25
|
27
|
28
|
||||
Статистика
+1 за неделю
От описания бизнес-процессов к эффективному управлению. Как выделить ключевые бизнес-процессы?
|
Выпуск 13.Добрый день, уважаемые читатели! Я никуда не потерялся, просто завален работой. Еще начал работать над книгой, теперь она точно увидит свет. Рабочее название «Управление требованиями и бизнес-аналитика в IT-проектах». Планирую закончить основной материал к маю, а в июне съездить в солнечные горы Крыма, переосмыслить и подготовить для издания. Сегодня будем говорить о том, как выделить ключевые бизнес-процессы из информации, полученной на этапе анкетирования сотрудников. Напомню, что в качестве результата по предыдущей части мы имеем описанную организационную структуру и заполненные анкеты привлеченных к проекту сотрудников. Но, кроме анкет, мы можем получить и еще один источник информации, потенциально полезный при обследовании деятельности предприятий. Речь идет об управленческой документации. Может ли ее изучение принести пользу в IT-проекте? А конкретно в разработке требований? На практике часто вообще игнорируют наличие или отсутствие управленческой документации в компании. И напрасно. Конечно, часто так случается, что подобная документация носит лишь формальный характер, а на практике работа организована иначе. В консалтинговом проекте данный факт имеет большое значение, т.к. говорит либо о том, что управленческая документация устарела и не соответствует реальности, либо о том, что сотрудники не выполняют установленные регламенты, положения и инструкции. Но это тема другая, сейчас мы ограничимся тем, как управленческая документация поможет в разработке требований к автоматизированной системе. Для начала надо определиться, о каких видах документов идет речь. Это могут быть положения об учетной политике, положения об отделах, различного рода регламенты, должностные и рабочие инструкции, а также прочие документы, регламентирующие рабочую деятельность персонала. Предварительное изучение управленческой документации поможет сформировать определенное представление о деятельности компании и взаимодействиях между собой подразделений и сотрудников. Надо признаться, что часто документация не соответствует действительности, но, полезная информация там есть практически всегда. Если этой информацией владеть заранее, то когда дойдет очередь до изучения анкет сотрудников и устных опросов, можно задать уточняющие вопросы, которые могли и не возникнуть. Много пользы можно извлечь и из должностных инструкций, если они разработаны не просто формально, а для использования сотрудниками в работе. К сожалению, такое встречается не часто. В последнее время в крупных и средних компаниях уделяют достаточно большое внимание регламентам взаимодействия. Подобных регламентов может быть очень много, как и широта охвата деятельности. Может быть описан порядок выполнения самых различных операций, вплоть до обязательности заполнения реквизитов в карточке клиента при занесении его в программу.
Как выделить ключевые бизнес-процессы?Предыдущие два шага (изучение оргструктуры и управленческой документации) важные и полезные, но это ведь только начало. Ведь нам необходимо, чтобы сложилось в голове системное представление о бизнесе компании. Это означает, что и анализировать информацию лучше не хаотично, а в рамках конкретных процессов. Вот выделением этих процессов и надо заняться перед детальным анализом рабочих функций. Поэтому, продолжим анализировать нашу анкету. Следующий раздел анкеты «Описание выполняемых функций» является самым важным с точки зрения понимания принципов функционирования организации. На данном шаге надо попытаться классифицировать существующие бизнес- процессы. Удачно классифицировать бизнес-процессы – задача достаточно сложная. С одной стороны, все кажется просто. Продажи, закупки и т.д. Но такой результат скорее будет носить формальный характер, особенно если он подкреплен схемами в IDEF0 (это не критика, это выводы из практики). Прежде, чем продолжить, сделаю небольшое отступление в сторону данной проблематики. Это важно. Если удачно выделить бизнес-процессы, то это поможет в дальнейшем на всех этапах работ, от разработки требований до внедрения в эксплуатацию. На мой взгляд, существует 2 причины проблемы:
Прежде, чем говорить о выделении ключевых процессов, давайте рассмотрим пример. Возьмем распространенный случай – обработка заказов торговой компании. С одной стороны, он сквозной. С точки зрения собственника компании, клиент обратился в компанию – он должен получить свой заказ. С его позиции это один процесс. Но наша российская действительность сложилась так (да и не только наша), что предприятия в большинстве своем имеют функциональную структуру. Предположим, в нашем примере заявка от клиента поступает в отдел продаж, затем происходит сборка заказа на складе, после чего служба доставки его доставляет. В каждом таком отделе есть свой руководитель. А это означает, что он полномочен влиять только на процессы своего подразделения. Он не может нести ответственность за плохую работу другого подразделения. Ведь если служба доставки не успевает вовремя доставлять заказы, нельзя наказывать начальника склада, когда он все делает вовремя и к его отделу претензий нет. Кроме того, система мотивации или показатели эффективности (KPI), как правило, построена именно на качестве работы отдельной службы. И в этом есть логика, согласитесь. Но тогда выходит, что процесс обработки заказа в рассматриваемом примере будет состоять из трех частей: приёмка заказа, сборка заказа и доставка заказа. И в каждом таком процессе будут свои функции. Есть и такой момент: в большинстве IT-проектов Заказчик не станет менять оргструктуру компании, если по мнению консультантов она не является оптимальной. Причин много, в том числе и уровень доверия к консультантам. При попытке работать в рамках сквозных процессов придется столкнуться с высокой трудоемкостью их описания, сложности согласования (ведь они проходят через несколько подразделений), сложностью управления и массой других проблем. Поэтому, я всегда рекомендую выделять процессы в рамках подразделения (функциональной структуры), как отражающие действительность. Кроме того, это связано и с необходимостью дальнейшей автоматизации операций. Если рассматривать процессы как сквозные, могут случиться такие казусы, когда в один момент времени разные люди должны работать в одном документе (в программе). Предполагаю, что на меня сейчас обрушаться критики, пропагандирующие использовать сквозные процессы. Я отвечаю просто: сколько успешных IT-проектов они лично выполнили? Диссертацию одну знаю, в интернете сторонники такого подхода ее часто цитируют. А примеры проектов? На этом дискуссия обычно заканчивается. Радует, что я не одинок в подходе изучения бизнес-процессов в рамках функциональной модели. К сожалению, данный вопрос выходит за рамки книги. Если интересно, можно прочесть об этом в книге «Бизнес-процессы: Регламентация и управление. Елиферов В.Г., Репин В.В.». где проблематика раскрывается весьма подробно. Поэтому, я поступаю так: в рамках каждого подразделения выделяю группы процессов (они и есть ключевые функции), затем бизнес-процессы для каждой группы. И уже потом каждый бизнес процесс при необходимости можно декомпозировать до рабочей функции. Подобная универсальная трехуровневая иерархия подходит для любых типов проектов. Ниже на рисунке показаны группа процессов и бизнес-процессы внутри группы. Затем каждый бизнес-процесс можно описать детально по функциям. Это можно сделать как графически, так и в текстовом формате. Методика графического описания бизнес-процессов в данной статье не рассматривается. Если интересно, можно кратко ознакомиться в статье «Использование нотации eEPC для описания бизнес-процессов» (в практике IT-проектов графически процессы описывают гораздо реже, чем в консалтинговых проектах, связанных с оптимизацией процессов, организационном проектировании и т.п.). Главное, что я хочу сейчас донести – при изучении раздела с описываемыми сотрудниками функциями нужно попробовать составить предварительный классификатор бизнес-процессов. Он может быть представлен в виде таблицы:
В идеальном случае то, что описывают сотрудники в анкете в разделе «Описание выполняемых функций» как раз и будет перечень бизнес-функций, которые надо сгруппировать по процессам. Но структурно они это точно не опишут (в 1% случаев, не более). В этом и заключается работа консультанта, анализировать и структурировать информацию. Как правило, в процессе анализа выясняется, что есть «подвисшие» функции, непонятно к чему относящиеся, противоречивое изложение одного и того же разными сотрудниками, упоминание сотрудником неких документов, о которых больше никто не говорит и их образцов нигде не приводится и т.п. и т.д. Все подобные вопросы по мере изучения информации следует записывать. Это можно делать как по тексту анкеты, так и в отдельном документе, кому как удобнее. Главное, чтобы не оставалось недосказанности и двойного толкования. Таким образом, в результате предварительной обработке информации раздела «Описание выполняемых функций» мы получим еще 2 полезных документа:
Что касается остальных разделов анкеты, ее стоит внимательно прочитать, но документировать не спешить, так как вероятность неточностей до устного опроса достаточно высока. Используемые системы автоматизации, пожелания к автоматизации, систему документооборота и отчеты лучше обсудить при опросе. Если при просмотре этих разделов в глаза бросились нестыковки, или информации по отдельным вопросам явно недостаточно, включайте это в перечень вопросов на устный опрос. Не надо тратить свое время на фантазии и предположения – они, скорее всего, будут ошибочными или неточными.
|
| В избранное | ||
