Вид для печати
Уважаемые дамы и господа, посоветуйте с чего начать описание и разработку бизнес-процессов для повышения управляемости и контроля отдела?
Я делал всё по методическим материалам: описывал "as is" далее "to be". Но такая каша получалась. И как внедрить потом это всё?
Поделитесь опытом, пожалуйста.
На этом сайте есть интересная статья по теме...
http://www.cfin.ru/itm/bpr/work_proc...heduling.shtml
Dias, существует мнение (Елиферов и Репин, цитирую по памяти, могу что-то упустить), что описывать As is не очень полезно:
1. Увеличивается количество информации,
2. При описании to be могут потеряться важные идеи, которые были,
3. И может отбиться у людей желание наконец что-то улучшать.
Подразумевается внедрение через разработку и регламентацию процессов, их согласование (в том числе входов/выходов), затем доработку, разработку рабочих инструкций, утверждение. Затем уже обучение персонала и сбор статистики, возможно, доработка регламентов.
По своему опыту (с IT-шным уклоном), могу сказать вот чего. На "как есть" я трачу очень немного времени, одно краткое поверхностное интервью, не более того (это чаще всего политический момент, "создание локомотива", на котором потом "выезжать" проекту). После того, как выяснено "что нужно", и, собственно, разработки, идёт внедрение, а именно, те же самые обучение, и применение со сбором статистики, возможно, доработка продукта.
Начинать надо "от яйца":
- какие цели, задачи, функции отдела
- какие результаты, риски, задачи и механизмы внутреннего контроля
....
Может так статься, что на корню изменять бизнес-процессы и нет необходимости. Достаточно подгрузить Петю, чтобы он контролировал Васю, Васю контролем Оли, Олю контролем Пети - а самому проверять подтверждения осуществления каждым из них функций контроля за своим соседом.
Это называется segregation of duties.
Хм. Если у вас каша получилась уже при описании процессов отдела, это тревожный сигнал.Цитата:
Сообщение от Dias
Что-то не так в консерватории: либо функции отдела слабо формализованы, либо у отдела нет собственных функций (т.е. он только участвует в сквозных процессах компании). В обоих случаях стоит серьезно задуматься - в том числе и о целях анализа.
Или я что-то не так понял, или одно из двух... :)Цитата:
Сообщение от Andruxa
При описанном вами подходе получается не внедрение, а подгонка компании под предлагаемый вами продукт. Хорошо, если продукт подходит, а если нет?
Теперь я ничего не понял. Что значит подгонка компании под продукт. Кратко спрашиваешь, как работают. Спрашиваешь, чего хотят. Обычно понятно, что "вот это хотим чтобы было автоматически, это хотим по кнопочке, а это показывать так". Продукт разрабывается уже после разборок, "что нужно". Естественно, при этом реорганизуются взаимосвязи и взаимодействие между подразделениями: один продукт дает выход нескольким подразделениям, они меняют не только содержание общения, но и порядок. И я говорил в основном об обучении, и хочу подчеркнуть кстати его важность. После него вся работа по-новому и начинается.Цитата:
Сообщение от Александр Болдин
Думаю, понять можно только если рассмотреть какой-нибудь конкретный проект. Иначе так и будем оба ходить в непонятках.Цитата:
Сообщение от Andruxa
One, статья абсолютно стандартная, ничего интересного там нет. Andruxa, IT последний этап, это первое. Вопрос был в другом, это второе. Genn, согласна. У меня лично это реализовано. Экономист по учету доходов контролирует работу менеджера по выписке первички и старшего кассира. Экономист по закупам - склад. Dias, могу посоветовать только взять бумагу, ручку. Нарисовать схему отдела и разрисовать подчиненность и взаимозаменяемость. Потом положение об отделе, должностные инструкции, положения о ведении отдельных операций (о кассовых операциях, о финансовой документации, о проведении инвентаризаций и проч.). Я дополнительно на переходной период ввела систему планирования загрузки на месяц. Удобно контролировать и сотрудники знают, что делать.
Да, я начал отвечать на вторую часть вопроса, больше чем на первую - именно про внедрение. Выделение процессов - это именно "разгадывание" (может даже и с элементами интуитивного) процессов. Есть рекомендации. Конкретизируйте, какая у вас там "каша" получилась.
(Что-то у вас интерес пропал. текучки насыпалось?:))
Dias, рекомендую опять же Елиферов, Репин, их книгу. У них первая глава - как раз по поводу, как выделять процессы. Вторая - как управлять. Третья - как описывать. Четвертая - как их все увязать (и внедрять). Вот первая глава и четвертая - будут полезны.
Вот поэтому я и возражаю все время против "выделения процессов". Мало того, что от "выделений" хорошего не жди (8~)), так еще за ними сразу приходит "разгадывание".Цитата:
Сообщение от Andruxa
Давайте оставим "выделение процессов" консультантам, порхающим над процессами компаний на высоте птичьего полета, и кидающим с этой высоты советы пирожникам на основе опыта внедрения у сапожников.
:)
пока обедал, догадался, что прилетит такая плюшка :) вот как раз описано, как избежать такого разгадывания, а именно приведено несколько (8 кажется) рекомендаций, концептуально замкнутых, как выделить.Цитата:
Сообщение от Александр Болдин
например: рекомендуется выделять по границам функциональных подразделений, процесс не должен выходить за ЦФО, д.б. не менее, чем создание определенного продукта, имеющего ценность и т.д.
На самом деле, не стоит забывать, что под процессом понимается система мероприятий по созданию некоторого продукта (выхода) из входа с привлечением ресурсов (они всегда есть, осознаны они или нет). Все это измеряется, пусть даже что-то интервально, регламентируется, и управляется.
Как минимум, результатом описания и внедрения, становится управляемая система бизнес-процессов.
p.s. я не консультант вообще-то. просто приходится иногда пользоваться такими "консультантскими" инструментами при внедрении ПО.
Не надо пересказывать мне книгу Е&Р - у меня есть экземплярчик с подписью одного из авторов. Тем более, за время прошедшее с ее выхода, кое-какие позиции авторов могли измениться.Цитата:
Сообщение от Andruxa
Кстати книга получилась очень хитрая - по отзывам можно понять насколько поверхностно ее читали. Если читать по диагонали - складывается впечатление, что авторы предлагают выделять процессы по подразделениям и так далее - то есть оргструктура рулит. Но если читать вдумчиво, а потом еще позадавать вопросы кому-то из авторов (один из них является постоянным участником этого форума), выясняется что нужно границы подразделений выстраивать в рамках происходящих в компании процессов. И опираться надо на процессы, а не оргструктуру.
Оставляю за собой право на собственное мнение - здесь для меня было важно указать на неточность.
к сожалению, прочитал глубоко и вдумчиво. я как раз в своём посте и не занимался пересказыванием книги, а выдержками, и вовсе не для того, чтобы дать возможность указывать на неточности. я вообще-то пишу о том, "что читать", а не о том, "как понимать", и рецензированием не занимался тем паче.Цитата:
Сообщение от Александр Болдин
если хотите обсудить книгу и моё её понимание - давайте поговорим в той ветке, которую открыл я в реинжиниринге.
Почему "к сожалению"?Цитата:
Сообщение от Andruxa
Других таких книг все равно пока нет: одним некогда, у других есть время, но их читать без спецподготовки - себе дороже.
:)
К сожалению - это о том, что уточнение ваше мимо кассы, если оно было адресовано лично мне. я не столько в бесплатных оценках своей "подготовки" нуждаюсь, сколько в "роскоши человеческого общения" по существу.
А книга и действительно отличная.
Тоже хочу автограф.
А в платных? Я бесплатных оценок не даю. .. только намекаю. :)Цитата:
Сообщение от Andruxa
Если "по существу", это уже не роскошь, а мега-роскошь человеческого общения. Какой-то Куршавель :)
Описание процессов под ПО - с этим всё ясно более менее.
А вот описание и анализ процесса (т.е. анализ с целью дальнейшего изменения), с этим уже сложнее. Мне как-то тоже посоветовали не писать "как есть", а сразу - "как должно быть", чтобы избежать тягомотины с анализом и выявлением всяких там причин.
Что касается оргструктуры - если высшее звено управления находится вне процессов, то можете вообще ничего не описывать. Вся картина строится на конечном управленческом решении, которое влияет на тот или иной процесс. И когда руководитель говорит - опиши этот процесс, но меня не включай, то это не подход, а элементарный уход от всего. А дальше больше - за руководителем последуют менеджеры, за менеджерами сотрудники. В результате есть процесс на бумаге - нет в реале.
Спасибо за совет.Цитата:
Сообщение от Andruxa
Такой вопрос: какой инструментарий сейчас популярен для моделирования бизнес-процессов?
ARIS, CASEWISE, BPWIN.Цитата:
Сообщение от Dias
Это - первая тройка. Она не меняется довольно давно.
Есть еще перспективный отечественный инструмент Business Studio.
В его раскрутку в России кто-то вкладывает неслабые деньги... по крайней мере топ-менеджеров уже заинтересовали.
Про CASEWISE не слышал. Надо прочитать про него.Цитата:
Сообщение от Александр Болдин
А он в России представлен года два-три всего. Из пользователей могу навскидку назвать: МТС, Ростелеком, Минэкономразвития, Бауманка, Администрация Ханты-МАнсийского округа.Цитата:
Сообщение от Dias
По всем вопросам надо обращаться в компанию ФОРС (www.fdc.ru) - они являются партнерами CASEWISE у нас.
В конце мая в компании FORS состоится открытый и бесплатный семинар по CaseWise 1/2 дня. Дата пока не определена, где-то между 28-31 мая.
CaseWise тоже, конечно, не идеальное ПО для описания БП, но идеология построения у него более подходящая для этих целей.
С уважением Виталий.
Про идеальные инструменты вообще речь не идет - разобраться бы с необходимым функционалом.
На мой взгляд, темам выбора нотаций и инструментов для моделирования процессов уделяется слишком большое внимание. Как со стороны продавцов программного обеспечения (что логично), так и со стороны менеджмента компаний (что непонятно). Ну не имеет эта тема такого значения в ряду жизненно важных вопросов фирмы.
Могу навскидку назвать более важные темы: например разграничение по функционалу и полномочиям между корпоративным центром и бизнес-единицами.
Без решения этой и аналогичных проблем моделирование бизнес-процессов превращается в "игры разума". Все бы хорошо, но во-первых прямые и косвенные потери от этих игр наносят существенный удар по бюджету, а во-вторых заявленная неадекватная модель надолго блокирует попытки правильного подхода.
Еще раз перечитал свои книжки и не нашел в них категорических фраз с содержанием: "процесс=подразделению".http://www.forum.cfin.ru/images/icons/icon4.gif
1-я книга R&E "Процессный подход к управлению. ..." - есть фразы:
- " принимать во внимание оргструктуру ..." ; " очень часто Процесс не ограничивается рамками одного подразделения..." - (написано было в 2001-2002 г.г. sic!)
2-я книга E&R "Бизнес-процессы. ..." - есть фразы: "Конечно процесс не равен подразделению...", " мы не проводим знак равенства "подразделение"="процесс". (написано в 2003-2004 г.г.)
Это фразы видны даже при чтении "по диагонали".
Не знаю: по какой параболе, эвольвенте или кохлеоиде нужно читать, чтобы увидеть смысл, который авторы не вкладывали? http://www.forum.cfin.ru/images/icons/icon5.gif
С уважением Елиферов Виталий (соавтор R&E и E&R).
я так понимаю, пост мне адресован?Цитата:
Сообщение от eliferov
прошу прощения, но вы ориентировались на пересказ моих слов Александром, а не на мои. я могу говорить про выделение процессов по границам структурных подразделений как рекомендуемое, и все связанные с этим плюсы и минусы (знак равенства и я не ставил, и понимание вашего подхода у меня есть) я не упомянул в этой ветке не для того, чтобы дать повод к дискуссии, а лишь ввиду того, что не счел необходимым в рамках совета "почитать книгу".
А вообще, я имел ввиду первую главу книги "Бизнес-процессы: управление и регламентация".
с уважением, Андрей.
Перечитал обсуждение - слава богу оно небольшое. Не нашел, где бы я как-то интерпретировал ваши слова - везде сплошь цитаты.Цитата:
Сообщение от Andruxa
Может быть, вы имели в виду что-то еще - я не в курсе. Я же ж не Вольф Мессинг. :)
По существу вопроса:
Мы можем получить информацию о процессах компании двумя способами:
1. Пройти назад по цепочке создания стоимости от продажи продукта клиенту до создания этого продукта.
2. Рассмотреть сервисы, которые подразделения оказывают внешним и внутренним контрагентам.
В первом случае мы получим "продуктово-процессную модель", во втором "структурно-процессную". Не судите строго - названия условные, придуманы только что.
Проблема в том, что при создании системы управления на базе процессного подхода мы вынуждены использовать одновременно оба типа моделей. Стараясь по возможности их интегрировать.
Отсюда и проистекают вот такие идеологические трудности. Где выход?
И тут я не скажу ничего нового: нужно начинать с соглашения о моделировании (регламента формирования процессной модели ... есть и другие названия).
Документ должен быть простым и однозначно воспринимаемым всеми участниками проекта. Не стоит вливать в него копи-пастом обширные куски из стандартов моделирования, как это часто делают (у меня сейчас лежит как раз такой проект регламента - ужос). Короткого описания целей и методов их достижения вполне достаточно.
Скорее 2. просто второй этап (вспомогательные процессы).Цитата:
Сообщение от Александр Болдин
А "продуктивная цепочка" звучит хорошо. :)
Александр, а эти модельеры дают какие-нибудь рекомендации по качеству моделей пользователей? Есть ли какой-нибудь анализ графа процессов?
Вопрос конечно интересный :~)Цитата:
Сообщение от Сахават
Какие-то средства проверки связности модели есть практически везде. Но даже в этом случае их трудно применять - не всегда понятно ошибка это или "так и было задумано". Пока что процесс моделирования процессов слабо формализован ... несмотря на наличие кучи стандартов.
Далее Александр приводит ответ, который хотелось бы дополнить следующим соображением. Отчасти определить центр тяжести этих компонент и сбалансировать их по объему использования в построении модели позволяет маркетинговый подход. А именно определение эластичности спроса на выпускаемую продукцию: неэластичный - ориентация на продукт, эластичный - на сервисы для клиента.Цитата:
Сообщение от Александр Болдин
Мое отношение к Маркетингу (с большой буквы) озвучено в другой ветке форума. Не хочу ругаться - замнем для ясности?Цитата:
Сообщение от GRIG
1. Эластичность по чему?Цитата:
Сообщение от GRIG
2. А если продукт это и есть сервисы для клиента? Пример - телекоммуникационные компании.
Не только Вам. Очень многие, из читавших книги, видят, почему-то, только "процесс=подразделение". http://www.forum.cfin.ru/images/icons/icon5.gifЦитата:
я так понимаю, пост мне адресован?
То Болдин
Я бы не сказал, что позиции в чем то сильно изменились. По прежнему главное - объекты управления (процессы,проекты, подразделения, бизнес-единицы), приносящие пользу (доход, маржу, инфраструктуру, соцпотребности) и процедуры (регламенты, стандарты), их описывающие. А также руководители (владельцы, а не собственники), которые управляют этими объектами на регулярной (документированной, понятной, прозрачной, логичной) основе или "по понятиям" (спонтанно, от настроения "левой задней", без планирования и доведения планов до нижестоящих).Цитата:
Тем более, за время прошедшее с ее выхода, кое-какие позиции авторов могли измениться.
С уважением Виталий.
Уважаемый Dias
Во первых, цели, которые Вы обозначили (повышение управляемости, контроль) не факт, что должны достигаться описанием бизнес-процессов. Тем более в рамках одного подразделения.
Бизнес-процессы - это инструмент для устранения проблем прежде всего на стыках подразделений в организации.
Что значит повышение управляемости? Управление - это достижение определенных целей, поставленных перед управленцем. "Повышение управляемости" - что Вы имели в виду? Улучшения статистики достижения целей?
Но улучшения статистики достижения цели можно достигать другими методами. Например, изменением системы мотивации. То есть сильнее поощрять сотрудников за то, что они достигнут цели. Или наказывать сильнее, за то, что не достигли. У Вас работает управленческий цикл по отношению к сотрудникам? Проводятся регулярные аттестации, проводится постановка и оценка достигнутых целей? Может быть Вам надо сначала аттестацию наладить?
Что значит "улучшение контроля"? Контроль - это выявление не соответствия действий сотрудников установленным правилам и нормам. У Вас уже есть установленные правила и нормы? Они контролируются - то есть происходит регулярная проверка соответствия реальной работы правилам и нормам? Возможно Вам не бизнес-процессы надо описывать, а регулярную качественную процедуру аудита запустить.
Может быть вариант, когда у Вас работа вообще не описана - поэтому нечего контролировать. Тогда начните просто с описания работы людей, что они должны делать. Введите нормы - какое количество звонков, например, и начните это регулярно контролировать.
Можно точно говорить, что управление с использованием бизнес-процессов - это более тонкий инструмент, чем описанные выше, и результаты он дает, когда более грубые инструменты уже действует.
Во вторых, если все не так плохо, и описанные выше инструменты (и другие похожие) уже применены, действуют, и речь идет действительно о тонкой настройке.
Тогда совет следующий: для того, чтобы каши не получилось, нам для описания процессов надо выбрать и использовать одну методологию.
Тут есть засада. Обычно путают нотацию и методологию описания. Нотация - это некий язык моделирования, примерно то же самое что русский язык, или английский язык. Просто знать язык недостаточно, чтобы на нем уметь писать стихи. Так же и с нотацией. Недостаточно знать IDEF, чтобы уметь правильно выделить процессы на предприятии.
Обычно методологии разрабатывают консатинговые компании - это и есть их основной продукт. Иногда эти методологии попадают в книги - правда в достаточно упрощенном варианте.
В методологии содержится описание подходов, шагов, действий, которые необходимо сделать, чтобы получилось какое то стройное описание процессов, а не каша.
В частности, Финэкспер, свою какую то методологию имет, которую пропагандирует. Компания ПОРЯДОК также свою методологию проектирования имеет, более подробная информация на сайте www.modellab.ru
Так вот. Рекомендую следующее. Попытайтесь поскать методологии. Если найдете какую - попытайтесь провести описание четко следуя методологии, даже если в чем то с ней не согласны. Если получившийся результат Вас не удовлетворит - то возьмите другую, и сделайте описание точно по ней.
Вероятнее всего на второй-третей иттерации Вы поднатореете настолько, что начнете понимать, что Вам все таки нужно и в каком виде, чтобы решить свои проблемы.
Всего... vbmenu_register("postmenu_70365", true);
Уважаемый Dias, пусть с опозданием, но все-таки хотела бы добавить несколько строк к обсуждению Вашего вопроса. Вот несколько моих практических наблюдений (надеюсь, они будут полезны в работе над Вашим проектом):
1. Каша в описании может получится из-за нечеткого определения цели моделирования. Описать абсолютно все с учетом всех аспектов и точек зрения на процесс невозможно, поэтому приходится накладывать определенные ограничения и выделять значимые и незначимые вещи для описания. И здесь как раз приходится ориентироваться на цель моделирования (подготовка регламентирующих документов, автоматизация процесса, его оптимизация и т.п.). Например, с т.з. автоматизации процесса акцент делается на движении информации, при оптимизации – на выявлении проблемных зон, а при подготовке регламентов нужно максимально подробное описание и взгляд с т.з. исполнителя процесса (т.к. ему потом по этим регламентам работать). Кстати, цели определяют и выбор нотации моделирования и программного продукта.
2. При описании очень важно знать меру! Очень часто возникает соблазн двух видов: а) максимально детализироваться – вплоть до «нажатия кнопочки», а это может быть и не нужно, но сильно усложнит и запутает модель; б) бесконечно совершенствоваться, особенно в модели to be. У меня есть печальный опыт, когда эксперты на протяжении двух (!) лет заставляли переписывать описание одних и тех же процессов и бесконечно согласовывали подготовленные документы, меняя там то по 1-2 слову, то в корне переделывая весь процесс. Результат соответствующий. Умейте вовремя остановиться!
3. При внедрении самое сложное пробить сопротивление персонала и добиться, чтобы процесс действительно заработал по-новому, а не остался на бумаге. И здесь полностью согласна с Andrux’ой – обучение, обучение и еще раз обучение. Важно донести до людей, зачем им это надо, так что опять упираемся в цели моделирования.
Добрый день, я недавно на этом форуме, может, что-то из прошлых тем не знаю, но могу сказать, что взаимодействие с персоналом один из наиболее важных фактов, потому как если люди не понимают, то для них любой процесс будет каша. С сопротивлением сталкиваюсь постоянно, самое худшее, когда персонал устраивает «итальянскую» забастовку. Особенно когда в подразделении есть не явный лидер, которому вообще все новое не по-душе и он начинает дискредитировать проект, таща за собой других. Так как стадный рефлекс развит лучше, чем стремление к совершенству. Плюс присоединяюсь к тому, что излишнее описание не есть хорошо, принцип избыточности тут не подходе, всего не учтешь.Цитата:
Сообщение от Олешко Виктория
Возможно, я повторяю ранее сказанное, но персонал это больная тема всех проектов.