формализация бизнес-процессов

1. в своей описывал сам ) но до этого у меня было 2 года практики в проф.фирме ) и учился на базе BusinessStudio. Правда сейчас уже измененную методику использую. С элементами идеологии ACM. Но учился на BusinessStudio. И разобрался в теме именно благодаря этому ПО.
2. сейчас на новом проекте тоже сам описываю. при этом параллельно со мной это делают 2 внешние конторы. обе делают что попало.
2.1. в одном случае бабушка маразматичка выдумала собственную "методологию" описания и не может объяснить что и зачем нужно. сотрудники от нее стреляются.
2.2. во втором случае молодые консультанты которые думают что описание бизнес процессов это рисование схем в нотациях типа EPC.
причем если бабушку уже только магила исправит, то молодежь еще удается вразумить. объяснить им что такое описание процессов и как это надо делать.

У меня ушло 2 года на изучение кучи умных книг. 2 модели написанные как попало.
Первую живую модель процессов написал с 3-го раза и ушло на это 6 месяцев. Тратит около 8 часов в неделю. Допускал крупные ошибки, с опытом приходило понимание, пару крупных блоков приходилось переписывать.

Тут в теме модераторы запрещают давать ссылки. Пишите в ЛС если нужно сброшу 2 ссылки на оба моих проекта. Там есть заметки, наработки и описание методик. Есть даже библиотекта образцов и готовых моделей. Но там платно.

пусть меня ругают модераторы ))
1. вы производственная фирма, потому вам может подойти идеология BPM. инструмент типа http://businessstudio.ru/
2. но в части процессов администрации или управления, закупки, логистика, бухгалтерия, юристы и т д уже нужно смотреть в сторону ACM. мне понравилась вот эта статья http://itau.ru/2011/05/03/chem-vyidelyaetsya-keys-menedzhment/
3. BusinessStudio и ACM - может быть и можно подружить, но я не стал пробовать. Пошел своим путем.

Инструменты
1. Сейчас на одном из проектов использую Word + DIRECTUM. Удобство не очень, зато безопасность.
2. На втором использую 1С Битрикс Корпоративный портал WiKi - наиболее интересное решение для вашего случая. ИМХО.
3. На третьем использую бесплатный Google Sites - это как правило для маленьких организаций подходит из-за страхов и безопасности. Но по функционалу и возможностям рвет все что мной было изучено ранее )

Вот тут делал выброс мыслей в слова по тему http://itau.ru/2011/05/21/protsessyi-organizatsii-opisanie-formalizatsiya-reglamentatsiya-na-primere-printsipov-acm/

Там же готовится библиотека готовых моделей http://itau.ru/groups/tag/%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5+%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2

Елена, здравствуйте!
Описывал по-разному.
Про подходы и проблемы можно говорить долго, но постараюсь вкратце.
Чьими силами описывать?
1. Полностью самостоятельно если:
- в компании имеются специалисты по совершенствованию системы управления и бизнес-процессов. Или имеется возможность приёма с рынка труда таких специалистов. Почему я говорю про совершенствование системы управления? Потому что в ходе "описания" бизнес-процессов и последующего внедрения вы невольно сталкиваетесь с вопросами организационных изменений, изменений принципов принятия решений в компании. Могут быть затронуты самые разнообразные функциональные зоны ответственности - управление финансами, персоналом и т.п.
- в компании есть мощная поддержка этих работ, прежде всего со стороны генерального директора и у "описывателей" не будет проблем с полномочиями.
- проект по "описыванию" долговременный, не менее чем на 1,5 года. А ещё лучше, если компания созрела до понимания, что совершенствование бизнес-процессов и системы управления - это постоянная деятельность, необходимая для поддержания компании "в тонусе". - компания не готова тратить большие деньги на привлечение сторонних консультантов.

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

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

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

Выбор инструментария и программного обеспечения для описания бизнес-процессов, тоже не маловажный момент. Это существенно влияет на восприятие результата и трудоемкость/стоимость работ.
Как правило, внешние консультанты «заточены» под 1 инструмент. Реже 2 и более.
Поэтому желательно оценить, как производится описание, и что получаете на выходе.
Ещё обратите внимание на потенциал инструментария.
Одно дело, когда он позволяет только формировать текстовые регламенты описания бизнес-процессов.
Совсем другое дело, когда вы, описывая бизнес-процессы создаёте комплексную модель деятельности предприятия в самых разных аспектах: стратегия, орг. структура, описание ИТ инфраструктуры, оборудования и т.п. И далее, используете эту комплексную модель для поиска узких мест процесса через имитационное моделирование, стоимостную оценку, расчета потребности в ресурсах (персонале, прежде всего) именно средствами программного обеспечения, на основе созданных моделей.
Важно как это будет доводиться до потребителя – текстовые регламенты будут храниться в какой-либо централизованной системе документооборота или имеется потребность в доступе к графическим моделям, через централизованный Web портал с распределением прав доступа.
Важна территориальная расположенность участников проектной группы и формат их работы. Если моделировщиков бизнес-процессов много, инструментарий должен позволять вести коллективную одновременную работу в единой базе данных.
К сожалению, на рынке не такой уж и широкий выбор программного обеспечения.
Самые распространенные это ARIS, CaseWise, BusinessStudio (в России), ну и конечно народно-ручной инструментарий типа MS Visio/Word и даже Excel :).

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

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

Удачи Вам!
P.S. Кажется вкратце не получилось :)

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

Добавлю, что формализация бизнес-процессов - это инструмент решения бизнес-задачи. Необходимо понять, умеет ли лицо, принимающее решение о начале описания, ставить и решать бизнес-задачи. Так, формулировка: "имеющаяся оргструктура – избыточна, либо результат её работы – недостаточен. Сократить оргструктуру, либо улучшить формируемый ею результат", постановкой задачи считаться не может, это "хотелка", повод для первого обращения к консультанту. А вот он должен поставить задачу, примерно так: "Увеличить долю оплаченных заказов «на выходе» процесса обслуживания клиентов: «Обращение клиента -> Продажа -> Оплаченный заказ» до величины 60–70%, при сохранении заданного уровня рентабельности продаж направления". И отсюда поехали: анализ воронки продаж, определение её "угла наклона", фокус внимания на том, где этот угол наиболее "крут", изучение зон ответственности в этом участке (поиск пересечений или её отсутствие, определение отсутствующих на этом участке компетенций...), затем "размежевание" зон ответственности с помощью процессов, назначение показателей. Затем, организационные предложения: эту рабочую группу передать в подчинение тому-то, этих - поднатаскать побольше в технических вопросах, а вон тех - поставить смотрящими за полнотой и объективностью статистики на входе и выходе воронки продаж. Или вторая задача: "сократить затраты на обучение нового персонала, при... ", "сократить количество ошибок на участке __________ до..., при... " и т.п. Ответ на вопрос, а именно, кто может правильно поставить бизнес-задачу - даст ответ на вопрос, чьими силами будет организовано её решение.

Александр Абрамов, это верно от части. есть еще два нюанса: 1. руководитель может быть интуитом, а не логиком по своей природе. такие люди просто нутром чуют что надо, а объяснить не могут. 2. вы описали точку зрения, задачу или цель руководства. а если посмотреть на это с точки зрения клиента? на сколько ему интересна ваша воронка продаж или затраты на обучение новичков? клиенту нужно чтобы его ожидания были оправданы. это также одна из целей описания процессов. потому можно взять такую задачу: а давайте повысим качество деятельности! удовлетворим и превзойдем ожидания клиента! получим сертификатик типа ИСО 9000 :) Вариантов от куда нам может прийти подача в виде поручения "сделать описание процессов" - очень много. и видно что автор темы эту подачу уже получила. сейчас она просит помочь правильно направить полученный мячик :) Автору, Кстати бабушка-маразматик-консультант до сих пор меня уверяет что описание процессов для целей создания СМК и для проектирования информационных систем - это разные описания ) Не верьте бабушкам ) Модель процессов может быть одна. Хотя каждый процесс может быть описан по разному или сразу несколькими способами. Может быть положение, кодекс, регламент, инструкция, сквозной пример, мультики и т д. Еще вспомнил что уже выкладывал давненько пример описания маленькой модели вот тут http://infostart.ru/public/71738/ Сейчас технология уже существенно шагнула вперед, но базовые идеи остались прежними. Может быть этот регламент поможет вам начать.

Анатолий Юмашев пишет: Александр Абрамов, это верно от части. 2. вы описали точку зрения, задачу или цель руководства. а если посмотреть на это с точки зрения клиента?

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

Анатолий Юмашев пишет:потому можно взять такую задачу: а давайте повысим качество деятельности! удовлетворим и превзойдем ожидания клиента! получим сертификатик типа ИСО 9000 :)

"Качество деятельности" и "сертификатик" - вещи разные, но если клиент отказывается работать без сертификатика, а получение его ну никак невозможно без "описания бизнес-процессов"...:) тогда да, "создать комплект документации, как этапа получения сертификатика" - может рассматриваться, как задача.

Александр Абрамов, > Клиенту, строго говоря, вообще без разницы, организована деятельность компании "на базе взаимосвязанных процессов", или же без таковой вовсе ... вы видели организации от 100 человек, которые умеют удерживать качество на приемлемом уровне без описания процессов? я нет... в остальном согласен :)

Леонид, к Вашему

автор темы эту подачу уже получила. сейчас она просит помочь правильно направить полученный мячик smile:)

считаю своим долгом добавить, что нелишним бывает умение вовремя завернуть назад этот мячик, отказаться от участия в проекте, если нет понимания того, что: (1) автор подачи "по достоинству оценит результат"; (2) он готов реально рассматривать даже самые смелые оргвыводы, а не спрятать голову в песок, как я часто наблюдал. Когда у "автора подачи" априори нет желания понимать, что теперь ЕГО ОЧЕРЕДЬ думать над практической реализацией оргвыводов, вместо соблазнительного делания огульно обвинить описателя "вот, ты наверняка упустил еще какой-то вариант, который не требует столь далеко идущих мер, иди и ещё думай".

Александр Абрамов, да, но опять же есть нюансы :) 1. а может быть я как исполнитель ошибаюсь? 2. модет быть я вывод не правильно донес до автора? Вот в этой статье я рассматривал проблемы внедрения 1С Предприятие http://itau.ru/2011/05/10/1s-predpriyatie-4-klyuchevyie-problemyi-proektov-vnedreniya/ Но на самом деле эти проблемы и особенности свойственны при любых орг.изменениях. Тоже может быть полезно почитать. По своему опыту скажу так. В начале практики меня руководство не понимало. Я вроде весь такой правый и умный. А руководство мои идеи не принимает и все тут ) И кто тут виноват? Руководство? :) Потом прочитал книгу СПИН-продажи и с тех пор мне достаточно изложить свою идею на одном листочке чтобы она получила положительную резолюцию первого лица и все остальные встают по стойке смирно :) Да, конечно, бывают и люди, которые не слышат факты и не желают идти на обострения в отношениях, которые встречаются в таких проектах почти что на каждом шагу. Но тут у меня простая позиция. Я говорю лишь с первыми лицами и лишь тогда когда вижу перед собой сильного человека. Слабых за версту видно. С ними дела не начинаю.

Анатолий Юмашев пишет: Александр Абрамов, > Клиенту, строго говоря, вообще без разницы, организована деятельность компании "на базе взаимосвязанных процессов", или же без таковой вовсе ... вы видели организации от 100 человек, которые умеют удерживать качество на приемлемом уровне без описания процессов? я нет... в остальном согласен :)

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

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

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

Даниил Булычев пишет: 1) Получить набор целей с приоритетами. От клиентов, от акционеров, от топов, от персонала - все они заказчики.

Если интересы топа (генерального) не противоречат интересам акционеров, то да - с ним можно говорить о целях. Если иначе, свидетелем чего я бывал не раз - то никакого разговора о целях с главным топом и остальными топами - не получится никогда, и проекту они будут всячески препятствовать. Ну зачем им нужно, чтобы акционеры узнали о маленькой конторке например, генерального, которая заворачивает на себя часть привлеченных компанией заказов? А "бизнес-цели", высказанные "устами клиентов и простых сотрудников" - это извините, смешно. Директор по производству, на общем совещании топов по целям в рамках внедрения ССП на одном из моих проектов, всерьёз заявил: "я умею лить отличную минеральную воду! могу давать объемы, крупнейшие в регионе, с минимальными потерями и издержками! это я тут главный, а ты, коммерс - мне сбыт - обеспечь!"

Елена Муругова, еще вспомнил про одну статистику :) при всем моем опыте, сейчас занимаюсь проектом формализации процессов в гос.органе. 100 человек. около 50 услуг. уже скоро год как воюем тут ) в неделю на эту задачу уходит около 10 часов. в начале думал что справлюсь за полгода ) но не тут то было ))

Александр Абрамов пишет: Если интересы топа (генерального) не противоречат интересам акционеров ...А "бизнес-цели", высказанные "устами клиентов и простых сотрудников" - это извините, смешно.

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