Что необходимо знать об 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
Комментарии
Директор по продажам, Ставрополь

Отвратительный осадок после прочтения этой статьи. Поставила минус.
1. Неряшливость в терминологии, влекущая за собой дальнейшие логические ошибки (например, под ''зоопарком'' на ИТ-сленге подразумевается не противоборство смежных подразделений, а использование для решения одной задачи сразу нескольких методов решения - часто противоречащих друг другу). ERP как некая монолитная система не может породить ''зоопарка'', она поражает хаос другого порядка, вызванный другими причинами и имеющий другие следствия.
2. В первой части предлагается совершенно надуманное противопоставление - ерп и бпм. Это просто абсурд. Но для пущей забористости добавлено еще и про эджайл. Это всего лишь метод разработки или метод работы с проектами. Выбор метода не зависит от класса продукта....

Нет, не могу. Это прописные истины уж совсем. Куда это годится, публиковать такую фигню, правда, а? Я понимаю, там есть многозначительные аббревиатурки, но не до такой же степени!

А Виталию Елиферову респект, безусловно!

Нач. отдела, зам. руководителя, Москва
Алексей Зуев пишет: Или есть иные примеры?
Вы же сами тут же приводите пример ->
Алексей Зуев пишет: Тех же CIO трансформируют в CPO
Предполагается, что CPO уже знает проблемы, или думает что знает :) Взаимодействие с конечными пользователями, конечно, предполагается. P. .S. Посмотрите по ссылке на программный продукт в начале статьи, что имеет в виду автор, и ''зачем'' так критикует ERP системы :)
Нач. отдела, зам. руководителя, Москва
Михаил Кузнецов пишет: Я уже дал в сл. предложение пояснение
А мне стало понятно что имелось в виду, сам не обратил внимание.
Нач. отдела, зам. руководителя, Москва
Алексей Зуев пишет: Причем тут начинание с нуля?
Для меня это самый интересный вопрос :) Специалисты всегда имеют некие представления и опыт в предшествующих проектах. Кроме того ''багаж'' того, что называют референтными, эталонными моделями, или отраслевыми решениями. И всё это в конечном итоге и используется, т.к. времени начинать всё с нуля нет. Поэтому глупость часто дублируется :( в новых проектах ... Основная проблема в том ,что часто приходят люди, которые не знают логистику, а это интегральный инструмент Менеджмента, раздёргивают всё на отдельные бизнес-процессы, а компания теряет всё что раньше заработала тяжёлым трудом. Вот даже здесь в этой дискуссии люди не знающие логистику пишут о ERP как системе ''Только для сбора и обработки информации ...'' :) Я знаю о недостатках ERP, но сравнивать ERP систему , которая используется как интегральный инструмент менеджмента с технологией OLAP, которая на автомате может входить в ERP систему вместе с используемой СУБД … :) Не надо мечтать о карьере CPO -> гораздо перспективнее стать CKO (Chief Knowledge Officer)
Менеджер, Москва
Александр Соловьев пишет: Вы же сами тут же приводите пример
Ну какой это пример? Я ожидал, что кто-то возмет и размажет мои домыслы. '' А у нас в организации владельцы\\боссы\\ключевые стейкхолдеры прозрели, вдохновили народ на непрерывные изменения и дело пошло'' или как т.п. А вижу что дискуссия уходит в сферу ''что как называется...''.
Александр Соловьев пишет: Посмотрите по ссылке на программный продукт в начале статьи
чем то напоминае Rapid miner. Хорошее решение, но не в любом зоопарке уживется. Плюс человеческий фактор в части любви перемен.
Александр Соловьев пишет: Специалисты всегда имеют некие представления и опыт в предшествующих проектах. Кроме того ''багаж'' того, что называют референтными, эталонными моделями, или отраслевыми решениями. И всё это в конечном итоге и используется, т.к. времени начинать всё с нуля нет. Поэтому глупость часто дублируется :( в новых про
Здесь ИМХО проблема несколько иная. Уже есть ИТ инфраструктура, прописаны процедуры, народ обучен работать. Но тут как всегда внезапно изменились условия и всё надо срочно менять. В контексе топика - переходить на BPM. Тут уже ни сразу, ни поэтапно в большинстве случаев заменить ЗОО чем-то гибко-интегральным, да еще не особо инвестируя, не получится. ''Опыт'' и консерватизм здесь весомы, но основное - как сделать перенос всех процессных цепочек (не факт, что только внутренних) на новую платформу и при этом оперативно эти цепочки менять.
Александр Соловьев пишет: Не надо мечтать о карьере CPO -> гораздо перспективнее стать CKO (Chief Knowledge Officer)
Смешная шутка, я уже давно не только СРО, но СКО переболел :)
Менеджер, Москва
Александр Соловьев пишет: Вот даже здесь в этой дискуссии люди не знающие логистику пишут о ERP как системе ''Только для сбора и обработки информации ...'' :) Я знаю о недостатках ERP, но сравнивать ERP систему , которая используется как интегральный инструмент менеджмента с технологией OLAP, которая на автомате может входить в ERP систему вместе с используемой СУБД … :)
Для того чтобы ''знать логистику'' существуют ''специально обученные люди'' : D А люди не знающие ERP, : D ... не знают, что многие ERP-продукты могут работать с разными СУБД (IBM DB2, Microsoft SQL Server, Oracle и т.д). Эти люди также не знают, что в ''большом зоопарке'' CRM может иметь свой OLAP, ERP - свой OLAP, а ряд других систем (WMS - например), могут совсем не иметь OLAP, а если где-то в дочках стоит D.J. Edwards или ''1С'' (в разных версиях) + Primavera, да еще Axapta ''доисторической'' версии (''мы к ней привыкли'') ... Каждый, кто занимался крупными внедрениями, может много случаев вспомнить.
Нач. отдела, зам. руководителя, Москва

Во понаписали! Даже не знаю кому отвечать. Висела себе статья без каментов довольно долго, вдруг бац - настрочили ;)

Вижу, что заметная часть адресованных автору (т.е. мне) претензий основана на недоразумениях. Например:

''непонятно как перейти от ''зоопарка'' к ВРМS, особенно в крупной организации'' - автор вообще-то этого не предлагал. Автор считает зоопарк в каком-то объеме неизбежным. Бороться с ним можно и нужно, победить - невозможно. Автор считает, что функциональное управление должно гармонично сочетаться с процессным, и соответственно, системы, поддерживающие функциональное управление (читай - традиционные корпоративные системы), должны сочетаться с процессными (читай - BPMS).

''Из каких элементов будет состоять BPMS в средней школе и на какой платформе'' - вопрос просто поставил меня в тупик. BPMS - это класс софта, вообще-то. Архитектурно стоит где-то рядом с DBMS. Поэтому переформулирую вопрос: ''Из каких элементов будет состоять DBMS в средней школе и на какой платформе?'' Может кто-нибудь ответить? Я - нет, извините.

Претензии же к автору уважаемой Лидии Сергеевой - это вообще нечто!

''например, под ''зоопарком'' на ИТ-сленге подразумевается не противоборство смежных подразделений, а использование для решения одной задачи сразу нескольких методов решения - часто противоречащих друг другу'' - автор вообще-то не называет ''зоопарком'' противоборство смежных подразделением; он говорит, что ''зоопарк'' есть следствие этого противоборства. Главное - борьба или все же проявим уважение к тексту?

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

По поводу реинжиниринга, ERP и Agile. Настаиваю на том, что методологически ERP тесно связан с реинжинирингом. Примеры внедрения ERP в соответствии с Agile если и есть, не делают погоды. Утверждаю, что в природе нет ERP-систем, разработчики которых ориентировались бы на непрерывное усовершенствование. Доминирующая идея - обследовали - написали требования - составили ТЗ - запрограммировали - наступило щасте.

Впрочем готов выслушать контраргументы; рад был бы ошибиться в этом пункте. Только ссылка уважаемого Виталия на собственный опыт не убеждает, извини. Это скорее исключение, подтверждающее правило ;)

Профессор, Чебоксары

Спасибо автору за ответы. Вопросы «терминологии» конечно же важные и первые!

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

Мб все-таки автор попробует ответить или найдутся другие люди, которые знают ответы.

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

Виктор, примеров полно. Конференции по BPM в Москве проходят уже 10 лет, по 3 в год. На каждом - несколько кейсов. Итого только доложенных кейсов порядка сотни. Отчеты по конференциям публикуются например тут: http://bpms.ru/library/reviews/17/index.html#c1705 Или обратитесь к любому вендору - каждый даст десятки референсов.

Что касается второго Вашего вопроса, то какого ответа Вы ожидаете? Особенно с учетом того, что, что в словаре BPM нет таких вещей, как вычислительные и графические связи между факторами и целевыми функциями. Я вам даже больше скажу: с точки зрения BPM нет такой вещи, как ''процесс образования''. Увы.

Профессор, Чебоксары
Анатолий Белайчук пишет: Виктор, примеров полно. К
За это большое спасибо!
Анатолий Белайчук пишет: в словаре BPM нет таких вещей, как вычислительные и графические связи между факторами и целевыми функциями.
Здесь хочу уточнить. Чтобы управлять, надо знать то, чем управляешь. Знать - это означает, что вы имеете модель того, чем управляете. Модели бывают вычислительные и графические. Процесс образования - термин спорный? Ради бога. Назовите просто процессом выдачи аттестатов зрелости растянутый на 11 лет - срок обучения в школе. Вопрос как надо организовать обучение можно решить, когда у вас есть вычислительная или графическая модель содержащая связи между оценками в аттестате и характеристиками процесса обучения школьника (например, зарплата преподавателей). Реально факторов типа - зарплата преподавателей - очень много, целевыми функциями обучения могут быть удовлетворенность процессом обучения родителя ученика, самого ученика, директора школы, министерства образования (но их все равно меньше, чем факторов). Вот я и спрашиваю - можно с помощью BPM выявить связи между факторами и целевыми функциями. Предупреждаю Ваш возможный ответ типа ''нет'', ''невозможно''. Зачем нужна BPM, если она не может строить модели и соответственно не может ничего дать для управления.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Эксперты: 4-дневная рабочая неделя приведет к снижению зарплат

Закон не препятствует пропорциональному снижению ФОТ при переходе на четырехдневную рабочую неделю.

75% россиян не верят в пенсии

Три четверти россиян не верят в пенсии, показал опрос Райффайзенбанка. А те кто верят, полагают, что она составит всего 10-20 тыс. руб.

Японцы доказали, что при четырехдневной рабочей неделе производительность растет. В Microsoft сообщили о росте на 40%

Японское подразделение Microsoft подвело положительные итоги месячного эксперимента по переходу на четырехдневную рабочую неделю.

 
Кто счастлив в России?

Самыми счастливыми оказались - медики, госслужащие и HR-ы. Об этом сообщается в исследовании Headhunter.