Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Directum ECM

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

Вы используете

Библиотека

17.08.2011 16:36
  от автора
  Business_Studio

Описание бизнес-процессов. Немного о практическом опыте

Оценки за материал: 4.40 (5)

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

Автор: Станислав Тульчинский, генеральный директор консалтинговой компании b2b.Технологии развития,
tulchinsky@b2b-group.ru
Опубликовано: http://www.businessstudio.ru/procedures/business/bp_descr_practice/


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

С чего чаще всего начинается

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

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

Первую из них менеджеры компании описывают в начальных беседах примерно так: «Наш бизнес за последнее время сильно разросся (увеличился), но что-то в нем стало происходить не так, как было обычно». В качестве беспокоящих проблем обычно называют примерно одни и те же:

  • Возросло количество конфликтов, которые можно разрешить только с привлечением собственников (верховных менеджеров);

  • Непропорционально росту бизнеса возросли затраты, но совершенно не понятна причина этого;

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

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

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

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

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

Несколько замечаний по постановке задачи

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

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

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

Третьей проблемой является надежда на то, что новая программа MRP, ERP, CRM, SCM, BPM, DFM и т.д. и т.п. (зачастую флагман западной экономики), которая (со слов ее продавцов) является неиссякаемым источником мудрости и референсных моделей бизнеса, после внедрения сотворит чудо. И бизнес сам изменится в «правильную» сторону. Увеличатся доходы, будут выбраны правильные сегменты рынка, сократятся издержки и конфликты между сотрудниками. Но, как говорят продавцы «волшебной» программы, для того, чтобы ее внедрить, надо описать процессы.

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

Важное замечание про оптимизацию

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

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

И проблема даже не в том, что само слово «оптимизация» сложно и непонятно. Сама мысль об улучшении (оптимизации), которое должно принести избавление, а далее по списку, "у кого что", понятна всем. Проблема в том, что важен критерий оптимизации: что именно и насколько хочется улучшить путем допустимых изменений. И, как правило, если с тем «что улучшить» проблем не возникает (обычно после напоминания): «точно, нам нужно сократить время выполнения бизнес-процесса, его стоимость, улучшить качество обслуживания», то со всем остальным в большинстве случаев очень туго.

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

Описанный логический тупик может поставить большой «крест» на самой идее об описании бизнес-процессов (в обойму вставляется второй патрон для верности). Хотя на самом деле ситуация с изменениями в ходе оптимизации не столь фатальна, как она видится заказчику. Можно подобрать решения, которые в рамках существующих (не мнимых) ограничений позволят достигнуть некоторых целей. Остается определить отношение цены/качества – устроят ли они заказчика.

Переход на новые (оптимизированные) процессы

Как уже было сказано, описание бизнес-процессов, скорее всего, приведет к тому, что в компании нужно будет что-то изменить. Либо сам сложившийся уклад деятельности сотрудников, их взаимоотношений, порядок общения, либо продукты/услуги, либо рынки, либо клиентов компании, а скорее всего в некоей пропорции все из описанного. И очень часто это становится неприятной новостью. Описанные бизнес-процессы сами по себе не работают. А сам заказчик, сотрудники компании, и, тем более, менеджеры компании не готовы и не стремятся к тому, что что-то еще надо сделать. Действительно, ведь плохо или хорошо, но компания работает, что-то зарабатывает, а что будет, если все поменять? Никто не знает. А это усугубляет то, что первоначальная задача «просто описание бизнес-процессов» точно не включает в себя разработку программы по переходу на новые процессы. Бытует упрощенное мнение: «примем одним приказом по компании новые регламенты с первого числа, и все заработает». К моменту окончания описания процессов становится понятно, что приказом не получится. Изменений много, не все их понимают, не все к ним готовы, не хватает многих составных частей для перехода (например, надо поменять ИТ систему, внести изменения в инструменты, оснастку, инфраструктуру, переобучить персонал). И инвестиции в описание и оптимизацию бизнес-процессов списываются на убытки.

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

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

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

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

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

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

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

Поверхностный анализ Интернета показывает, что данная тема (выбор методологии и инструментария) недостаточно освещена (анализ META Group мало того, что больше ориентирован на IT-решения, так еще и практически не учитывает особенностей Российского рынка, рассматривает только типичных представителей сложившегося западного рынка). Наиболее часто встречаются статьи сравнения методологий ARIS и IDEF. Другой наиболее распространенной темой является перечисление сильных и слабых сторон (обычно методологий) без учета того, применительно к какой задаче эти качества анализируются. Становится несколько странно: неужели, например, грузоподъемность грузовика всегда является неоспоримым преимуществом, независимо от того, для чего я выбираю машину?

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

  • CA ERwin Data Modeler (ранее называвшийся AllFusion Data Modeler, BPwin). Наиболее удачно реализована возможность описания взаимосвязанных сложных моделей, задачи описания алгоритмов и последовательности действий реализованы заметно слабее. Простые (лаконичные) нотации описания. Сложно, либо вообще никак не реализуются дополнительные задачи (увязка целей и процессов, создание дерева показателей, проведение имитационного моделирования);

  • ARIS (набор программных обеспечений, модулей компании IDS Scheer). Само название (Architecture of Integrated Information Systems) говорит о том, что программное обеспечение изначально было ориентировано на решение задачи описания алгоритмов и последовательности действий. Все остальное в ARIS тоже можно делать, но это будет получаться очень непросто. Для описания бизнес-процессов придётся использовать большое количество моделей (в ARIS их более 80, и количество их растет) достаточно сложной семантики, в которой путаются даже наиболее ярые адепты. Без большого опыта и существенного переосмысления основ методологии реализовать сложные описания взаимосвязанных моделей непросто;

  • Corporate Modeler (Casewise Systems) во многом является английским более юным аналогом ARIS - не по методологии и решениям, но по самим идеям1 ПО. Также ориентировано на помощь в описании бизнес-процессов для последующей разработки программного обеспечения. Но стоит оно в среднем дешевле;
    iGrafx Enterprise Central (подразделение Corel Inc) пока менее известное в России, но очень симпатичное решение из Канады. Включает в себя целый набор модулей по описанию, моделированию процессов, приложения по планированию и управлению качеством управлением рисками. Существенным ее минусом является ее нераспространённость;

  • Business Studio (ГК «Современные технологии управления»). Наиболее известная российская разработка из семейства рассматриваемого ПО. Пожалуй (на наш частный взгляд), удачно совмещает (насколько это возможно) некоторые наиболее полезные возможности BPwin и ARIS, чем-то напоминая по своему решению iGrafx (но не по стоимости). Если для заказчика важно соотношение цена/возможности, наверное, это оптимальный выбор для российских предприятий. Имеет один недостаток, так как очень плотно интегрирована с MS Office (Word, Excel, Visio), а поэтому все шероховатости этих решений автоматически переносятся и на Business Studio.


Что может получить заказчик

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

  • Из умной книги (ведь «еще Портер писал что-то про это, а у нас этого нет!») или во время обучения, например, на ставшей сейчас модной степени МВА;

  • От ИТ директора или продавцов дорогих информационных систем («эта программа точно решит все проблемы, посмотрите на список успешных компаний, которые ее используют, в этом есть заслуга программы, но для ее внедрения надо описать процессы»);

  • От молодого и энергичного зама, который тоже ее где-то услышал и успешно «продал» своему шефу, не донеся самых главных ее нюансов.

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

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

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

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

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

  • Бизнес существенно подвержен внешним и/или внутренним рискам;

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

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

Не лучшее решение

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

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

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

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

Что можно порекомендовать

Как можно не совершать описанные в статье ошибки? Все очень просто. Нужно так не поступать. Попробуем чуть подробней описать, а что надо сделать, с точки зрения автора. Ниже приведен список задач, которые стоит решить (или начать решать), прежде чем будут выделены основные деньги (ресурсы) и приобретено специальное программное обеспечение, появятся новые люди и нарисуют первые «квадратики», напишут первые строки регламентов. Так как это только самое начало возможного проекта по изменениям, то никто нам не мешает потратить немного больше, чем это принято, времени, и подумать о том, что и как компания хочет получить и сколько она готова заплатить. Для этого стоит, как минимум, сделать следующее:

  • Определить какие именно бизнес-задачи (бизнес-показатели) бизнес хочет улучшить. Чего на самом деле заказчик хочет достичь, задумывая изменения в своем бизнесе? Для этого, вполне возможно, нужно будет переосмыслить видение бизнеса;

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

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

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

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

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

_____________________

1 «Для каждого существующего продукта будет разработан такой же аналог, интегрируемый с решениями SAP. Этим будет заниматься отдельное подразделение в нашей компании. Поэтому, можно сказать, что мы выходим на новый сегмент рынка в мировом масштабе — нашими клиентами станут заказчики SAP». Из интервью Бернарда Фишера, Президента компании Casewise.

Комментарии

Оценки: /
17.08.2011 19:52
  от автора
  Репин
Спасибо автору за статью! Но есть некоторые критические замечания

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

"...Третьей проблемой является надежда на то, что новая программа MRP, ERP, CRM, SCM, BPM, DFM и т.д. и т.п. (зачастую флагман западной экономики), которая (со слов ее продавцов) является неиссякаемым источником мудрости и референсных моделей бизнеса, после внедрения сотворит чудо. И бизнес сам изменится в «правильную» сторону. Увеличатся доходы, будут выбраны правильные сегменты рынка, сократятся издержки и конфликты между сотрудниками. Но, как говорят продавцы «волшебной» программы, для того, чтобы ее внедрить, надо описать процессы..."
- опять же, руководители бизнеса - реалисты. Они чуда не ждут, но хотят при внедрении новой ИТ-системы сохранить лучшие наработки и оптимизировать неэффективные процессы за счет новых возможностей системы. Если они этих возможностей не видят, то систему не будут внедрять. Бывает, конечно, что внедряют необоснованно, но такое внедрение обусловлено факторами другого рода (внешние требования акционеров и т.п.).

"...Начнем с того, что определиться с тем, «насколько улучшить», бывает весьма сложно, потому что в организации, как правило, такие «мелочи», которые указывают в «что улучшить», обычно просто никак не измеряются...".
- зачем эти "мелочи" измерять, если собственников устраивает результат бизнеса? Если мы их не измеряем, значит они не так важны для организации. Например, часто вы измеряете уровень тормозной жидкости в бачке автомобиля? А уровень бензина в баке? Вот и вся разница. То, что реально критично для бизнеса меряем, остальное - от лукавого. Намерить можно много всего, только это будут стоить хороших денег. Пример. Внедряет компания 1С-8. Операторы, которые вводят заявки клиентов и выставляют счета используют недостаточно удобные отчеты, тратят лишнее время. Если мы им в настроим новую систему так, чтобы они тратили меньше времени, это будет оптимизацией процесса? Не факт. Будет в том случае, если мы в итоге сократим количество операторов. А сократить мы их не можем, т.к. они по 2 сидят в офисе (для взаимозаменяемости). Что тогда? Сократив время обработки заявок, чем порадуем клиента и повысим оборачиваемость по ГП. Да, наверное. А если клиенты и так в очереди стоят за продуктом? И т.д. и т.п.

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

"...Наиболее часто встречаются статьи сравнения методологий ARIS и IDEF...."
- ну, это песня из 98-2002 годов. Сейчас это никого не интересует реально. Народ уже погружен в BPMN, ACM и т.п.

"...Все остальное в ARIS тоже можно делать, но это будет получаться очень непросто. Для описания бизнес-процессов придётся использовать большое количество моделей (в ARIS их более 80, и количество их растет) достаточно сложной семантики, в которой путаются даже наиболее ярые адепты. Без большого опыта и существенного переосмысления основ методологии реализовать сложные описания взаимосвязанных моделей непросто..."
- не то, чтобы я любил ARIS , но этот тезис некорректный. В АРИСе вполне можно рисовать вменяемые модели в eEPC с настроенным фильтром, не использую все остальное. Другое дело, что он достаточно сложен в освоении, формировании отчетов и его схемы не воспринимаются BPMS.

"...Corporate Modeler (Casewise Systems) во многом является английским более юным аналогом ARIS - не по методологии и решениям, но по самим идеям..."

- как то совсем скупо про этот продукт. ИМХО, лучший продукт из "тяжелых" западных по части BA.

В целом, не понял, о чем статью. Фокуса не увидел.
ИМХО, заказчик нынче не тот, что 10-12 лет назад. Не стоит держать его за идиота
Оценки: /
18.08.2011 09:57
  от автора
  Дмитрий Пинаев
>>Народ уже погружен в BPMN, ACM и т.п.
Некоторый народ в некоторой Москве?

На мой взгляд статья показывает реальность. И нельзя винить автора за то, что реальность такова .

Оценки: /
18.08.2011 11:36
  от автора
  Тульчинский
Спасибо автору за статью! Но есть некоторые критические замечания

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

1. За «спасибо» скажу «пожалуйста». Но есть некоторое удивление по ряду Ваших замечаний. Владимир Владимирович, уважаемый, как же так? Что ж, получается, Вы отказываете мне в моем опыте? Я с удовольствием бы узнал, как Вы построили систему продвижения у себя в компании, что к Вам приходят только те, кто «давно так не считает». К сожалению, у меня работа так складывается (но это вовсе не отрицает Ваш опыт, а видимо говорит о том, что просто либо рынок, на котором работаю я другой, либо я не столь удачлив в продвижении, нежели Вы) как написано. Статья была написана («о чем статья. Фокуса не увидел») именно о некотором сложившемся (в моем понимании) тренде. Не написав ее, например я бы не узнал, что вот есть достаточное количество клиентов, которые отличаются, что я их просто видимо не вижу. А вы говорите Фокуса нет.
2. Вот за что я не люблю экзекютив так это за однозначность суждений. Скажите мне, честно, вот то, что Вы пишите это 100% единственное решение? А где же право на ограниченную рациональность, желание попилить бюджет, «корпоративные игры», просто право на заблуждение? Наверное, Вы просто не продолжаете общение с теми клиентами, кто не столь однозначен как Вам нужно? Я к сожалению пока не готов к такой жесткой позиции, что если они этого не разделяют: «руководители бизнеса - реалисты. Они чуда не ждут, но хотят при внедрении новой ИТ-системы сохранить лучшие наработки и оптимизировать неэффективные процессы за счет новых возможностей системы. Если они этих возможностей не видят, то систему не будут внедрять», то я сними работать не буду
3. «зачем эти "мелочи" измерять, если собственников устраивает результат бизнеса?»
Увы и тут похоже мне не удалось донести основную мысль. К сожалению, в половине компаний, с которыми мне приходится сталкиваться не умеют считать просто прибыль, маржу, операционные затраты. Не говоря уж о том, чтобы их посчитать в разрезе клиента или продукта. А потому вопрос не так абсурден, как мне приписывается: посчитать все на свете, включая «время обработки заявки». Согласитесь, что когда в начале проекта по описанию БП заказчик, например, ведет разговор про повышение эффективности по итогам работы, то хотелось бы, чтобы клиент умел ее (эту эффективность) считать, а иначе надо сначала с ним научиться это делать? А то, что Вы пишите про 1С, так тут я более чем согласен с Вами. Я даже иду дальше. Если все так всех устраивает и все так однозначно, то вообще зачем менять 1с7 на 1с8? Оставьте все как есть?

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

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


5. "...Наиболее часто встречаются статьи сравнения методологий ARIS и IDEF...."
- ну, это песня из 98-2002 годов. Сейчас это никого не интересует реально. Народ уже погружен в BPMN, ACM и т.п.

Так и тут у меня лично не все однозначно. Мне именно в Москва наиболее часть приходится сталкиваться с желанием подискутировать кто круче арис или что-то иное 

- не то, чтобы я любил ARIS , но этот тезис некорректный. В АРИСе вполне можно рисовать вменяемые модели в eEPC с настроенным фильтром, не использую все остальное. Другое дело, что он достаточно сложен в освоении, формировании отчетов и его схемы не воспринимаются BPMS.

Помилуйте, уважаемый Владимир Владимирович! Про арис Вы пишите, насколько я понимаю, в своем посте именно то, что и я. Насколько я понимаю, что написано Вами ранее (как в посте, так статьях, книге) говорит о том, что: описание набора моделей ПРОЦЕДУР в eEPC не дает возможности описать ВСЮ модель БИЗНЕС_ПРОЦЕССОВ предприятия без потери существенной информации. И необходимы специальные, не предначертанные eEPC методикой усилия, либо привлечение иных диаграмм и нотаций (начиная с VAD и далее по списку). Только почему-то Вы считаете что я некорректен.

6. "...Corporate Modeler (Casewise Systems) во многом является английским более юным аналогом ARIS - не по методологии и решениям, но по самим идеям..."
- как то совсем скупо про этот продукт. ИМХО, лучший продукт из "тяжелых" западных по части BA.

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

7. В целом, не понял, о чем статью. Фокуса не увидел.
ИМХО, заказчик нынче не тот, что 10-12 лет назад. Не стоит держать его за идиота

Увы мне. Но все же я считаю, что Вы несколько максималистски расставили точки над «е». Я исхожу из убежденности, что заказчик это живой человек, гораздо более сложный, чем конечный автомат («идиот» или «реалист»). И он (заказчик), прежде всего человек, профессионал в чем-то своем (например, в бизнесе) и ему, по целому ряду причин совершенно простительно ошибаться в нашей с Вами, достаточно узкой сфере деятельности. А потому неплохо об этом как минимум нам помнить в своей работе, чтобы самим случайно не ошибиться, например, приняв заблуждение заказчика за его реальную позицию. А как максимум обмениваться мнениями и опытом (которые априори не доказуемы и интересны именно своим разнообразием ) с коллегами.
С уважением, Тульчинский
Оценки: /
18.08.2011 12:12
  от автора
  Репин
Спасибо за подробный ответ!

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

С уважением,
Владимир Репин
Оценки: /
18.08.2011 14:54
  от автора
  Тульчинский

Насчет специалистов по описанию БП, скорее соглашусь с Вами, они стали появляется. Особенно в Москве. В регионах с этим значительно хуже. Но тут есть один нюанс, связанный с тем, что специалист по описанию БА он же человек не простой , он развивается и совершенствуется не только познавая новые возможности ПО, но и в других измерениях. Я разделяю обычно на несколько уровней качественного развития таких людей:
• Некий начальный уровень исполнителей, которые знаю основные подходы и инструмент по моделированию, но нуждаются в четкой «нарезке» процессов и задач;
• «Модельеры» способные по поставленной задаче разработать общую модель, выделив основные процессы, определить критерии оптимизации и организовать работу БА;
• Специалисты способные взглянуть на бизнес своими глазами, понять чужую (например, менеджерскую на цели бизнеса вообще, а не только в терминах внедрения 1С) точку зрения, выявить основные ограничения системы для поставленных целей, оценить сами цели, а далее прописать «рецепт» - программу, которая может как включать моделирование и оптимизацию (в классическом понимании описания БП), так и нет.
Так вот мне кажется, вы говорите больше о первых. А я, в первую очередь, говорил в статье о третьих, в моем списке. И как раз отсутствие грамотных голов, а не технических специалистов приводит к тому, о чем я написал в статье.
Зачастую как раз наличие инициативного «технаря» без «головы» приводит к описанному, когда какое-то «лекарство» (будь то внедрение 1с, иди описание процессов) вдруг принимается за конкретную «программу лечения», панацею. А дальше пошло-поехало: «все переходят на 1с8, и это всем помогает. В чем? Да во всем»
Я конечно несколько утрирую, но в каждой шутке есть доля шутки
С уважением, Тульчинский
Оценки: /
18.08.2011 15:33
  от автора
  Репин
Не нравится мне аналогия с "лечением" и "рецептами". Клиенты - не больные, наоборот. (Да и больные умудряются вытянуть из государства несколько ярдов на программы реконструкции ).

"...Специалисты способные взглянуть на бизнес своими глазами, понять чужую (например, менеджерскую на цели бизнеса вообще, а не только в терминах внедрения 1С) точку зрения, выявить основные ограничения системы для поставленных целей, оценить сами цели, а далее прописать «рецепт»..."

- это качества хорошего бизнес-аналитика. А плохие кому нужны?
Оценки: /
18.08.2011 19:54
  от автора
  Тульчинский
Не относитесь слишком предвзято. Это же всего лишь метафоры не описывающи ни чего плохого или хорошего, а эмоциональную окраску к ним добавляете Вы сами Так сказать по вкусу и прошлому опыту.

А по поводу «плохих» БА: я бы взял, будь я точно уверен в том, что они походят под мое описание первого и вторых типажей. Точно бы взял человека 3-4 второго типажа, и 6-7 третьего. По сути, приходится и более неопытных подбирать, в надежде что хотя бы часть их них до 2 (я уж не говорю про второй или третий) типажей дорастет. Но чего только не сделаешь для сбалансированных проектных команд…
Оценки: /
25.08.2011 12:21
  от автора
  Evr1981
До чего же интересно!

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

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

Спасибо.
Оценки: /
25.08.2011 21:03
  от автора
  Репин
Эту тему лучше обсудить на форуме, имхо
Оценки: /
26.08.2011 10:30
  от автора
  Тульчинский
«Вот за что я люблю вас, новозеландских пареньков, так это за незамутненность сознания»(С)


Уважаемая инкогнИто, а почему бы и не четко и не конкретно? Если Вам интересно стать специалистом ну натурально по ОПИСАНИЮ БП, то я бы советовал начать с того, что:
1. Нашел и попытался прибиться к команде (только тут важно, чтобы это была не орда неофитов, а команда с приличным прошлым опытом, структурой, пониманием ведения проектов) и поработал бы с ней от года, чтобы понабраться практики.
2. В зависимости от того, что это за команда, к которой Вы прибились, достаточно будет для начала почитать либо МакГоуэна, либо те заклинания, что уважают новозеландские пареньки из Шиира, ну либо новомодные соглашения о моделировании складывающихся стандартов (например, BPMN).
3. В принципе для начала этого будет достаточно для того, чтобы зарегистрироваться на около специальных сайтах и со знанием дела рассуждать о том, что BPM и BPA это одно и тоже, или наоборот, а также ругать всех остальных (кто не использует Ваш инструментарий) и называть их презрительно КОНСУЛЬТАНТАМИ.
4. Большинство останавливается именно на п.3 Но некоторые отчаянные идут после этого чуть дальше и читают, например, книгу господ Репина и Елиферова (весьма неплохое чтение для неофитов, желающих расширить свой кругозор), опять же в ней есть библиография. Самые пропащие идут и далее, читают, например, Шука и Ротера и уж особо отмороженные Харрингтона, Оболенски, Хаммера и Чампи и далее (появляется множественность по настроению) без остановок.

НО, для того, чтобы нормально ОПИСЫВАТЬ процессы достаточно пп. 1 и 2. Так как ОПИСАНИЕ БП это прежде всего соглашение о моделировании, опыт и общение с наставником, ну и знание азов теории систем управления.
К сожалению все перечисленное выше не гарантирует, что Вам удастся стать толковым бизнес-аналитиком. Скорее даже наоборот. Особенно после п.3
Я старался быть максимально четким. Правда, не знаю, насколько это Вам поможет.
С уважением, Тульчинский
Оценки: /
26.08.2011 19:02
  от автора
  Репин
"...а также ругать всех остальных (кто не использует Ваш инструментарий) и называть их презрительно КОНСУЛЬТАНТАМИ..."

- оценил юмор - пять баллов!

"...читают, например, книгу господ Репина и Елиферова (весьма неплохое чтение для неофитов, желающих расширить свой кругозор), опять же в ней есть библиография. Самые пропащие идут и далее, читают, например, Шука и Ротера и уж особо отмороженные Харрингтона, Оболенски, Хаммера и Чампи и далее (появляется множественность по настроению) без остановок..."


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

Согласен, что опыт на первом месте. Но чтобы систематизировать этот опыт и развиваться, надо методически "подковываться"...
Оценки: /
01.09.2011 15:48
  от автора
  Evr1981
Спасибо, Вячеслав!

Отдельное спасибо Вам, Владимир Владимирович!
Оценки: /
23.10.2012 10:07
  от автора
  Kirill.Kichichidi
Спасибо, Станислав.
Всё верно.
Не далее как на предыдущей неделе ко мне подбежали сейлы: "N хочет ARIS!! Готовим!"
Попытка разобраться зачем N хочет ARIS и как видит свой бизнес привела к глухому молчанию.
N не знает сам. N насмотрелся презентаций.
И вот как сказать потенциальному заказчику, что он ещё совершенно не зрел для таких дел?

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

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

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений