BPM: Влияние детства на взрослую жизнь
Исторически так сложилось, что к эффективности бизнес-процессов организации начали подходить с двух совершенно разных сторон: «что автоматизировать?» и «что улучшить в наших процессах?»
Исторически так сложилось, что организации начали подходить к эффективности бизнес-процессов с двух совершенно разных сторон: «что автоматизировать?» и «что улучшить в наших процессах?»
Если в первом случае речь идет о выделении функций, в которых эффективно применимы именно ИТ, то во втором информационные технологии – лишь вспомогательный инструмент, который необязательно будет задействован, а основой являются методическая проработка и организационные меры. Первый подход свойственен ИТ-подразделениям компаний, второй чаще встречается среди топ-менеджмента и бизнес-аналитиков. Думаю, объяснения эта закономерность не требует.
Как и следовало бы ожидать, системы автоматизации управления бизнес-процессами (я сознательно не употребляю термин BPMS, т.к. потребность и первые попытки автоматизации появились несколько раньше, чем оформилась концепция BPM) начинали свой путь из двух различных отправных точек: создание среды для исполнения бизнес-процессов (workflow) и моделирование бизнес-процессов (business process modeling).
Здесь хотелось бы обратить внимание, что исполнение процессов в workflow-системе также требует моделирования, но моделирования только тех процессов и операций, которые протекают внутри системы. С другой стороны, например IDEF0 требует отражать внешние по отношению к объекту моделирования обстоятельства начиная с диаграммы A0. И BPMN, и EPC диаграммы также отражают бизнес-процессы целиком, а не только их автоматизированные (или подлежащие автоматизации) фрагменты. На мой взгляд, именно в этом причина, почему модели из workflow-систем мало помогают реинжинирингу бизнес-процессов, а первые инструменты бизнес-моделирования не развили собственных сильных сред исполнения бизнес процессов.
Думаю, дело здесь не в технических сложностях - они то как раз довольно легко разрешимы, а скорее в подходах к достижению цели. Взять, например, такую: "Сократить срок согласования договоров". С позиции workflow задача решается "просто": заменяем "ноги" и бумагу мгновенной доставкой документа в электронном виде; последовательное согласование заменяем параллельным там, где это возможно; формальные проверки (например, корректность заполнения реквизитов организации в документе) делаем автоматическими и т.п. С точки зрения BPM (того, который "Modeling", а не "Management") интереснее совсем другие аспекты: можно ли отказаться от согласования договоров на небольшие суммы с генеральным директором, чтобы снять с него нагрузку; нужно ли отправлять на рецензию юристу, если текст договора типовой; следует ли уведомлять производственные отделы на ранних стадиях оформления договора, чтобы своевременно актуализировать производственные планы и оформить заказы на поставку комплектующих и другие подобные вопросы.
Вполне разумным шагом было бы совместить эти две грани оптимизации процессов. Технически это было давно сделано в идее business process management, но, по личным ощущениям, рынок еще только-только созревает совершить этот шаг.
Комментарии 9
Хотелось бы добавить - Что делать с человеческим фактором? И мерой ответственности за своевременное принятие или не принятие решений? Поможет ли строгий регламент выполнения процедур? Или опять возвращаемся к системе кнута и пряника?
Мы люди и не что человеческое нам не чуждо!
Александр, не могли бы вы пояснить, что такое SMQ? Если же Вы имели ввиду QMS, то к вопросу управления качеством ERP и BPM подходят принципиально по-разному.
ERP по своему духу смотрит на объект автоматизации, как на монумент, большой, сложный, но не особо подвижный. Поэтому-то консультанты от ERP-сообщества не очень любят обращаться к вопросам качества после внедрения основного функционала - это же придется все процессы (автоматизированные кровью и потом) перестраивать, практически повторять процесс внедрения. А все мы знаем, во сколько "головной боли" обходится внедрение "сертифицированных (вы ведь имели ввиду именно сертификацию, а не просто членство в этой организации, правда?) APICS-ом" систем ;) И даже если бы упомянутые Вами консалтеры вдруг "загорелись" ставить СМК на базе "MRPII и выше", то, например, проектный институт или строительная компания вряд ли восприняли бы эту идею - есть способы подешевле.
BPM же в цикле управления качеством как раз оказывается на своем месте: гибкость моделирования и последующего внедрения измененных процессов лежит в основе этой технологии. И она является вполне самостоятельной, не требует предварительной постановки управленческого учета с автоматизацией "от и до".
Евгений, под SMQ я подразумеваю именно Систему Качества Управления, не Систему Управления Качеством (QMS). Разница, как Вы видите, очевидна, казалось бы, тем более что настройки средств моделирования в ERP QMS является подмножеством контура (или кластера) SMQ. Но вендоры, а в след за ними и консалтеры просто похерили (простите за скабрезность) идеи Хаммера/Чампи в купе с нотациями Йрдона-Де Марко (DFD -технологии) и пошли по пути наименьшего сопротивления. Они просто разработали т.н. "Стандарты качества управления в управленческой деятельности", поставив данную проблему с ног на голову. Что такое "МОДЕЛЬ"? Это всего лишь упорядоченная последовательность тех или иных элементов. Но вендоры и разработчики всегда стоят по разные стороны баррикад, у них разные задачи - одно дело разработать и совсем другое продать. Это проблема вечная. Ну так вот они, "внедренцы", таким вообщем-то не хитрым способом, элементы SMQ cделали подмножеством элементов QMS. И надо быть очень терпеливым и высококвалифицированным заказчиком что бы донести до их разума такую казалось бы простую задачу: внести в "Устав проекта внедрения" требование - PMBOК-и авторитетны, конечно, но только для вас, а мы, заказчики, стратегические карты, матрицы и прочую канитель как-нибудь сами накарябыем. Простой пример из практике: спросите при случае у консалтеров: "Зачем Вы описываете ВP?". На Вас посмотрят как на идиота (в лучшем случае) "Как зачем? Формализируем и напишим ТЗ. А как иначе?". Описание, с последующей формализацией BP, в первую очередь необходима заказчику для проведения АВС (функционально-стоимостного анализа), чтобы решить что автоматизировать, что оптимизировать, что подвергнуть "реинжинирингу", без чего вообще можно обойтись, а что-то и добавить, исходя из простой логике генерации отчета "Учета затрат" или "Фондоотдачи". А ТЗ дело пустяшное, когда знаешь ЧТО автоматизировать и зачем, если СИСТЕМНО к этому подходить. Вот мои пояснения и мое видение разницы и приоритетов SMQ и QMS.
А в остальном, позвольте мне с Вами не согласится и подисскутировать, но чуть позже. Извините, ждут неотложные дела.
Ну что ж, Евгений, продолжим? Вы утверждаете, что ERP по своему духу смотрит на объект автоматизации, как на монумент, большой, сложный, но не особо подвижный. Поэтому-то консультанты от ERP-сообщества не очень любят обращаться к вопросам качества после внедрения основного функционала - это же придется все процессы (автоматизированные кровью и потом) перестраивать, практически повторять процесс внедрения. Вы правы, если о столь неприятных моментах как кровь и пот в сочетании с обращением к вопросам качества после внедрения "основного функционала" (я предпочел бы иную формулировку - требуемого функционала) мы обращаемся до принятия методов, средств и технологической карт внедрения модулей ( и я вновь настаиваю на общепринятой в терминалогии внедрения формулировки - информационных кластеров или фукциональных контуров кому как нравится) SMQ и, что важнее, ERM (управление риском на предприятии - Enterprise Risk Management). Необходимый инструментарий предусмотрен во ВСЕХ ERP системых сертифицированных в стандартах APICS, даже в таких поганеньких как Axapta или Navition (да простят меня разработчики, в недостатках многих систем "их вина не в их вине"). Если Вы, как заказчик, об этом не напомните консалтерам, сами они и "репу не почешут". О какой монументальности и незыблемости ERP межет идти речь, когда Вы должны управляеть рисками?
Далее. "...если бы упомянутые Вами консалтеры вдруг "загорелись" ставить СМК на базе "MRPII и выше", то, например, проектный институт или строительная компания вряд ли восприняли бы эту идею - есть способы подешевле". Простите, но что значит подешевле? CASE покупать? Зачем выкладывать десяток тысячь евро за какой нибудь Power Designer SyBase если он из самого СУБДа не мене чем в пяти конфигурациях "выпиливается". Так что утверждение о дешевизне весьма спорный.
Что же касается: "BPM же в цикле управления качеством как раз оказывается на своем месте: гибкость моделирования и последующего внедрения измененных процессов лежит в основе этой технологии." - грамотное решение."И она является вполне самостоятельной, не требует предварительной постановки управленческого учета с автоматизацией "от и до". Талько вот "Управленческий учет" должен знать заранее что, в чем и зачем мы моделируем, чтоб он потом не "глючил".
Предполагать, что ERP уже внедрена и надо только воспльзоваться ее возможностями нельзя, т.к. на территории России полноценных внедрений - чуть да маленько. Возьмем для примера заказчика, у которого из унаследованных приложений - только бухучет и, скажем, управление проектами. Руководитель компании заинтересован в снижении стоимости работ, повышении скорости выполнения проектов. Никогда этот руководитель не возьмется внедрять ERP-систему только заради того, чтобы понять, где у него делается лишняя работа, а где можно сократить сроки.
В своих рассуждениях Вы этот этап опустили, предположив, что руководиль уже четко знает, что ему нужно изменить для достижения своих целей. По моему скромному опыту, таких руководителей - единицы. Если конечно речь не идет о компании в 20 человек. Большинству же требуется хотя бы минимальное внутреннее исследование (возможно, с привлечением консалтеров или ПО класса BPM), чтобы понять, что и почему сейчас делается внутри компании.
Поймите меня правильно, ERP - это важно и нужно, но для этой задачи не годится.