Что необходимо знать об IT-системах для функционального и процессного управления

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

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

Постановка проблемы

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

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

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

Альтернативой узкофункциональным автоматизированным системам являются интегрированные, или корпоративные системы, и в первую очередь системы класса ERP.

Исторически системы ERP появились как результат эволюции систем планирования материальных и производственных ресурсов (MRP – MRP II), когда к этим ресурсам добавили ресурсы финансовые (бухгалтерию, в широком смысле этого термина) и человеческие (управление персоналом). Это позволило говорить о комплексном планировании всех ресурсов предприятия, что и зашифровано в аббревиатуре ERP – Enterprise Resource Planning.

Концепция ERP оформилась в начале-середине 1990-х годов, и тогда же появились и реализующие ее программные продукты. В дальнейшем рамки концепции постепенно расширялись, включив взаимоотношение с заказчиками (CRM) и поставщиками (SCM), управление техническим обслуживанием и ремонтами и т.д.

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

Но общие данные – это необходимое, но недостаточное условие слаженной совместной работы: надо позаботиться и о непрерывность потока работ. И такая попытка в рамках ERP была предпринята: по всем канонам, внедрение ERP должно сопровождаться обследованием предприятия, анализом и оптимизацией бизнес-процессов и реализацией их средствами ERP.

Только вот незадача: на тот момент (начало-середина 1990-х) понимание того, как надо управлять бизнес-процессами, сильно отставало от современного. Это была эпоха реинжиниринга – период технократического идеализма:

1) проанализируем наши процессы (as-is),

2) спроектируем оптимальный бизнес-процесс,

3) разработаем план перехода,

4) реализуем его,

5) Profit!

Проект внедрения ERP ложился в эту схему идеально.

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

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

Способность оперативно менять свои бизнес-процессы – это определенная культура внутри организации, это наличие процессной компетенции и это определенные инструменты, которые способны в этом содействовать. Так вот – выяснилось, что ERP в качестве инструмента процессного управления является скорее пассивом, чем активом.

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

Это стало очевидным к началу 2000-х, и в ответ на этот вызов появилась концепция BPM – Business Process Management. Эту концепцию трактуют по-разному, мы в Comindware, придерживаемся трактовки, изложенной в классической книге Смита и Фингара «Business Process Management: The Third Wave» (2003). В ней BPM подается как целостный подход к управлению бизнес-процессами в замкнутом цикле моделирование-исполнение-анализ с опорой на новый класс информационных систем – BPMS.

Аббревиатура BPMS у Смита и Фингара расшифровывается как Business Process Management System, но в настоящее время приято ее расшифровывать – Business Process Management Suite, поэтому пусть вас не удивляет словосочетание «система BPMS», которое мы будем использовать.

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

Ценность BPMS в том, что такие системы полностью соответствуют современной концепции управления бизнес-процессами: они поддерживают замкнутый цикл проектирование-исполнение-анализ, за которым снова следуют перепроектирование, исполнение и т.д. (По сути это цикл PDCA Деминга).

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

Таким образом, BPM на основе BPMS обеспечивает органичное единство технологии, методологии и принципов реализации проектов.

Сравнение ERP и BPM как инструментов управления:


ERP

BPM

Методологическая основа

Реинжиниринг: as-is/to-be, план перехода от текущего к оптимальному состоянию

Непрерывное усовершенствование: процессы оперативно изменяются вслед за меняющимися потребностями бизнеса

Технологическая основа

СУБД: моделирование, хранение, поиск данных в единой базе данных, пользовательские интерфейсы к ней, запросы и отчетность

BPMS: моделирование бизнес-процессов, процессный движок и пользовательские интерфейсы к нему, анализ результатов исполнения процессов

Подход к реализации

Водопад (Waterfall) или Большой взрыв (Big Bang): однократный проект

Маневренная разработка (Agile): программа, т.е. серия проектов разного масштаба, реализующих как радикальные преобразования, так и эволюционные усовершенствования процесса

Спрашивается: что мешало ERP-вендорам реализовать передовой опыт управления бизнес-процессами в своих системах?

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

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

Так или иначе, но факт тот, что прогресс в технологиях управления бизнес-процессами пошел не по пути перевода ERP-систем на новую, процессную архитектуру, а по пути создания нового класса ПО – BPMS.

С архитектурной точки зрения, BPMS отличаются от ERP и других корпоративных систем тем, что это – не готовое приложение для конечного пользователя, а платформа – среда, в которой можно описать свои процессы и превратить их в исполняемую систему, которая будет раздавать задания исполнителям (сотрудникам организации), вызывать функции автоматизированных систем, обрабатывать события и правила и т.п. С этой точки зрения BPMS аналогична СУБД, которая также представляет собой универсальное средство создания приложений для любой предметной области.

Задача заменить ERP или другие прикладные информационные системы перед BPMS не ставится. Оптимальным является сочетание тех и других: ERP отвечает за поддержку функционального управления, BPMS – за поддержку процессного управления. В предыдущей части мы писали, что процессное управление не отменяет, а дополняет функциональное, компенсируя его издержки. То же самое мы видим и на уровне ПО: не замена, а дополнение и органическое сочетание.

Такое разделение выгодно для обеих сторон.

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

На практике это выглядит так: бизнес-процесс и, как следствие, требования к ПО, меняются быстрее, чем консультанты по внедрению и программисты способны их реализовывать при разумных затратах.

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

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

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

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

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

Выводы

Итак, оптимальное технологическое решение для реализации сочетания функционального и процессного управления – это оставить ERP только автоматизацию функций, а кросс-функциональные бизнес-процессы реализовать в BPMS. При этом, очевидно, возникают задачи интеграции.


Этот текст опубликован в рамках конкурса «Большая игра-2014» ― литературного состязания авторов, работающих в жанре Non fiction. Номинация «Менеджмент». В конкурсе могут принять участие авторы, зарегистрированные в Сообществе менеджеров E-xecutive.ru (независимо от срока регистрации), приславшие свои публикации на content@e-xecutive.ru с пометкой «конкурс Большая игра-2014» и указанием номинации в поле «Тема письма», или выложившие их на портал самостоятельно с пометкой «конкурс Большая игра-2014, номинация такая-то» в период с 10 февраля по 1 декабря 2014 года включительно. Подробнее об условиях и призовом фонде узнайте из описания конкурса «Большая игра-2014».

Источник изображения: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Нач. отдела, зам. руководителя, Москва
Алексей, информации мало от Вас. Попробую понять логику вопросов, если ошибаюсь поправьте:
Алексей Зуев пишет: Уже есть ИТ инфраструктура, прописаны процедуры, народ обучен работать. Но тут как всегда внезапно изменились условия и всё надо срочно менять
Алексей Зуев пишет:Ему интересна система, которая быстро и дешево отреагирует на условия ведения бизнеса.
Алексей Зуев пишет: особенно в крупной организации. Есть ли живые примеры?
Алексей Зуев пишет: Я ожидал, что кто-то возмет и размажет мои домыслы. '' А у нас в организации владельцы\\боссы\\ключевые стейкхолдеры прозрели, вдохновили народ на непрерывные изменения и дело пошло''
Приоритеты как то расставьте, и если есть готовый софт, то внешние или внутренние разработчики, или те и другие. Не про бухгалтерию конечно спрашиваю :). P.S. Выскажу на первый взгляд крамольную мысль :) надо вначале доказать, что компании необходим процессный подход. Здесь важен и масштаб операций и требования к адаптивности. Дело в том, что большинство Крупных российских компаний не дотягивает по Масштабу Операций до западных, и требования к адаптивности бизнеса для них очень высокие ... Процитирую известного в нашей стране специалиста по процессному подходу Тимура Кадыева;
Дело в том, что процессный подход – это заточка на эффективность, а не на адаптивность. Адаптивность – это функциональное управление, оно лучше адаптируется к изменениям. Когда каждый день новая ситуация и еще неизвестно, что типично, а что уникально - какой здесь процесс?
Эгу статью можно легко найти найти в Интернете
Нач. отдела, зам. руководителя, Москва

Виктор, мне кажется, Вам надо начинать не с BPM, а с архитектуры. Например с классической Захмановской. В ней есть место не только бизнес-процессам.

Заход ''зачем нужен BPM, если он не дает ответов на все вопросы'' выглядит как попытка взять ''на слабо''. Не возьмете ;)

Менеджер, Москва
Анатолий Белайчук пишет: ''непонятно как перейти от ''зоопарка'' к ВРМS, особенно в крупной организации'' - автор вообще-то этого не предлагал. Автор считает зоопарк в каком-то объеме неизбежным. Бороться с ним можно и нужно, победить - невозможно.
Тогда, пожалуйста, поясните вступление ''Во многих крупных организациях можно наблюдать разобщенность IT-систем. Анатолий Белайчук называет это «информационным зоопарком» – такое положение дел сложно назвать правильным. Как лучше интегрировать корпоративные системы – читаем в статье для конкурса «Большая игра-2014».''
Нач. отдела, зам. руководителя, Москва

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

Коллеги, извиняюсь, что влезаю в ваш спор, но это высказывание идет строго вразрез с современным BPM-мейнстримом. Разумеется, если новая ситуация прямо уж ''каждый день'', то это не BPM, а скорее ACM или даже PM. Но зачем же бросаться в крайности? BPM - это адаптивность в масштабе, скажем, от дней до месяцев. Причем если что-то меняется каждый день, то вовсе не обязательно это должны быть изменения эпического масштаба. А ''допиливать'' процесс с частотой раз в неделю, временами повышая частоту хоть бы и до раза в день - дело нормальное и полезное.

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

PS. С работами Тимура Кадыева и с ним самим не знаком, извините.

Нач. отдела, зам. руководителя, Москва

''Тогда, пожалуйста, поясните вступление''

Легко: вступления пишет редакция, в основном с целью завлечения, и с авторами их не согласует.

Давайте будем читать текст, если Вы не возражаете.

Менеджер, Москва
Александр Соловьев пишет: Приоритеты как то расставьте,
Александр, некий сумбур получился в результате хода дискуссии :) Приоритет банальный и практический - нужно обосновать, что BPM - это не всё, что BPM-ом зовется. Основная проблема - адаптивность процессов в неповоротливой ИТ-инфраструктуре, а также решить ряд вопросов по социализации.
Александр Соловьев пишет: Выскажу на первый взгляд крамольную мысль :)......
Ничего крамольного не усматриваю. Вопрос в том, что уже первый шаг на 100% невыполним. Всегда будет часть (самая продающая и\\или выпускающая), где не то что адаптивность, формализация крайне затруднена, а персонал слабо дисциплинирован. И всё это баламутство должен уметь подхватывать бэк-офис. Вот тут вроде и требуется ВРМ. Но на больших масштабах это практически не работает ИМХО.
Менеджер, Москва
Анатолий Белайчук пишет: Легко: вступления пишет редакция, в основном с целью завлечения, и с авторами их не согласует. Давайте будем читать текст, если Вы не возражаете.
Ок, собственно это и вызвало недоумение.
Лидия Сергеева Лидия Сергеева Директор по продажам, Ставрополь
Анатолий Белайчук пишет: Претензии же к автору уважаемой Лидии Сергеевой - это вообще нечто!
Нда… Евангелисты нынче пошли… Хотя! Савонарола (технически) тоже был евангелистом… Вы, Анатолий, если хотите, чтобы вас понимали правильно, излагайте свои мысли яснее, тогда и недоразумений не будет. А так… Нагенирили такого, «просто нечто», выражаясь вашим языком. Однако препираться по мелочам скучно. Давайте по-взрослому - сразу к вашей «жизнеутверждающей» табличке, где сравнивается «концепция ERP и BPM». Методологическая основа: в ERP некое разовое изменение, в BPM «непрерывное усовершенствование». Это надуманное утверждение. Ключевой особенностью ERP систем является интеграция или интегрированность. И как методология, и как идеология. Проще говоря, ЕРП – это единая база. Именно это лежит в основе. При этом, НИЧТО не мешает (ни технология, ни идеология) управлять изменениями, которые возникают в процессе развития организации, и которые впоследствии находят свое отражение на уровне автоматизированной системы. Или вы готовы назвать примеры ERP-систем, когда по закрытию проекта такая система передается заказчику на условиях того, что в дальнейшем внесение изменений будет невозможным – что выросло, то выросло? [COLOR=green=green]Развивается система или нет, зависит не от того ERP она или BPM, а от качества менеджмента в организации.[/COLOR] Вы же, утверждая обратное, манипулируете своей «паствой», при этом довольно вульгарно. Технологическая основа: в ERP – СУБД, BPMS - моделирование бизнес-процессов, процессный движок и пользовательские интерфейсы к нему… Тут сразу надо к основам, учить матчасть. СУБД – это инструмент. Система управления базами данных, как бы... Можно было бы назвать развитие СУБД драйвером развития ERP, что вы и сделали, но это не означает того, что СУБД – техническая основа ЕРП систем, а БПМ основаны на чем-то другом. БПМ системы в тех же целях и таким же образом используют СУБД. Я вам больше скажу! Не все ERP-системы отказываются работать без СУБД… Я не понимаю, почему [COLOR=green=green]некая технологическая особенность обозначена вами в качестве корневого отличия, при том что фактически это даже не так.[/COLOR] Подход к реализации: Водопад (Waterfall) или Большой взрыв (Big Bang) в ERP и соответственно Маневренная разработка (Agile) в BPM Как вам, возможно, известно, любой уважающий себя вендор, написавший свою ERP, кроме собственно программного продукта, разрабатывает еще и методологию его внедрения, как правило, используя в качестве основы стандарты PMI. У меня был некий опыт в этом смысле, и я знаю, что у SAP есть AcceleratedSAP, у Microsoft - Microsoft Dynamics Sure Step, у 1С – ТСКФ, где, кроме прочего, описаны и корпоративная технология внедрения, и ТБР (аналог эджайл). Надо сказать, что собственно разработка эджайл как один из методов содержится ВО ВСЕХ методологиях, более или менее известных разработчиков ERP-систем. Противопоставлять на этом основании ЕРП и БПМ – это… (запрещено декларацией сообщества:)) Но и это еще не все. Я не понимаю, зачем вы все это пишите, если в большинстве случаев актуальные версии флагманов рынка ERP содержат функциональные модули BPM (тут необходима табличка «сарказм»). То есть не надо беспокоиться, все включено… Возможно, вы хотите сказать, что система самостоятельная будет более функциональна? Ну, да, возможно. Но это, извините, вопрос религиозный. На рынке BPMS представлена масса поделий, где якобы расширенный функционал уступает стандартным, типовым, модулям в ERP. Нет, бывает, что и превосходит, но вопрос ведь не в этом! Вы же не предлагаете обсуждать функциональность. Вы говорите о том, что концептуально было бы логично выделять BPM в отдельное решение… Почему? Ну, по трем причинам: 1. ERP продукт неизменямый 2. Техническая основа ERP – это СУБД (поганка такая) 3. ERP внедряют через какие-то ужасные энтерпрайз методики, то ли дело BPM с его гибким эджайлом… В общем, это не зоопарк (хотя вот так он и начинается – с таких вот сомнительных проповедей), это – цирк. И при всем при этом я не являюсь сторонником того, что ERP – самое правильное, самое прогрессивное и самое эффективное решение. Скорее, даже наоборот. Меня просто немного раздражает, когда люди пытаются продать может быть даже хорошие вещи ВСЕМ, а не тем, кому они нужны. Я понимаю, у вас профессия такая – проповедовать… Ну, ок. Только имейте ввиду, что среди публики попадаются и атеисты.
Профессор, Чебоксары
Анатолий Белайчук пишет: Заход ''зачем нужен BPM, если он не дает ответов на все вопросы''
Уважаемый автор, я то, что выше, не писал :-) Я написал следующее: Зачем нужна BPM, если она не может строить модели и соответственно не может ничего дать для управления. '' Хорошо бы узнать, какие модели процесса обучения в школе можно получить с помощью BPM? Я надеюсь, что факторы и целевые функции процесса обучения в школе Вы представляете.
Нач. отдела, зам. руководителя, Москва
Алексей Зуев пишет: Приоритет банальный и практический - нужно обосновать, что BPM - это не всё, что BPM-ом зовется.
Мне тоже хотелось бы сказать как и Анатолию ''легко'', но … потом посмотрим :) Можете рассматривать просто как пример решения, т.к. не собираюсь здесь никого учить :) Да, и чтобы ещё не отрываться от обсуждения статьи, и быть ''ближе'' к той части аудитории, которую Вы обозначили как ''(самая продающая и\\или выпускающая), где не то что адаптивность, формализация крайне затруднена, а персонал слабо дисциплинирован'' ... В статье упоминается ''По сути это цикл PDCA Деминга'' …. А как всё реально работает в японских методах? Вначале Будем говорить о двух циклах :) SDCA (Standardize – Do – Check – Action).- это как раз то что называется циклом контроля за процессом и его совершенствования (Кайдзен) а цикл PDCA можно считать ближе к инновациям (Инновации). Подчёркиваю, что в контексте примера - ключевой момент Инновации Надо же будет потом ещё выделять, где нужно использовать BPMS :) Сразу оговорюсь, что можно, конечно, придираться и говорить о медленных инновация (или усовершенствованиях). Но для нашего обсуждения эти споры о тонкостях в терминологии будут только мешать …Например, когда автор статьи пишет:
Ценность BPMS в том, что такие системы полностью соответствуют современной концепции управления бизнес-процессами: они поддерживают замкнутый цикл проектирование-исполнение-анализ, за которым снова следуют перепроектирование, исполнение и т.д. (По сути это цикл PDCA Деминга)
. - и упоминает только PDCA – это не его ошибка, а издержки монополии ИСО 9001 на нашем и западном рынке. Понятно, что два цикла должны чередоваться. Инновации - Кайдзен - Инновации - Кайдзен … PDCA – SDCA – PDCA – SDCA - Это было вступление, … но получается слишком долго :). Чтобы ускориться -> 1) для обозначенной аудитории будет хотя бы интуитивно понятно, что они работают над созданием ценностей для клиента. 2) начинать нужно каждый раз не с бизнес процессов, а с Цепочки Создания Ценностей -> или в нашем контексте Инноваций в цепочке Создания Ценностей (проектировании, усовершенствовании, ). (Было бы более правильно говорить Сети, но уж так повелось - цепочке :) P.S. как и утверждаете ''не всё, что BPM-ом зовется. :)'' Такой подход всё намного упрощает, и ваши работники могут более плотно включиться в работу, Теперь по поводу адаптивности -> когда начинаете с Инноваций в цепочке создания ценностей, может появиться возможность уже не следовать за изменениями рынка, или даже формировать его и т.п. Для клиента что важно? – Ценности. Кстати, объекты управления сразу найдёте, процессы выявите, а это бывает проблемой … А использовать процессный подход или функциональное управление это уже выбор компании.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Уровень счастья напрямую влияет на продуктивность большинства россиян

При этом почти каждый четвертый респондент считает, что их руководитель ничего не делает для счастья сотрудников.

70% россиян отмечают сильное влияние работы на уровень стресса

Наибольший стресс создают строгие дедлайны, внезапные и большие объемы задач, а также собственные ошибки при выполнении задач.